DSN's do not display in ODBC Data Source Administrator

I'm currently having to create a raft of DB2 connections in a
reasonable hurry. In addition, this list has to be propogated to three
other workstations (ultimate goal is to have DBArtisan access the
servers, instances and databases in an identical manner without having
to spend days doing this manually.)
I've figured out that the registry keys
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
and
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources
allow me to specify the System DSN's so that they can be picked up by
the ODBC Data Source Administration application.
Unfortuantely, I think that there's a hidden limit in how much data
the tool can handle. Somewhere around 155 of the 219 DSN's, one row
gets chopped.
Instead of a line that reads
server.instance.database IBM DB2 ODBC DRIVER
I get variants such as the latest:
server.insta <rest of line is blank>
Looks like a classic buffer reaches max-size, burp and do nothing but
continue running.
BTW, this is only the tip of the iceberg, not only are there going to
be 200+ DB2 databases, but we're also looking at Sybase, MS SQLServer,
Informix, and Oracle, plus a few other antique clangers and
boat-anchors.
A follow-up question, would shortening the name of the ODBC server have any
impact? (eg, just DB2)
Thanks in advance...
BruceHi Bruce,
Just wanted to ask if you have already installed the ODBC drivers for
all the other databases i.e. Sybase, SQL Server, Informix and Oracle?
Regards,
Ashok Rautela
"Byrocat" <strikemaster2000@.yahoo.ca> wrote in message news:<CM50c.68204$ee3.635958@.news20.
bellglobal.com>...
> I'm currently having to create a raft of DB2 connections in a
> reasonable hurry. In addition, this list has to be propogated to three
> other workstations (ultimate goal is to have DBArtisan access the
> servers, instances and databases in an identical manner without having
> to spend days doing this manually.)
> I've figured out that the registry keys
> HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
> and
> HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources
> allow me to specify the System DSN's so that they can be picked up by
> the ODBC Data Source Administration application.
> Unfortuantely, I think that there's a hidden limit in how much data
> the tool can handle. Somewhere around 155 of the 219 DSN's, one row
> gets chopped.
> Instead of a line that reads
> server.instance.database IBM DB2 ODBC DRIVER
> I get variants such as the latest:
> server.insta <rest of line is blank>
> Looks like a classic buffer reaches max-size, burp and do nothing but
> continue running.
> BTW, this is only the tip of the iceberg, not only are there going to
> be 200+ DB2 databases, but we're also looking at Sybase, MS SQLServer,
> Informix, and Oracle, plus a few other antique clangers and
> boat-anchors.
> A follow-up question, would shortening the name of the ODBC server have an
y
> impact? (eg, just DB2)
> Thanks in advance...
> Bruce|||arautela@.openlinksw.co.uk (Ashok Rautela) wrote in message news:<f5f56ae7.0403020312.44da8d
0a@.posting.google.com>...
> Hi Bruce,
> Just wanted to ask if you have already installed the ODBC drivers for
> all the other databases i.e. Sybase, SQL Server, Informix and Oracle?
> Regards,
> Ashok Rautela
>
I definitely have DB2, Sybase and SQLServer ODBC drivers installed.
I don't think that that is the problem. I've played with the list
entries (having created and recreated the list via the Registry), and
can get the cut-off point to change locations.
Defintiely points to the buffer being hard-coded.
Did have an interesting suggestion... Could the MS ODBC Administrator
make use of a registry entry to determine the maximum size of its
buffer and can this be changed?|||I remember a posting from someone at Microsoft that the
limitation is the combined length of the DSNs cannot exceed
4096 characters. So if you have DSN names that are all 409
characters long, you can only have 10 of those that will
display in the ODBC Data Source Administrator. If you create
more DSNs after this, they won't show up in the
Administrator applet but will be written to the registry and
will be available for use by applications.
-Sue
On 2 Mar 2004 09:07:38 -0800, bdealhoy@.sympatico.ca
(Byrocat) wrote:

>I definitely have DB2, Sybase and SQLServer ODBC drivers installed.
>I don't think that that is the problem. I've played with the list
>entries (having created and recreated the list via the Registry), and
>can get the cut-off point to change locations.
>Defintiely points to the buffer being hard-coded.
>Did have an interesting suggestion... Could the MS ODBC Administrator
>make use of a registry entry to determine the maximum size of its
>buffer and can this be changed?

DSN VS Logon

Our Database is ignores the authentication method that is chosen in the
database connection under ODBC. Everyone is getting a log on dialog.
Can any one help! ThanksYou didn't provide many details but is it safe to guess that
you are trying to use Windows Authentication in the DSN and
that all user who use this DSN are being prompted to enter a
user and password?
There was a similar issue with an old version of MDAC (2.5
maybe) if that's the case. You can check your MDAC
installation and version with component checker. Component
checker and MDAC versions are available for download from:
http://msdn.microsoft.com/data/ref/mdac/downloads/
-Sue
On Thu, 26 Oct 2006 12:49:02 -0700, Maida
<Maida@.discussions.microsoft.com> wrote:

>Our Database is ignores the authentication method that is chosen in the
>database connection under ODBC. Everyone is getting a log on dialog.
>Can any one help! Thanks|||Thanks Sue - Sorry I was short
We're moving on servers to a new Domain (btoins.com) then we will reimage
the workstation and move them. Before we moved it the DSN file worked fine w
e
didn't get any Windows Authentication box. We did a temp fix by putting the
domain users(genelco.com) in the local machine administrator group. Why
what's up with that - Thanks for your help!
"Sue Hoegemeier" wrote:

> You didn't provide many details but is it safe to guess that
> you are trying to use Windows Authentication in the DSN and
> that all user who use this DSN are being prompted to enter a
> user and password?
> There was a similar issue with an old version of MDAC (2.5
> maybe) if that's the case. You can check your MDAC
> installation and version with component checker. Component
> checker and MDAC versions are available for download from:
> http://msdn.microsoft.com/data/ref/mdac/downloads/
> -Sue
> On Thu, 26 Oct 2006 12:49:02 -0700, Maida
> <Maida@.discussions.microsoft.com> wrote:
>
>|||What protocol are you connecting with? Make sure it's TCP/IP
and not named pipes.
You can end up with some issues on logins, domain mappings
when moving domains but I can't tell from your post if this
is the issue or not. What domain are the users logging into
when they try to use the DSN? What domain are they listed
under in syslogins?
-Sue
On Fri, 27 Oct 2006 07:26:03 -0700, Maida
<Maida@.discussions.microsoft.com> wrote:
[vbcol=seagreen]
>Thanks Sue - Sorry I was short
>We're moving on servers to a new Domain (btoins.com) then we will reimage
>the workstation and move them. Before we moved it the DSN file worked fine
we
>didn't get any Windows Authentication box. We did a temp fix by putting the
>domain users(genelco.com) in the local machine administrator group. Why
>what's up with that - Thanks for your help!
>"Sue Hoegemeier" wrote:
>

DSN vs login authentication

Hello everybody!
I've created a DSN from a WIN2K Pro client to connect to a SQL Server 7.0
running on a WIN2K Server with domain controller.
The SQL Server authentication mode on the server machine is "Mixed mode"
Inside the client DSN configuration I've specified that the Authentication
Mode is SQL Server Mode, so I've entered the correct values for Access Id
and Password (I've already tested them connecting directly on the server
machine from query analyzer).
If I test this DSN connection everything works fine.
But if I run my VisualFoxPro Application (that use surely the DSN I've set
up) and appears the "sql server connection dialog box" when I click on "Ok"
I obtain the following error:
...
[Microsoft]ODBC-SQL Server Drive][Sql Server][Login failed for u
ser "server
name/user"]
as the Authentication Mode was "Windows" (trusted connection) and not "SQL
Server" as truly is.
Note that on the same network I've others WIN2K box with the same setup
(same MDAC 2.6, same domain user properties, same DSN setup) and for them I
don't have any problems.
Is there a way to force the connection process from the client to the server
to use always "SQL server authentication mode" (if DSN is not enough)?!?!
Can anyone help me? Thanks in advance!
Riccardo Piccini
Supporto Software
EDP SERVICE SRLCheck the version of the SQL Server ODBC driver on the client machine. It
sounds like you are running into a problem with sqlsrv32.dll version
2000.80.194. This version ignores SQL authentication and uses NT
authentication. The only way to resolve the problem is to upgrade teh
version of MDAC. I believe the problem was resolved in MDAC 2.6 SP2.
Rand
This posting is provided "as is" with no warranties and confers no rights.

DSN vs login authentication

Hello everybody!
I've created a DSN from a WIN2K Pro client to connect to a SQL Server 7.0
running on a WIN2K Server with domain controller.
The SQL Server authentication mode on the server machine is "Mixed mode"
Inside the client DSN configuration I've specified that the Authentication
Mode is SQL Server Mode, so I've entered the correct values for Access Id
and Password (I've already tested them connecting directly on the server
machine from query analyzer).
If I test this DSN connection everything works fine.
But if I run my VisualFoxPro Application (that use surely the DSN I've set
up) and appears the "sql server connection dialog box" when I click on "Ok"
I obtain the following error:
...
[Microsoft]ODBC-SQL Server Drive][Sql Server][Login failed for user "server
name/user"]
as the Authentication Mode was "Windows" (trusted connection) and not "SQL
Server" as truly is.
Note that on the same network I've others WIN2K box with the same setup
(same MDAC 2.6, same domain user properties, same DSN setup) and for them I
don't have any problems.
Is there a way to force the connection process from the client to the server
to use always "SQL server authentication mode" (if DSN is not enough)?!?!
Can anyone help me? Thanks in advance!
Riccardo Piccini
Supporto Software
EDP SERVICE SRL
Check the version of the SQL Server ODBC driver on the client machine. It
sounds like you are running into a problem with sqlsrv32.dll version
2000.80.194. This version ignores SQL authentication and uses NT
authentication. The only way to resolve the problem is to upgrade teh
version of MDAC. I believe the problem was resolved in MDAC 2.6 SP2.
Rand
This posting is provided "as is" with no warranties and confers no rights.

DSN Using Trusted Connection When SQL Authentication is selected

I am trying to help an in-house developer with his database. He has develope
d an Access front-end that links to SQL tables. The tables are linked using
an ODBC DSN with SQL Server Authentication selected. WHen a user opens the d
atabse, they get one of two
error messages, based on the user. THey eith get ODBC Call failed and can no
t go any further, or they get Connection failed, and the SQL Server login di
alog, where they have to uncheck Trusted connection and enter the appropriat
e username and password. W
e want it to just authenticate based on the settings in the DSN without open
ing a logn box.You can trace the calls using ODBC Trace to see exactly why the call
failed. Also, the developer's connection string may be being used and
could be stored in the system table. You'll need to modify this before
distributing the app.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

DSN Using Trusted Connection When SQL Authentication is selected

I am trying to help an in-house developer with his database. He has developed an Access front-end that links to SQL tables. The tables are linked using an ODBC DSN with SQL Server Authentication selected. WHen a user opens the databse, they get one of two
error messages, based on the user. THey eith get ODBC Call failed and can not go any further, or they get Connection failed, and the SQL Server login dialog, where they have to uncheck Trusted connection and enter the appropriate username and password. W
e want it to just authenticate based on the settings in the DSN without opening a logn box.
You can trace the calls using ODBC Trace to see exactly why the call
failed. Also, the developer's connection string may be being used and
could be stored in the system table. You'll need to modify this before
distributing the app.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.