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.