2010-10-08 1 views
0

Ceci est assez étrange. J'ai cette chaîne qui se connecte à un SQLServer dans le même domaine que les ordinateurs sont en cours d'exécution et compare le nom d'utilisateur avec employeeID. Puis prend cette ligne et la déverse dans le registre des ordinateurs lokal. Cela fonctionne sous Windows XP, mais pas Windows 7 semble-t-il.VBscript - Connexion SQL échoue SQL Server n'existe pas ou accès refusé

Je reçois ce message d'erreur exact:

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. 

C'est le script lui-même. J'ai supprimé les noms de serveur réels. Reckon personne n'a besoin de ça.

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 

Pourquoi cela fonctionne-t-il sous Windows XP mais pas sous Windows 7?

+0

Je pense que vous pouvez radicalement supprimer tout dans l'exemple de script à l'exception de la ligne qui échoue + une ou deux lignes de contexte. Toute la question LDAP n'a rien à voir avec votre problème. – Tomalak

+0

Supprimé la plupart du script maintenant, il est probablement lié à différentes structures de sécurité dans Windows 7? –

Répondre

1

Étant donné que vous utilisez la sécurité intégrée, laissez-moi vous poser des questions sur le compte qui exécute l'application. Avez-vous ajouté ce compte en tant qu'utilisateur à la base de données? Si ce n'est pas le cas, et que c'est un compte admin, vous comptez probablement sur les anciens "administrateurs qui peuvent tout faire" et sous Windows 7 ce n'est plus vrai. Pour tester cela, essayez d'exécuter l'application surélevée (cliquez avec le bouton droit de la souris sur l'exe et exécutez l'administrateur). Cela lui permettra de conserver votre "admin-ness" et de le laisser entrer dans la base de données. Si cela fonctionne, ne continuez pas à l'exécuter, mais allez plutôt à SQL et ajoutez-vous en tant qu'utilisateur. Ensuite, l'application devrait fonctionner bien non-élevée.

+0

Bien, cela a du sens. Donc, cela signifie essentiellement que je devrais ajouter un utilisateur et un mot de passe pour le script lui-même? Ceci est censé fonctionner sur tous les utilisateurs du domaine, environ 2000. La moitié d'entre eux ont Windows 7 et plus à venir. Ils sont tous des administrateurs locaux, ce qui explique probablement pourquoi cela fonctionne sous XP. –

+0

Il est probablement préférable de créer un groupe Windows et d'y ajouter toutes ces personnes, puis d'ajouter ce groupe Windows en tant qu'utilisateur à la base de données elle-même à l'aide de SQL Server Management Studio. Vous pouvez également mettre un nom d'utilisateur et un mot de passe SQL dans la chaîne de connexion, mais il existe des problèmes de sécurité avec des personnes susceptibles de découvrir ce nom d'utilisateur et mot de passe, ainsi que toute personne pouvant exécuter l'exe. vouloir. –

+0

Juste un petit commentaire. Si tel était le problème, cela ne fonctionnerait pas sur Windows XP non plus? Je ne pense pas que ce soit un problème avec la base de données et les paramètres de sécurité. Je pense que c'est Windows 7 lui-même qui empêche l'exécution du script. –