script Perl fonctionne sur OK dans l'invite de commande, mais échoue sur ODBC en tant que script CGI

Question

Problème: script Perl fonctionne très bien dans l'invite de commande, mais échoue sur ODBC en tant que script CGI

Réglages: Win XP Pro version 64 bits 2003 SP2 Apache 2.2.17 Win32 actif Perl 5.12.2 (non Perl64) une source de données ODBC est créé pour SQL Server

Détails: à partir de l'invite de commande, Phone.pl fonctionne OK - il obtient des résultats de la requête comme prévu - ce qui signifie que DBI fonctionne bien

comme script CGI, Ph one.pl imprime le code HTML comme prévu avant le code de démarrage ODBC. (Paramètres Apache fonctionnent OK pour le script non-ODBC.)

est ici le msg error.log d'Apache

[Mar 23 novembre 2010 13:27:57] [error] [client 127.0.0.1] DBI connect ('SQLSVR206', 'administrator', ...) a échoué: [Microsoft] [Gestionnaire de pilotes ODBC] Nom de la source de données introuvable et aucun pilote par défaut spécifié (SQL-IM002) sur C: /CGI/Phone.pl ligne 32

Une idée de pourquoi il se comporte différemment?

#!c:/perl/bin/perl.exe 
use CGI qw(:standard); 
use strict; 
use warnings; 
use DBI; 

my ($sqlstr, $sql_UNITED, $dbh206); 

# 206 
# select * from getProvFINON('270762789')#TIN 
my @colUNITED = qw/ADR_LN_1_TXT PROV_SYS_ID ZIP_CD FULL_NM SOURCE PROV_TIN BILL_TEL/; 

sub Init(){ 
    $dbh206 = DBI->connect ("dbi:ODBC:SQLSVR206",'USER','PASSWORD',{RaiseError=>1}) 
     or die $DBI::errstr; 
    $sqlstr = qq/ select * from getProvFINON(?) /; #parameters TIN 
    $sql_UNITED = $dbh206->prepare($sqlstr) 
     or die "prepare failed: " . $dbh206->errstr(); 
} 

sub test1{ 
    my $tin = shift(); 
    $sql_UNITED->execute($tin) or die $sql_UNITED->errstr; 
    my $row = $sql_UNITED->fetchrow_hashref; 
    while(defined ($row)){ 
    foreach(@colUNITED){ 
     print $row->{$_}."~~~"; 
    } 
    print "<p>"; 
    $row = $sql_UNITED->fetchrow_hashref; 
    } 
} 

print header; 
print "test text<p>"; 
Init(); 
test1('270762789'); 
print "999999999999<p>"; 

=========================================== =============== MISE À JOUR: une partie du problème est le 32 bits VS 64 bits problème ODBC voir http://support.microsoft.com/kb/942976

CEPENDANT, après avoir mis en place ODBC, je reste erreur suivante dans le journal Apache [Wed Nov 24 01:38:48 2010] [erreur] [client 127.0.0.1] DBI connect ('SQLSVR206-32', '', ...) a échoué: [Microsoft] [ODBC Pilote SQL Server] [SQL Server] Échec de la connexion pour l'utilisateur 'MYDOMAIN \ GARY $'. (SQL-28000) à C: /CGI/test.pl ligne 15

Je me suis connecté en tant que MYDOMAIN \ administrator et a démarré Apache. ODBC a été configuré pour utiliser "Avec l'authentification Windows NT utilisant l'ID de connexion réseau" D'où vient ce "MYDOMAIN \ GARY $"? Merci!

============================================== ============= MISE À JOUR FINALE: Les services Apache s'exécutent en utilisant "Compte système local", et c'est de là que vient le "MYDOMAIN \ GARY $". La chose est GARY n'est pas avec la compagnie et son ID a été abandonné de SQL Server, mais le code ODBC dans CGI hérité GARY d'Apache, entraînant l'erreur 28000. Donc le problème était une convolution de 1) ODBC 32/64 bit DSN et 2) compte par défaut utilisé par Apache

Answer 1

La source de données ODBC est peut-être répertoriée sous "DSN utilisateur" et non "DSN système". Je pense que l'identité de votre serveur Web a uniquement accès au System DSN.

Dans le cas où mon post n'a pas de sens, je le modifier afin d'ajouter un lien vers des informations sur la différence entre les utilisateurs par rapport à DSN système: http://www.truthsolutions.com/sql/odbc/creating_a_new_odbc_dsn.htm

Answer 2

passe quelque chose avec Windows 7 connexions ODBC que je ne peux pas comprendre non plus. J'ai mis en place le ODBC et il serait bien tester mais obtenir une erreur similaire à celle que vous montrez. Même en connectant MS SQL Server Mgmt Studio à certains serveurs SQL, je dois explicitement ajouter des paramètres de connexion supplémentaires. Puisque je n'ai que le problème sur certains serveurs SQL (que je ne possède pas), je pense que c'est un problème côté serveur. Sur PERL j'ai finalement abandonné et juste créé le fichier DSN avec les paramètres de connexion supplémentaires et pointé directement vers lui. Notez comment le nom du serveur est là deux fois.

use DBI; 
use SQL::Abstract; 
my $CONNECT = "FILEDSN=thefile.dsn"; 
my $dbh = DBI->connect("dbi:ODBC:$CONNECT", "myidsid", "passwordThatsNotUsed"); 

avec le fichier ODBC recherche quelque chose comme:

[ODBC] 
DRIVER=SQL Server Native Client 10.0 
UID=myidsid 
Address=servername,3180 
Network=DBMSSOCN 
APP=Microsoft® Windows® Operating System 
Trusted_Connection=Yes 
SERVER=servername 
PWD=someTextInPlaceOfPasswordAsItsNotUsed