views:

33

answers:

1

Hi, this is pretty strange. I've got this string that connect to a SQLServer in the same domain as the computers are running and compares username with employeeID. Then takes that row and dumps it into the lokal computers registry. This is working in Windows XP, but not Windows 7 it seems.

I get this exact error message:

Line:39
Char:1
Error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied. 
Code: 80004005
Source: Microsoft OLE DB Provider for SQL Server. 

This is the script itself. I've removed the actual servernames. Reckon nobody needs those.

Set oConn = CreateObject("ADODB.Connection")
oConn.Open "Provider=sqloledb;Data Source=mysqlserver04\mysqlserver04;Initial Catalog=orginfo;Integrated Security=SSPI"
sSQL = "select top 1 * from dbo.Mal_personinfo where empid = '" & EID & "'"
'wscript.echo sSQL
set rs = oConn.Execute(sSQL)

set oSystem = CreateObject("WScript.Shell")
for iTeller = 0 to rs.fields.count - 1
    Text = Text & rs.fields(iTeller).Name & "=" & rs.fields(iTeller).Value & " - "
    oSystem.RegWrite "HKCU\Software\MalData\" & rs.fields(iTeller).Name,rs.fields(iTeller).Value,"REG_SZ"
next
'wscript.echo Text

Why does this work on Windows XP but not Windows 7?

+1  A: 

Since you're using integrated security, let me ask you about the account that is running the application. Did you add that account as a user to the database? If not, and it's an admin account, you're probably relying on the old "admins can do everything" and under Windows 7 that's not true any more.

To test this, try running the application elevated (right click the exe and Run As Administrator.) This will cause it to keep your "admin-ness" and might let it into the database. If that works, don't continue to run it elevated, but instead go to SQL and add yourself as a user. Then the app should work fine non-elevated.

Kate Gregory
Right, that makes sense. So, that basically means that I should add a user and password to the script itself? This is supposed to run on every user in the domain, about 2000. Half of which have Windows 7 and more to come. They're all local admins so that probably explains why it works in XP.
Kenny Bones
Probably the best bet is to create a Windows group and add all these people to it, then add that Windows group as a user to the database itself using SQL Server Management Studio. Alternatively you could put a SQL username and password into the connection string, but there are security issues there with people possibly able to discover that username and password, plus anyone who can run the exe gets database access instead of being able to control it if you want.
Kate Gregory
Just a quick comment. If this was the issue, then it wouldn't work on Windows XP either would it? I don't think it's an issue with the database and security settings towards it. I think it's Windows 7 itself that is stopping the script from executing.
Kenny Bones
@Kenny, on XP if you are an admin you get access to the database by virtue of your admin-ness. This is exactly what happened to me when I moved to Windows 7. I had to go around adding myself to databases I had been using for years.
Kate Gregory
Hi, the problem was actually solved by specifying the server port. No changes had to be made for permissions. I guess a problem can have several possible solutions :p I'm setting your answer as approved anyway :)
Kenny Bones