DBI not finding Database after upgrade to SQLServer 2005

After upgrading to SQLServer 2005 none of the perlscripts (which access the DB with DBI) we use for our drop downs work anymore when called as inlines from the DCT. We get the error -
Root cause:
DBI connect('NickTest','sa',...) failed: [Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied. (SQL-08001) [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Connect()). (SQL-01000)(DBD: db_login/SQLConnect err=-1) at C:/iw-home/custom/bin/DBTest.ipl line 51 Unable to open database connection at C:/iw-home/custom/bin/DBTest.ipl line 51.

However when the same perlscripts are run from the command line they work fine.
Windows2003/TS6.7.1/OD6.1

Thanks in advance for any help !

/nick

Find more posts tagged with

Comments

Adam Stoller

After upgrading to SQLServer 2005 none of the perlscripts (which access the DB with DBI) we use for our drop downs work anymore when called as inlines from the DCT. We get the error -
Root cause:
DBI connect('NickTest','sa',...) failed: [Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied. (SQL-08001) [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (Connect()). (SQL-01000)(DBD: db_login/SQLConnect err=-1) at C:/iw-home/custom/bin/DBTest.ipl line 51 Unable to open database connection at C:/iw-home/custom/bin/DBTest.ipl line 51.

However when the same perlscripts are run from the command line they work fine.
Windows2003/TS6.7.1/OD6.1

Thanks in advance for any help !

/nick

This sounds like a classic case of environment information not being synchronized - add some code to your scrip to dump out the contents of %ENV to a debugging log file - run it both from the command line and from the DCT and compare the results.

Chances are you will need to add a BEGIN{...}; block to your scripts to explicitly set some ENV parameters.

Migrateduser

Many thanks again Ghoti. I did exactly what you said and it seems that when the perlscript is executed as an inline from the DCT the only ENV variables are the 4 or 5 TeamSite ones. When executing from the command line there where over 20 systems ones. So I set all the these system ones manually in my script and this solved the problem. I then removed them one by one until I found the single one that was fixing the problem. Turns out that it is SYSTEMROOT.
So for those of you who may also encounter this problem adding the line -

$ENV{SYSTEMROOT} = "C:\\WINDOWS";

to your perlscripts solves it.

However I'm still maddingly puzzled as to why this problem arose on migration to Windows2003 and SQLServer2005 and to why this simple addition to the script solves it.

cheers

/nick

Adam Stoller

Many thanks again Ghoti. I did exactly what you said and it seems that when the perlscript is executed as an inline from the DCT the only ENV variables are the 4 or 5 TeamSite ones. When executing from the command line there where over 20 systems ones. So I set all the these system ones manually in my script and this solved the problem. I then removed them one by one until I found the single one that was fixing the problem. Turns out that it is SYSTEMROOT.
So for those of you who may also encounter this problem adding the line -

$ENV{SYSTEMROOT} = "C:\\WINDOWS";

to your perlscripts solves it.

However I'm still maddingly puzzled as to why this problem arose on migration to Windows2003 and SQLServer2005 and to why this simple addition to the script solves it.

cheers

/nick

As a guess - and only a guess - perhaps SQLServer2005 requires SYSTEMROOT where its predecessor may not have required it. Inline scripts from DCTs have never been passed environment information other than the TeamSite specific ones.