ODBC Driver to Connect With IBM AS/400 System

Good Morning All:
I am trying to find an ODBC Driver that will connect my current
Microsoft Access Databas with our IBM AS/400 System. We have the
driver in Excel, but I don't believe it is the same driver for
Access. Any input would be greatly appreciated.
-Anthony Morano
Pension Fund Intern.
The ODBC driver for DB2 on AS/400 as provided by IBM; it is the same driver
for all client applications. Contact you IBM SE to purchase the client
connectivity software if you don't already have it. Otherwise try an SQL/400
newsgroup.
<antmorano@.gmail.com> wrote in message
news:1184852139.438805.176820@.e9g2000prf.googlegro ups.com...
> Good Morning All:
> I am trying to find an ODBC Driver that will connect my current
> Microsoft Access Databas with our IBM AS/400 System. We have the
> driver in Excel, but I don't believe it is the same driver for
> Access. Any input would be greatly appreciated.
> -Anthony Morano
> Pension Fund Intern.
>
sql

ODBC Driver to Connect With IBM AS/400 System

Good Morning All:
I am trying to find an ODBC Driver that will connect my current
Microsoft Access Databas with our IBM AS/400 System. We have the
driver in Excel, but I don't believe it is the same driver for
Access. Any input would be greatly appreciated.
-Anthony Morano
Pension Fund Intern.The ODBC driver for DB2 on AS/400 as provided by IBM; it is the same driver
for all client applications. Contact you IBM SE to purchase the client
connectivity software if you don't already have it. Otherwise try an SQL/400
newsgroup.
<antmorano@.gmail.com> wrote in message
news:1184852139.438805.176820@.e9g2000prf.googlegroups.com...
> Good Morning All:
> I am trying to find an ODBC Driver that will connect my current
> Microsoft Access Databas with our IBM AS/400 System. We have the
> driver in Excel, but I don't believe it is the same driver for
> Access. Any input would be greatly appreciated.
> -Anthony Morano
> Pension Fund Intern.
>

ODBC driver for windows 2003 64bit

Hi All,

I have installed windows 2003 R2 64bit on one of the system, but my devlopment team pointed out that there is no odbc driver available.

I check it for odbc driver on OS cd but i do not found any relevant files/packages, can any one tell me from where I can download the ODBC driver for windows 2003 64bit OS.

Thanks & Regards

Varian

An ODBC driver connects to a particular database backend server (Oracle, SQL Server, etc). What specific ODBC driver are you looking for?|||

There is definitely a SQL Server driver for 64-bit. SQLSRV32.DLL ships with the OS, and SQLNCLI.DLL (used with SQL Server 2005) can be downloaded from the microsoft website.

I think you may be correct, though, about non-SQL Server drivers no being available on 64-bit clients.

|||

I have the same problem. My company works with the windows server 2003 R2 64 bits and we can't use an Access DB in our Site because this version doesn't have the drivers for accessing Access Databases. Can someone help?

Thanks

|||

Hi,

Can you help me with ODBC drivers for MS Excel and MS Access... My organisation needs the same.

Regards

Ramakrishnan M

|||

Try looking at the post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1239339&SiteID=1, which I believe answers your question. Here's a clip:

64-bit MSDASQL (both AMD64 and IA64) will be released in Windows Longhorn Server Beta 3 and Windows Vista SP1.

Pak-Ming Cheung,

MDAC Team, MSFT.

ODBC driver for windows 2003 64bit

Hi All,

I have installed windows 2003 R2 64bit on one of the system, but my devlopment team pointed out that there is no odbc driver available.

I check it for odbc driver on OS cd but i do not found any relevant files/packages, can any one tell me from where I can download the ODBC driver for windows 2003 64bit OS.

Thanks & Regards

Varian

An ODBC driver connects to a particular database backend server (Oracle, SQL Server, etc). What specific ODBC driver are you looking for?|||

There is definitely a SQL Server driver for 64-bit. SQLSRV32.DLL ships with the OS, and SQLNCLI.DLL (used with SQL Server 2005) can be downloaded from the microsoft website.

I think you may be correct, though, about non-SQL Server drivers no being available on 64-bit clients.

|||

I have the same problem. My company works with the windows server 2003 R2 64 bits and we can't use an Access DB in our Site because this version doesn't have the drivers for accessing Access Databases. Can someone help?

Thanks

|||

Hi,

Can you help me with ODBC drivers for MS Excel and MS Access... My organisation needs the same.

Regards

Ramakrishnan M

|||

Try looking at the post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1239339&SiteID=1, which I believe answers your question. Here's a clip:

64-bit MSDASQL (both AMD64 and IA64) will be released in Windows Longhorn Server Beta 3 and Windows Vista SP1.

Pak-Ming Cheung,

MDAC Team, MSFT.

sql

ODBC driver for windows 2003 64bit

Hi All,

I have installed windows 2003 R2 64bit on one of the system, but my devlopment team pointed out that there is no odbc driver available.

I check it for odbc driver on OS cd but i do not found any relevant files/packages, can any one tell me from where I can download the ODBC driver for windows 2003 64bit OS.

Thanks & Regards

Varian

An ODBC driver connects to a particular database backend server (Oracle, SQL Server, etc). What specific ODBC driver are you looking for?|||

There is definitely a SQL Server driver for 64-bit. SQLSRV32.DLL ships with the OS, and SQLNCLI.DLL (used with SQL Server 2005) can be downloaded from the microsoft website.

I think you may be correct, though, about non-SQL Server drivers no being available on 64-bit clients.

|||

I have the same problem. My company works with the windows server 2003 R2 64 bits and we can't use an Access DB in our Site because this version doesn't have the drivers for accessing Access Databases. Can someone help?

Thanks

|||

Hi,

Can you help me with ODBC drivers for MS Excel and MS Access... My organisation needs the same.

Regards

Ramakrishnan M

|||

Try looking at the post http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1239339&SiteID=1, which I believe answers your question. Here's a clip:

64-bit MSDASQL (both AMD64 and IA64) will be released in Windows Longhorn Server Beta 3 and Windows Vista SP1.

Pak-Ming Cheung,

MDAC Team, MSFT.

ODBC Driver for Access and AS/400

Good Morning All:
I am trying to find an ODBC driver for Microsoft Access that will
allow me to connect to our IBM AS/400 system. All inpout would be
appreciated.
-Anthony Morano
Pension Fund InternYou can use the Client Access driver you get with the client
for the AS/400.
You may want to post future questions to one of the Access
newsgroups. This group addresses ODBC and SQL Server.
-Sue
On Thu, 19 Jul 2007 14:06:15 -0000, antmorano@.gmail.com
wrote:

>Good Morning All:
>I am trying to find an ODBC driver for Microsoft Access that will
>allow me to connect to our IBM AS/400 system. All inpout would be
>appreciated.
>-Anthony Morano
>Pension Fund Intern

ODBC Driver for Access and AS/400

Good Morning All:
I am trying to find an ODBC driver for Microsoft Access that will
allow me to connect to our IBM AS/400 system. All inpout would be
appreciated.
-Anthony Morano
Pension Fund Intern
You can use the Client Access driver you get with the client
for the AS/400.
You may want to post future questions to one of the Access
newsgroups. This group addresses ODBC and SQL Server.
-Sue
On Thu, 19 Jul 2007 14:06:15 -0000, antmorano@.gmail.com
wrote:

>Good Morning All:
>I am trying to find an ODBC driver for Microsoft Access that will
>allow me to connect to our IBM AS/400 system. All inpout would be
>appreciated.
>-Anthony Morano
>Pension Fund Intern

ODBC Data Source Administrator

Hi all, hope you can help?
I have created a system DSN in the usual way using the above ODBC tool
(I am trying to create a connection to our Open Accounts package using
the OpenEdge 10.1A driver). I provide the host name, the port number
and the database name, the user ID and password and test the
connection. All works a treat...'Connection established'.
I open up Excel and try to import data using my newly created DSN...it
exposes all of the tables within the database and lets me select
fields from those table. When I get to the 'return data to Microsoft
Excel' part I get the following error message 'Access denied
(Authorisation failed) (7512)'.
Any ideas guys?
Regards
PaulHi Paul,
What database is the Open Accounts package using to store it's data, SQL
Server, Access, Oracle etc. We need to know this because we need to
troubleshoot the security settings/accounts etc. of the database
containing the Open Accounts data.
Jonathan
thePriest wrote:
> Hi all, hope you can help?
> I have created a system DSN in the usual way using the above ODBC tool
> (I am trying to create a connection to our Open Accounts package using
> the OpenEdge 10.1A driver). I provide the host name, the port number
> and the database name, the user ID and password and test the
> connection. All works a treat...'Connection established'.
> I open up Excel and try to import data using my newly created DSN...it
> exposes all of the tables within the database and lets me select
> fields from those table. When I get to the 'return data to Microsoft
> Excel' part I get the following error message 'Access denied
> (Authorisation failed) (7512)'.
> Any ideas guys?
> Regards
> Paul
>

ODBC Data Source

I hope that I am being a real dunce about this.
Using SSIS, I create an ODBC data connection to our transactional system,
from which we build our data warehouse. In the data flow, when I go to add
the data source, I find nothing that will reference the ODBC data connection
.
Suggestions?
StevenRight click on the data flow source and select edit. From
here you can enter the Connection Manager that you added.
What are you using as the Data Flow Source?
-Sue
On Tue, 23 May 2006 08:01:03 -0700, Steven
<Steven@.discussions.microsoft.com> wrote:

>I hope that I am being a real dunce about this.
>Using SSIS, I create an ODBC data connection to our transactional system,
>from which we build our data warehouse. In the data flow, when I go to add
>the data source, I find nothing that will reference the ODBC data connectio
n.
>Suggestions?
>Steven|||Sue,
Thanks for your response. Here is what I found after some digging. You use
a .Net Providers/ODBC data providers connection. You create it and then
configure it to use a system dsn. Within the dataflow, you access the
connection with a data reader source. You point it to the connection that
you configured. You control what is pulled by using the SQLCommand on the
component properties tab.
Simple enough once you know what to do.
-Steven
"Sue Hoegemeier" wrote:

> Right click on the data flow source and select edit. From
> here you can enter the Connection Manager that you added.
> What are you using as the Data Flow Source?
> -Sue
> On Tue, 23 May 2006 08:01:03 -0700, Steven
> <Steven@.discussions.microsoft.com> wrote:
>
>

ODBC Create a new Data Souce to SQL not displaying

On a Windows XP PC, why doesn't the Create a new Data
Source to SQL Server window pop up when you select to add
a new system dsn from the ODBC data source
administrator? I have one particular PC where this won't
come up, not all XP PCs though. Anyone see this before!
Thanks.
.Did you try reinstalling MDAC? You'd want to at least check
the MDAC configuration on the PC using component checker.
You can download the latest MDAC as well as component
checker from:
http://msdn.microsoft.com/downloads/list/dataaccess.asp
-Sue
On Mon, 1 Dec 2003 08:06:15 -0800, "Nil"
<anonymous@.discussions.microsoft.com> wrote:

quote:

---

>On a Windows XP PC, why doesn't the Create a new Data
>Source to SQL Server window pop up when you select to add
>a new system dsn from the ODBC data source
>administrator? I have one particular PC where this won't
>come up, not all XP PCs though. Anyone see this before!
>Thanks.
>.
>

---

odbc connections

A colleague of mine has a problem;
"Has anyone ever experienced the problem of creating a System ODBC and it doesn't display in the ODBC administrator applet?"
was hoping someone here could help...What is your exact problem?|||the problem was that when created a new odbc connection this was not displayed...i have since discovered a reboot fixed it-i was under the impression that the sql server would have been rebooted first...dont worry about it!
thanks though

ODBC connection frequently drops in routed network

Hello,
we are having serious problems with an application that uses an ODBC
connection (System DSN) to a SQL Server in another subnet. The network is
fine, all network tests reveal nothing of consequence. However, the problem
does not appear when SQL server and client are in the same subnet.
The ODBC connection from the client gets dropped at seemingly random
intervals and in the logs one can see the following:
{NIL, 10054, [01000][10054][Microsoft][ODBC SQL Server
Driver][DBNETLIB]ConnectionWrite (send()).}
{NIL, 59, [01000][59][Microsoft][ODBC SQL Server
Driver][DBNETLIB]ConnectionWrite (WrapperWrite()).}
{NIL, -1, [08S01][0][Microsoft][ODBC SQL Server
Driver]Communication link failure}
We honestly don't know what else to look for. Maybe anyone has an idea?
Thanks in advance,
Thomas Liss
Well, after configuring "Flow Control" on the network cards of the SQL
Server, the problems were gone.
"Thomas Liss" <liss@.uipugmbh.com> wrote in message
news:upFsIo9TFHA.2664@.TK2MSFTNGP15.phx.gbl...
> Hello,
> we are having serious problems with an application that uses an ODBC
> connection (System DSN) to a SQL Server in another subnet. The network is
> fine, all network tests reveal nothing of consequence. However, the
> problem does not appear when SQL server and client are in the same subnet.
> The ODBC connection from the client gets dropped at seemingly random
> intervals and in the logs one can see the following:
> {NIL, 10054, [01000][10054][Microsoft][ODBC SQL Server
> Driver][DBNETLIB]ConnectionWrite (send()).}
> {NIL, 59, [01000][59][Microsoft][ODBC SQL Server
> Driver][DBNETLIB]ConnectionWrite (WrapperWrite()).}
> {NIL, -1, [08S01][0][Microsoft][ODBC SQL Server
> Driver]Communication link failure}
> We honestly don't know what else to look for. Maybe anyone has an idea?
>
> Thanks in advance,
>
> Thomas Liss
>
|||Could you please explain what was the old setting and what is the new one?
Regards,
Marko Erzen
"Thomas Liss" <liss@.uipugmbh.com> wrote in message
news:e2wez$JUFHA.2172@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Well, after configuring "Flow Control" on the network cards of the SQL
> Server, the problems were gone.
>
> "Thomas Liss" <liss@.uipugmbh.com> wrote in message
> news:upFsIo9TFHA.2664@.TK2MSFTNGP15.phx.gbl...
is[vbcol=seagreen]
subnet.
>
|||Thomas,
I just read your post and we are experiencing the same kind of error
here. The communication link failure is only occurring for clients
connecting from outside of the server's home subnet and the failure is
intermittent. Did you ever resolve your problems?
*** Sent via Developersdex http://www.codecomments.com ***

ODBC connection frequently drops in routed network

Hello,
we are having serious problems with an application that uses an ODBC
connection (System DSN) to a SQL Server in another subnet. The network is
fine, all network tests reveal nothing of consequence. However, the problem
does not appear when SQL server and client are in the same subnet.
The ODBC connection from the client gets dropped at seemingly random
intervals and in the logs one can see the following:
{NIL, 10054, [01000][10054][Microsoft][ODBC SQL Se
rver
Driver][DBNETLIB]ConnectionWrite (send()).}
{NIL, 59, [01000][59][Microsoft][ODBC SQL Serve
r
Driver][DBNETLIB]ConnectionWrite (WrapperWrite()).}
{NIL, -1, [08S01][0][Microsoft][ODBC SQL Server
Driver]Communication link failure}
We honestly don't know what else to look for. Maybe anyone has an idea?
Thanks in advance,
Thomas LissWell, after configuring "Flow Control" on the network cards of the SQL
Server, the problems were gone.
"Thomas Liss" <liss@.uipugmbh.com> wrote in message
news:upFsIo9TFHA.2664@.TK2MSFTNGP15.phx.gbl...
> Hello,
> we are having serious problems with an application that uses an ODBC
> connection (System DSN) to a SQL Server in another subnet. The network is
> fine, all network tests reveal nothing of consequence. However, the
> problem does not appear when SQL server and client are in the same subnet.
> The ODBC connection from the client gets dropped at seemingly random
> intervals and in the logs one can see the following:
> {NIL, 10054, [01000][10054][Microsoft][ODBC SQL
Server
> Driver][DBNETLIB]ConnectionWrite (send()).}
> {NIL, 59, [01000][59][Microsoft][ODBC SQL Ser
ver
> Driver][DBNETLIB]ConnectionWrite (WrapperWrite()).}
> {NIL, -1, [08S01][0][Microsoft][ODBC SQL Serv
er
> Driver]Communication link failure}
> We honestly don't know what else to look for. Maybe anyone has an idea?
>
> Thanks in advance,
>
> Thomas Liss
>|||Could you please explain what was the old setting and what is the new one?
Regards,
Marko Erzen
"Thomas Liss" <liss@.uipugmbh.com> wrote in message
news:e2wez$JUFHA.2172@.TK2MSFTNGP15.phx.gbl...
> Well, after configuring "Flow Control" on the network cards of the SQL
> Server, the problems were gone.
>
> "Thomas Liss" <liss@.uipugmbh.com> wrote in message
> news:upFsIo9TFHA.2664@.TK2MSFTNGP15.phx.gbl...
is[vbcol=seagreen]
subnet.[vbcol=seagreen]
>|||Thomas,
I just read your post and we are experiencing the same kind of error
here. The communication link failure is only occurring for clients
connecting from outside of the server's home subnet and the failure is
intermittent. Did you ever resolve your problems?
*** Sent via Developersdex http://www.codecomments.com ***sql

odbc connection call failed

I moved a sql 2000 database to a sql 2005 server. I have a front end in access 2003. I manually created an ODBC data source system DSN using the ODBC Data Source Administrator just like it was on the other server. I can connect fine but users are saying their getting an odbc call fail. I created the connection and relinked the tables to the new server with the moved database. I completed the same task with another database and the user can connect fine. What could be the problem?

You will have to look at the additional information of the ODBC call / error message. I guess they are not priviledged to access the database or even connct to the server.

Jens K. Suessmeyer.

http://www.sqlserver2005.de

ODBC and user accounts

2 questions:
When you set up a new System DSN to a SQL Server db, you have the option of
selecting NT Authentication or SQL authentication.
1. I have been told that Microsoft recommends NT authentication. I haven't
been able to find anything on the MS site or BOL which says so, though.
Anyone got a link I could use which says this?
2. If you use NT authentication, your username (whoever happened to sign
into Windows when creating this DSN) is there, grayed out. Does that matter?
Is that name going to be used in any way when this ODBC connection is used
programatically?
The best forum for this kind of question would be m.p.access.odbcclientsvr
or m.p.access.externaldata.
NT authentication is recommended because the password used doesn't travel in
clear text over the local network. If you have a virus or a trojan on your
LAN, this is the kind of thing that these malwares can catch.
When you use NT authentication, the active current account of the client
machine is always used for connecting to SQL-Server. The username is not
stored, so if you move the MDB file to another machine or if that you use
another account, the new active account will be used instead of the old one.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OqxxA13eHHA.3960@.TK2MSFTNGP02.phx.gbl...
>2 questions:
> When you set up a new System DSN to a SQL Server db, you have the option
> of selecting NT Authentication or SQL authentication.
> 1. I have been told that Microsoft recommends NT authentication. I haven't
> been able to find anything on the MS site or BOL which says so, though.
> Anyone got a link I could use which says this?
> 2. If you use NT authentication, your username (whoever happened to sign
> into Windows when creating this DSN) is there, grayed out. Does that
> matter? Is that name going to be used in any way when this ODBC connection
> is used programatically?
>
|||> The best forum for this kind of question would be m.p.access.odbcclientsvr
> or m.p.access.externaldata.
Even if it's for SQL Server?
|||Although I am not using Access, your answer most likely stil applies, so
thanks for the explanation.
|||Even if you are using SQL-Server as the backend, your question is only
relevant to the type of client used as the Frontend. Most people using ODBC
links are using Access, hence my suggestion for the forums. However, if you
are using something else as for your frontend, then the best place would be
on a newsgroup about this type of client.
SQL-Server really doesn't care about knowing if the frontend client at the
other side is storing or not the password or if it will reuse the same
username when launched from another machine.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:uZJGnZ4eHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Although I am not using Access, your answer most likely stil applies, so
> thanks for the explanation.
>
|||I am not sure what you mean. I am using SQL Server 2000 only. From the
server, (where my software is running), I set up an ODBC connection,
pointing to the database server. I am not using any front end.
|||You are in the particular case where both the frontend and the backend are
on the same physical machine. However, for the purpose of etablishing an
ODBC connection and reusing or not the same user account when the client
will reetablish later the connection, this doesn't change anything.
In what context are you using this ODBC connection? Are you using it for
etablishing a linked server or if you are using it for another application?
However, if things are currently working properly, then there is no need to
bother yourself with this any more; particularly if you are already using a
Trusted Connection.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
>
|||"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
Disregard the "other forum" suggestion. The basic information provided by
Sylvain applies, regardless of the application using ODBC to connect. It
also applies to any interface used to connect to sql server - odbc, dblib,
ole db, etc.
From a user perspective - the most important reason is that I don't need to
re-enter my security information (userID and password) every time I connect,
nor do I have to manage yet another password to access the dbms.
|||> However, if things are currently working properly, then there is no need
> to bother yourself with this any more;
I'm not bothering myself. I'm only continuing this conversation because you
sent me over to an Access group, when I am not using Access.
|||Hum, you asked in your OP if it does matter to etablish a DSN with or
without NT authentification when this DSN will be used later
programatically.
However, you didn't provide any info about what is exactly this
programmation; so the exact answer to your original question is *Yes*: it
Does matter because you can use this DSN to reconstruct a new DSN or to
etablish a DSN-Less connection with or without the same parameters.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OBP9yB6eHHA.3948@.TK2MSFTNGP03.phx.gbl...
> I'm not bothering myself. I'm only continuing this conversation because
> you sent me over to an Access group, when I am not using Access.
>

ODBC and user accounts

2 questions:
When you set up a new System DSN to a SQL Server db, you have the option of
selecting NT Authentication or SQL authentication.
1. I have been told that Microsoft recommends NT authentication. I haven't
been able to find anything on the MS site or BOL which says so, though.
Anyone got a link I could use which says this?
2. If you use NT authentication, your username (whoever happened to sign
into Windows when creating this DSN) is there, grayed out. Does that matter?
Is that name going to be used in any way when this ODBC connection is used
programatically?The best forum for this kind of question would be m.p.access.odbcclientsvr
or m.p.access.externaldata.
NT authentication is recommended because the password used doesn't travel in
clear text over the local network. If you have a virus or a trojan on your
LAN, this is the kind of thing that these malwares can catch.
When you use NT authentication, the active current account of the client
machine is always used for connecting to SQL-Server. The username is not
stored, so if you move the MDB file to another machine or if that you use
another account, the new active account will be used instead of the old one.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OqxxA13eHHA.3960@.TK2MSFTNGP02.phx.gbl...
>2 questions:
> When you set up a new System DSN to a SQL Server db, you have the option
> of selecting NT Authentication or SQL authentication.
> 1. I have been told that Microsoft recommends NT authentication. I haven't
> been able to find anything on the MS site or BOL which says so, though.
> Anyone got a link I could use which says this?
> 2. If you use NT authentication, your username (whoever happened to sign
> into Windows when creating this DSN) is there, grayed out. Does that
> matter? Is that name going to be used in any way when this ODBC connection
> is used programatically?
>|||> The best forum for this kind of question would be m.p.access.odbcclientsvr
> or m.p.access.externaldata.
Even if it's for SQL Server?|||Although I am not using Access, your answer most likely stil applies, so
thanks for the explanation.|||Even if you are using SQL-Server as the backend, your question is only
relevant to the type of client used as the Frontend. Most people using ODBC
links are using Access, hence my suggestion for the forums. However, if you
are using something else as for your frontend, then the best place would be
on a newsgroup about this type of client.
SQL-Server really doesn't care about knowing if the frontend client at the
other side is storing or not the password or if it will reuse the same
username when launched from another machine.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:uZJGnZ4eHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Although I am not using Access, your answer most likely stil applies, so
> thanks for the explanation.
>|||I am not sure what you mean. I am using SQL Server 2000 only. From the
server, (where my software is running), I set up an ODBC connection,
pointing to the database server. I am not using any front end.|||You are in the particular case where both the frontend and the backend are
on the same physical machine. However, for the purpose of etablishing an
ODBC connection and reusing or not the same user account when the client
will reetablish later the connection, this doesn't change anything.
In what context are you using this ODBC connection? Are you using it for
etablishing a linked server or if you are using it for another application?
However, if things are currently working properly, then there is no need to
bother yourself with this any more; particularly if you are already using a
Trusted Connection.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
>|||"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
Disregard the "other forum" suggestion. The basic information provided by
Sylvain applies, regardless of the application using ODBC to connect. It
also applies to any interface used to connect to sql server - odbc, dblib,
ole db, etc.
From a user perspective - the most important reason is that I don't need to
re-enter my security information (userID and password) every time I connect,
nor do I have to manage yet another password to access the dbms.|||> However, if things are currently working properly, then there is no need
> to bother yourself with this any more;
I'm not bothering myself. I'm only continuing this conversation because you
sent me over to an Access group, when I am not using Access.|||Hum, you asked in your OP if it does matter to etablish a DSN with or
without NT authentification when this DSN will be used later
programatically.
However, you didn't provide any info about what is exactly this
programmation; so the exact answer to your original question is *Yes*: it
Does matter because you can use this DSN to reconstruct a new DSN or to
etablish a DSN-Less connection with or without the same parameters.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OBP9yB6eHHA.3948@.TK2MSFTNGP03.phx.gbl...
>> However, if things are currently working properly, then there is no need
>> to bother yourself with this any more;
> I'm not bothering myself. I'm only continuing this conversation because
> you sent me over to an Access group, when I am not using Access.
>|||I think my question was misunderstood.
1. Is there an official Microsoft recommendation to use NT Authentication
rather than SQL Server authentication on the ODBC connection itself. The
answer is Yes, which I found after I posted.
2. When you choose NT authentication, the box at the bottom of that same
screen, where you would type in your username/password, is grayed out. But
you can still see the text of your login name. If grayed out, does this
login name get used in any way by the ODBC connection?|||« If grayed out, does this login name get used in any way by the ODBC
connection? »
No, any user name stored in a DSN will not be used when etablishing a
trusted connection; the current active account will always be used.
If you want to, you can change the rules - for exemple switching the DSN
from a trusted connection a SQL account; however, this is probably not what
you have in mind, otherwise, you wouldn't ask the question here.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:eJAR8$6eHHA.284@.TK2MSFTNGP05.phx.gbl...
>I think my question was misunderstood.
> 1. Is there an official Microsoft recommendation to use NT Authentication
> rather than SQL Server authentication on the ODBC connection itself. The
> answer is Yes, which I found after I posted.
> 2. When you choose NT authentication, the box at the bottom of that same
> screen, where you would type in your username/password, is grayed out. But
> you can still see the text of your login name. If grayed out, does this
> login name get used in any way by the ODBC connection?
>|||Thanks!
> No, any user name stored in a DSN will not be used when etablishing a
> trusted connection; the current active account will always be used.

ODBC and user accounts

2 questions:
When you set up a new System DSN to a SQL Server db, you have the option of
selecting NT Authentication or SQL authentication.
1. I have been told that Microsoft recommends NT authentication. I haven't
been able to find anything on the MS site or BOL which says so, though.
Anyone got a link I could use which says this?
2. If you use NT authentication, your username (whoever happened to sign
into Windows when creating this DSN) is there, grayed out. Does that matter?
Is that name going to be used in any way when this ODBC connection is used
programatically?The best forum for this kind of question would be m.p.access.odbcclientsvr
or m.p.access.externaldata.
NT authentication is recommended because the password used doesn't travel in
clear text over the local network. If you have a virus or a trojan on your
LAN, this is the kind of thing that these malwares can catch.
When you use NT authentication, the active current account of the client
machine is always used for connecting to SQL-Server. The username is not
stored, so if you move the MDB file to another machine or if that you use
another account, the new active account will be used instead of the old one.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OqxxA13eHHA.3960@.TK2MSFTNGP02.phx.gbl...
>2 questions:
> When you set up a new System DSN to a SQL Server db, you have the option
> of selecting NT Authentication or SQL authentication.
> 1. I have been told that Microsoft recommends NT authentication. I haven't
> been able to find anything on the MS site or BOL which says so, though.
> Anyone got a link I could use which says this?
> 2. If you use NT authentication, your username (whoever happened to sign
> into Windows when creating this DSN) is there, grayed out. Does that
> matter? Is that name going to be used in any way when this ODBC connection
> is used programatically?
>|||> The best forum for this kind of question would be m.p.access.odbcclientsvr
> or m.p.access.externaldata.
Even if it's for SQL Server?|||Although I am not using Access, your answer most likely stil applies, so
thanks for the explanation.|||Even if you are using SQL-Server as the backend, your question is only
relevant to the type of client used as the Frontend. Most people using ODBC
links are using Access, hence my suggestion for the forums. However, if you
are using something else as for your frontend, then the best place would be
on a newsgroup about this type of client.
SQL-Server really doesn't care about knowing if the frontend client at the
other side is storing or not the password or if it will reuse the same
username when launched from another machine.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:uZJGnZ4eHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Although I am not using Access, your answer most likely stil applies, so
> thanks for the explanation.
>|||I am not sure what you mean. I am using SQL Server 2000 only. From the
server, (where my software is running), I set up an ODBC connection,
pointing to the database server. I am not using any front end.|||You are in the particular case where both the frontend and the backend are
on the same physical machine. However, for the purpose of etablishing an
ODBC connection and reusing or not the same user account when the client
will reetablish later the connection, this doesn't change anything.
In what context are you using this ODBC connection? Are you using it for
etablishing a linked server or if you are using it for another application?
However, if things are currently working properly, then there is no need to
bother yourself with this any more; particularly if you are already using a
Trusted Connection.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
>|||"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:%23$PDWG5eHHA.2640@.TK2MSFTNGP06.phx.gbl...
>I am not sure what you mean. I am using SQL Server 2000 only. From the
>server, (where my software is running), I set up an ODBC connection,
>pointing to the database server. I am not using any front end.
Disregard the "other forum" suggestion. The basic information provided by
Sylvain applies, regardless of the application using ODBC to connect. It
also applies to any interface used to connect to sql server - odbc, dblib,
ole db, etc.
From a user perspective - the most important reason is that I don't need to
re-enter my security information (userID and password) every time I connect,
nor do I have to manage yet another password to access the dbms.|||> However, if things are currently working properly, then there is no need
> to bother yourself with this any more;
I'm not bothering myself. I'm only continuing this conversation because you
sent me over to an Access group, when I am not using Access.|||Hum, you asked in your OP if it does matter to etablish a DSN with or
without NT authentification when this DSN will be used later
programatically.
However, you didn't provide any info about what is exactly this
programmation; so the exact answer to your original question is *Yes*: it
Does matter because you can use this DSN to reconstruct a new DSN or to
etablish a DSN-Less connection with or without the same parameters.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"Middletree" <middletree@.hottttttttmail.com> wrote in message
news:OBP9yB6eHHA.3948@.TK2MSFTNGP03.phx.gbl...
> I'm not bothering myself. I'm only continuing this conversation because
> you sent me over to an Access group, when I am not using Access.
>

odbc + sql problem

Anyone could please help me ?
I have a simple asp program connecting to sql7.0.
I have the system dsn setup already.
After I transfer everything from the old hard disk to new hard disk, I
cannot login through asp program anymore. Below is the error message but I
don't know why it has to do with the iusr account. Thanks a lot. (any image
of setup would be helpful)
Microsoft OLE DB Provider for ODBC Drivers (0x80040E4D)
[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for
user
'CENTRAL\IUSR_CENTRAL'.So, the error message is that this user:
doesn't exist as a SQL login.
Microsoft OLE DB Provider for ODBC Drivers (0x80040E4D)
[Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for
user
'CENTRAL\IUSR_CENTRAL'.
175671 PRB: 80004005 ConnectionOpen (CreateFile()) Error Accessing SQL
http://support.microsoft.com/?id=175671
307002 PRB: ASP/ODBC/SQL Server Error 0x80040E4D "Login Failed for User
http://support.microsoft.com/?id=307002
176380 How To Use ASP with a SQL Trusted Connection with Guest Account
http://support.microsoft.com/?id=176380
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.

ODBC & Remote SQL Server

Hello,

How to create system DSN (ODBC) on windows 2003 for SQL Server located
on remote machine ?

Please, guide me.

Bye.On Sep 18, 10:07 am, pradeep <pwprad...@.gmail.comwrote:

Quote:

Originally Posted by

Hello,
>
How to create system DSN (ODBC) on windows 2003 for SQL Server located
on remote machine ?
>
Please, guide me.
>
Bye.

Go to control panel-->Click administrative tools --click data
sources(odbc)

select system DSN tab
1) Click Add
2)provide a name using which you will be refering in name
3) in server column,select or type server name you want to connect
4)provide security details in next page
5)select default database name if you want
6)in next page click Finish
7) you get test screen ,now click Test data source to test the
connection ..if success you are in or else you need to check details

Thanks
VS

ODBC - System DSN window is blank

We've run into a few XP machines in our organization that have some interesting quirk going on. We have several ODBC connections configured on the machines. However, when you go to ODBC connections, then click on the System DSN tab, it's empty. If we try to manually create a "missing" odbc, it says it already exists, do you want to overwrite, etc. We say yes, but it still doesn't appear. The main program being used has a dropdown box at the login screen that shows the various ODBC names to choose from. The ones from the System DSN tab (which is blank anyway) are not listed. However, if you manually type in the name of the ODBC that is supposedly configured but doesn't show up, it works. So, it sees the ODBC, but it won't display it to the human eye in the settings or drop down lists. What's up with that? We've tried reinstalling MDAC, java, windows updates, etc, etc. Only some machines are affected. I am unable to tell you what's been done to all these machines. The users are all set as admins on their machines. They all run similar software, etc. The only thing that happened around the time we started noticing this is that we added a couple new ODBCs and changed the settings in an existing one. We sent an exe to all users in the organization that auto configures these ODBC's so we don't have to do it manually. It works awesome, but I don't see how that exe could have caused this problem especially when the problem seems to have only shown up on about 1% of the PCs it was applied to.Found this at: http://www.dbforums.com/t1055278.html

01-01-05, 01:37
wconner50
Registered User

Join Date: Jan 2005
Posts: 2
System DSN not in ODBC Manager
You should export the registry entries for the ODBC.INI Data source and DataSet Names. Then edit the .reg exported file and see if there are any odd lines of text. I found a corrupt entry in the ODBC Data Source registry entry, all the missing system DSN's were right after the corrupt line. Delete corrupt line and deleted ODBC Data Source registry entry, then imported .reg file.

Problem was resolved.