Re: DBD::ODBC in Windows Server 2008

I would presume your DSNs do not exist for the user you are logged in as. Creating them as SYSTEM DSNs is one way to fix this. Alternatively, you have migrated from Windows 32bit to 64bit and these use two different ODBC administrators - there is a 32bit one and a 64bit one - you need to pick the right one for your application.

The error text including the "default driver specified" is a little misleading. In ODBC you can create a DEFAULT data source which is used if you do not specify a DSN - strangely ;-) it is implemented as data source named DEFAULT in the odbc ini files or registry entries.

You can move to DSNless connections but that does mean if you connect from multiple apps and you want to change some aspect of the driver connection you will have to change it in multiple places instead of in a single SYSTEM DSN.

Comment on Re: DBD::ODBC in Windows Server 2008

Replies are listed 'Best First'.
Re^2: DBD::ODBC in Windows Server 2008 by Narveson (Chaplain) on May 05, 2010 at 20:59 UTC
Good advice, and a perceptive warning: that does mean if you connect from multiple apps and you want to change some aspect of the driver connection you will have to change it in multiple places instead of in a single SYSTEM DSN. I think I'll set up a module so my client scripts can say `use OurDatabase::Connection; my $dbh = OurDatabase::Connection->new();` [download] and the OurDatabase::Connection module can check whether it's running in development or in production and pick the right server name accordingly. My boss may regret the apparent increase in complexity, but I'll try to point out that we'll be leaving behind our dependency on crucial data that we've been keeping hidden in the Windows registry until now.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: DBD::ODBC in Windows Server 2008
by Narveson (Chaplain) on May 05, 2010 at 20:59 UTC

Good advice, and a perceptive warning:

that does mean if you connect from multiple apps and you want to change some aspect of the driver connection you will have to change it in multiple places instead of in a single SYSTEM DSN.

I think I'll set up a module so my client scripts can say

use OurDatabase::Connection;
my $dbh = OurDatabase::Connection->new();
[download]

and the OurDatabase::Connection module can check whether it's running in development or in production and pick the right server name accordingly.

My boss may regret the apparent increase in complexity, but I'll try to point out that we'll be leaving behind our dependency on crucial data that we've been keeping hidden in the Windows registry until now.

[reply]
[d/l]