|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
ODBC Errors?Windows 2003 Enterprise Server (Production Server) SQL Server 2000 Standard Edition (with Service Pack 4 installed) Windows 2003 Enterprise Server (Test Server) SQL Server 2000 Enterprise (with Service Pack 4 installed) I'm getting three different ODBC error: >> Error At:Login: SQLConnect SQL RC:-1State:HYT00 SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired SQL Native Error Code:0 >> Error At:Login: SQLConnect SQL RC:-1State:08001 SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL Server does not exist or access denied. SQL Native Error Code:17 >> Error At:Login: SQLConnect SQL RC:-1State:01000 SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed database context to 'CDMS8'. SQL Native Error Code:5701 These error are on our production server only, on my test server which is the same configuration, I don't get any of these ODBC errors. In both cases the SQL Server is "local" to both machines. So their no possibility of network traffic, Firewalls, bad cables, etc. What would cause these errors? Thanks, Weston Fryatt Sr. Software Engineer The SSI Group, Inc. I am not sure about this, but if your connection string specifies the server
by name, there may be a chance that the application is actually going accross the network even though it does not need to. Again, I don't know if this is the case, but I have seen other applications and database platforms behave this way. How often are you getting these errors? Does it sometimes work, or not at all? Show quote "Weston Fryatt" <wfry***@gmail.com> wrote in message news:ORtAldQzGHA.1936@TK2MSFTNGP06.phx.gbl... > Environment: > Windows 2003 Enterprise Server (Production Server) > SQL Server 2000 Standard Edition (with Service Pack 4 installed) > > Windows 2003 Enterprise Server (Test Server) > SQL Server 2000 Enterprise (with Service Pack 4 installed) > > > I'm getting three different ODBC error: > > >> Error At:Login: SQLConnect > SQL RC:-1 > State:HYT00 > SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired > SQL Native Error Code:0 > > >> Error At:Login: SQLConnect > SQL RC:-1 > State:08001 > SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL Server > does not exist or access denied. > SQL Native Error Code:17 > > >> Error At:Login: SQLConnect > SQL RC:-1 > State:01000 > SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed > database context to 'CDMS8'. > SQL Native Error Code:5701 > > > These error are on our production server only, on my test server which is > the same configuration, I don't get any of these ODBC errors. In both cases > the SQL Server is "local" to both machines. So their no possibility of > network traffic, Firewalls, bad cables, etc. > > What would cause these errors? > > Thanks, > Weston Fryatt > Sr. Software Engineer > The SSI Group, Inc. > > > You in my ODBC setup of the System DSN? You might be right, I'll have to
double check that. But instead of using a SQL Connect string, I'm using ODBC's SQLConnect and passing in the ODBC DSN name, UserID and Password for the connection. It probably works about 80% or more of the time, and fails about 20% of the time.. I have the problem pretty much patched with a hacked work around... I just go into a retry loop until it connects... but I should have to do this. And on my test server, I can't make it fail, even under load. Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:uGZcy$RzGHA.1292@TK2MSFTNGP03.phx.gbl... >I am not sure about this, but if your connection string specifies the >server > by name, there may be a chance that the application is actually going > accross the network even though it does not need to. Again, I don't know > if > this is the case, but I have seen other applications and database > platforms > behave this way. > > How often are you getting these errors? Does it sometimes work, or not at > all? > > "Weston Fryatt" <wfry***@gmail.com> wrote in message > news:ORtAldQzGHA.1936@TK2MSFTNGP06.phx.gbl... >> Environment: >> Windows 2003 Enterprise Server (Production Server) >> SQL Server 2000 Standard Edition (with Service Pack 4 installed) >> >> Windows 2003 Enterprise Server (Test Server) >> SQL Server 2000 Enterprise (with Service Pack 4 installed) >> >> >> I'm getting three different ODBC error: >> >> >> Error At:Login: SQLConnect >> SQL RC:-1 >> State:HYT00 >> SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired >> SQL Native Error Code:0 >> >> >> Error At:Login: SQLConnect >> SQL RC:-1 >> State:08001 >> SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL > Server >> does not exist or access denied. >> SQL Native Error Code:17 >> >> >> Error At:Login: SQLConnect >> SQL RC:-1 >> State:01000 >> SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed >> database context to 'CDMS8'. >> SQL Native Error Code:5701 >> >> >> These error are on our production server only, on my test server which is >> the same configuration, I don't get any of these ODBC errors. In both > cases >> the SQL Server is "local" to both machines. So their no possibility of >> network traffic, Firewalls, bad cables, etc. >> >> What would cause these errors? >> >> Thanks, >> Weston Fryatt >> Sr. Software Engineer >> The SSI Group, Inc. >> >> >> > > One issue with your loop...
If the database actually goes down, you can get stuck in an endless loop trying to connect. You probably want to have it try a maximum number of times then give up. I'm not sure what to suggest, but you will probably get more help in an ODBC group than here. Show quote "Weston Fryatt" <wfry***@gmail.com> wrote in message news:urJ$1TSzGHA.3464@TK2MSFTNGP03.phx.gbl... > You in my ODBC setup of the System DSN? You might be right, I'll have to > double check that. > > But instead of using a SQL Connect string, I'm using ODBC's SQLConnect and > passing in the ODBC DSN name, UserID and Password for the connection. It > probably works about 80% or more of the time, and fails about 20% of the > time.. I have the problem pretty much patched with a hacked work around... I > just go into a retry loop until it connects... but I should have to do this. > And on my test server, I can't make it fail, even under load. > > > > > "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > news:uGZcy$RzGHA.1292@TK2MSFTNGP03.phx.gbl... > >I am not sure about this, but if your connection string specifies the > >server > > by name, there may be a chance that the application is actually going > > accross the network even though it does not need to. Again, I don't know > > if > > this is the case, but I have seen other applications and database > > platforms > > behave this way. > > > > How often are you getting these errors? Does it sometimes work, or not at > > all? > > > > "Weston Fryatt" <wfry***@gmail.com> wrote in message > > news:ORtAldQzGHA.1936@TK2MSFTNGP06.phx.gbl... > >> Environment: > >> Windows 2003 Enterprise Server (Production Server) > >> SQL Server 2000 Standard Edition (with Service Pack 4 installed) > >> > >> Windows 2003 Enterprise Server (Test Server) > >> SQL Server 2000 Enterprise (with Service Pack 4 installed) > >> > >> > >> I'm getting three different ODBC error: > >> > >> >> Error At:Login: SQLConnect > >> SQL RC:-1 > >> State:HYT00 > >> SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired > >> SQL Native Error Code:0 > >> > >> >> Error At:Login: SQLConnect > >> SQL RC:-1 > >> State:08001 > >> SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL > > Server > >> does not exist or access denied. > >> SQL Native Error Code:17 > >> > >> >> Error At:Login: SQLConnect > >> SQL RC:-1 > >> State:01000 > >> SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed > >> database context to 'CDMS8'. > >> SQL Native Error Code:5701 > >> > >> > >> These error are on our production server only, on my test server which is > >> the same configuration, I don't get any of these ODBC errors. In both > > cases > >> the SQL Server is "local" to both machines. So their no possibility of > >> network traffic, Firewalls, bad cables, etc. > >> > >> What would cause these errors? > >> > >> Thanks, > >> Weston Fryatt > >> Sr. Software Engineer > >> The SSI Group, Inc. > >> > >> > >> > > > > > > I hate to state the obvious but the first step is to make sure the two
servers are in fact configured the same. I suspect they are not. For example, the 5701 error is not really an error. It just says the connection switched to a different database after connecting. This might mean that the database specified in your DSN and the default database specified for the user are not the same. If you're using Windows authentication then there may be differences in the response time for your domain controller which could explain some of the other errors. One of the database could be configured for autoclose. The users you are logging in as on your test machine may be different than the ones of the production box, etc. I'm not an ODBC expert but I've worked on enough problems to know that identical systems seldom are identical. -- Show quoteThis posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:O8ACydSzGHA.4844@TK2MSFTNGP04.phx.gbl... > One issue with your loop... > > If the database actually goes down, you can get stuck in an endless loop > trying to connect. > > You probably want to have it try a maximum number of times then give up. > > I'm not sure what to suggest, but you will probably get more help in an > ODBC > group than here. > > "Weston Fryatt" <wfry***@gmail.com> wrote in message > news:urJ$1TSzGHA.3464@TK2MSFTNGP03.phx.gbl... >> You in my ODBC setup of the System DSN? You might be right, I'll have to >> double check that. >> >> But instead of using a SQL Connect string, I'm using ODBC's SQLConnect >> and >> passing in the ODBC DSN name, UserID and Password for the connection. It >> probably works about 80% or more of the time, and fails about 20% of the >> time.. I have the problem pretty much patched with a hacked work >> around... > I >> just go into a retry loop until it connects... but I should have to do > this. >> And on my test server, I can't make it fail, even under load. >> >> >> >> >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >> news:uGZcy$RzGHA.1292@TK2MSFTNGP03.phx.gbl... >> >I am not sure about this, but if your connection string specifies the >> >server >> > by name, there may be a chance that the application is actually going >> > accross the network even though it does not need to. Again, I don't > know >> > if >> > this is the case, but I have seen other applications and database >> > platforms >> > behave this way. >> > >> > How often are you getting these errors? Does it sometimes work, or not > at >> > all? >> > >> > "Weston Fryatt" <wfry***@gmail.com> wrote in message >> > news:ORtAldQzGHA.1936@TK2MSFTNGP06.phx.gbl... >> >> Environment: >> >> Windows 2003 Enterprise Server (Production Server) >> >> SQL Server 2000 Standard Edition (with Service Pack 4 installed) >> >> >> >> Windows 2003 Enterprise Server (Test Server) >> >> SQL Server 2000 Enterprise (with Service Pack 4 installed) >> >> >> >> >> >> I'm getting three different ODBC error: >> >> >> >> >> Error At:Login: SQLConnect >> >> SQL RC:-1 >> >> State:HYT00 >> >> SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired >> >> SQL Native Error Code:0 >> >> >> >> >> Error At:Login: SQLConnect >> >> SQL RC:-1 >> >> State:08001 >> >> SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL >> > Server >> >> does not exist or access denied. >> >> SQL Native Error Code:17 >> >> >> >> >> Error At:Login: SQLConnect >> >> SQL RC:-1 >> >> State:01000 >> >> SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed >> >> database context to 'CDMS8'. >> >> SQL Native Error Code:5701 >> >> >> >> >> >> These error are on our production server only, on my test server which > is >> >> the same configuration, I don't get any of these ODBC errors. In both >> > cases >> >> the SQL Server is "local" to both machines. So their no possibility of >> >> network traffic, Firewalls, bad cables, etc. >> >> >> >> What would cause these errors? >> >> >> >> Thanks, >> >> Weston Fryatt >> >> Sr. Software Engineer >> >> The SSI Group, Inc. >> >> >> >> >> >> >> > >> > >> >> > >
Show quote
"Roger Wolter[MSFT]" <rwol***@online.microsoft.com> wrote in message
news:uitccUTzGHA.2208@TK2MSFTNGP03.phx.gbl... >I hate to state the obvious but the first step is to make sure the two >servers are in fact configured the same. I suspect they are not. For >example, the 5701 error is not really an error. It just says the >connection switched to a different database after connecting. This might >mean that the database specified in your DSN and the default database >specified for the user are not the same. If you're using Windows >authentication then there may be differences in the response time for your >domain controller which could explain some of the other errors. One of the >database could be configured for autoclose. The users you are logging in >as on your test machine may be different than the ones of the production >box, etc. I'm not an ODBC expert but I've worked on enough problems to >know that identical systems seldom are identical. > > -- > This posting is provided "AS IS" with no warranties, and confers no > rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm > > "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > news:O8ACydSzGHA.4844@TK2MSFTNGP04.phx.gbl... >> One issue with your loop... >> >> If the database actually goes down, you can get stuck in an endless loop >> trying to connect. >> >> You probably want to have it try a maximum number of times then give up. >> >> I'm not sure what to suggest, but you will probably get more help in an >> ODBC >> group than here. >> >> "Weston Fryatt" <wfry***@gmail.com> wrote in message >> news:urJ$1TSzGHA.3464@TK2MSFTNGP03.phx.gbl... >>> You in my ODBC setup of the System DSN? You might be right, I'll have >>> to >>> double check that. >>> >>> But instead of using a SQL Connect string, I'm using ODBC's SQLConnect >>> and >>> passing in the ODBC DSN name, UserID and Password for the connection. >>> It >>> probably works about 80% or more of the time, and fails about 20% of the >>> time.. I have the problem pretty much patched with a hacked work >>> around... >> I >>> just go into a retry loop until it connects... but I should have to do >> this. >>> And on my test server, I can't make it fail, even under load. >>> >>> >>> >>> >>> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >>> news:uGZcy$RzGHA.1292@TK2MSFTNGP03.phx.gbl... >>> >I am not sure about this, but if your connection string specifies the >>> >server >>> > by name, there may be a chance that the application is actually going >>> > accross the network even though it does not need to. Again, I don't >> know >>> > if >>> > this is the case, but I have seen other applications and database >>> > platforms >>> > behave this way. >>> > >>> > How often are you getting these errors? Does it sometimes work, or >>> > not >> at >>> > all? >>> > >>> > "Weston Fryatt" <wfry***@gmail.com> wrote in message >>> > news:ORtAldQzGHA.1936@TK2MSFTNGP06.phx.gbl... >>> >> Environment: >>> >> Windows 2003 Enterprise Server (Production Server) >>> >> SQL Server 2000 Standard Edition (with Service Pack 4 installed) >>> >> >>> >> Windows 2003 Enterprise Server (Test Server) >>> >> SQL Server 2000 Enterprise (with Service Pack 4 installed) >>> >> >>> >> >>> >> I'm getting three different ODBC error: >>> >> >>> >> >> Error At:Login: SQLConnect >>> >> SQL RC:-1 >>> >> State:HYT00 >>> >> SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired >>> >> SQL Native Error Code:0 >>> >> >>> >> >> Error At:Login: SQLConnect >>> >> SQL RC:-1 >>> >> State:08001 >>> >> SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL >>> > Server >>> >> does not exist or access denied. >>> >> SQL Native Error Code:17 >>> >> >>> >> >> Error At:Login: SQLConnect >>> >> SQL RC:-1 >>> >> State:01000 >>> >> SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed >>> >> database context to 'CDMS8'. >>> >> SQL Native Error Code:5701 >>> >> >>> >> >>> >> These error are on our production server only, on my test server >>> >> which >> is >>> >> the same configuration, I don't get any of these ODBC errors. In >>> >> both >>> > cases >>> >> the SQL Server is "local" to both machines. So their no possibility >>> >> of >>> >> network traffic, Firewalls, bad cables, etc. >>> >> >>> >> What would cause these errors? >>> >> >>> >> Thanks, >>> >> Weston Fryatt >>> >> Sr. Software Engineer >>> >> The SSI Group, Inc. >>> >> >>> >> >>> >> >>> > >>> > >>> >>> >> >> > > Its hard to compare both system since they are not on the same floor and can
not use RDP to check. But I just came back from the server room and double checked the ODBC System DSN setting and they are the same as my settings on the test server. We're using Mixed Mode for authentication and logging in as the "sa" account. The default database is set to the correct database. Anyway, Thanks all of your help and idea, I'm going to repost my problem in the ODBC group and see if they have any other ideas. Show quote "Roger Wolter[MSFT]" <rwol***@online.microsoft.com> wrote in message news:uitccUTzGHA.2208@TK2MSFTNGP03.phx.gbl... >I hate to state the obvious but the first step is to make sure the two >servers are in fact configured the same. I suspect they are not. For >example, the 5701 error is not really an error. It just says the >connection switched to a different database after connecting. This might >mean that the database specified in your DSN and the default database >specified for the user are not the same. If you're using Windows >authentication then there may be differences in the response time for your >domain controller which could explain some of the other errors. One of the >database could be configured for autoclose. The users you are logging in >as on your test machine may be different than the ones of the production >box, etc. I'm not an ODBC expert but I've worked on enough problems to >know that identical systems seldom are identical. > > -- > This posting is provided "AS IS" with no warranties, and confers no > rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm > > "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message > news:O8ACydSzGHA.4844@TK2MSFTNGP04.phx.gbl... >> One issue with your loop... >> >> If the database actually goes down, you can get stuck in an endless loop >> trying to connect. >> >> You probably want to have it try a maximum number of times then give up. >> >> I'm not sure what to suggest, but you will probably get more help in an >> ODBC >> group than here. >> >> "Weston Fryatt" <wfry***@gmail.com> wrote in message >> news:urJ$1TSzGHA.3464@TK2MSFTNGP03.phx.gbl... >>> You in my ODBC setup of the System DSN? You might be right, I'll have >>> to >>> double check that. >>> >>> But instead of using a SQL Connect string, I'm using ODBC's SQLConnect >>> and >>> passing in the ODBC DSN name, UserID and Password for the connection. >>> It >>> probably works about 80% or more of the time, and fails about 20% of the >>> time.. I have the problem pretty much patched with a hacked work >>> around... >> I >>> just go into a retry loop until it connects... but I should have to do >> this. >>> And on my test server, I can't make it fail, even under load. >>> >>> >>> >>> >>> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >>> news:uGZcy$RzGHA.1292@TK2MSFTNGP03.phx.gbl... >>> >I am not sure about this, but if your connection string specifies the >>> >server >>> > by name, there may be a chance that the application is actually going >>> > accross the network even though it does not need to. Again, I don't >> know >>> > if >>> > this is the case, but I have seen other applications and database >>> > platforms >>> > behave this way. >>> > >>> > How often are you getting these errors? Does it sometimes work, or >>> > not >> at >>> > all? >>> > >>> > "Weston Fryatt" <wfry***@gmail.com> wrote in message >>> > news:ORtAldQzGHA.1936@TK2MSFTNGP06.phx.gbl... >>> >> Environment: >>> >> Windows 2003 Enterprise Server (Production Server) >>> >> SQL Server 2000 Standard Edition (with Service Pack 4 installed) >>> >> >>> >> Windows 2003 Enterprise Server (Test Server) >>> >> SQL Server 2000 Enterprise (with Service Pack 4 installed) >>> >> >>> >> >>> >> I'm getting three different ODBC error: >>> >> >>> >> >> Error At:Login: SQLConnect >>> >> SQL RC:-1 >>> >> State:HYT00 >>> >> SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired >>> >> SQL Native Error Code:0 >>> >> >>> >> >> Error At:Login: SQLConnect >>> >> SQL RC:-1 >>> >> State:08001 >>> >> SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL >>> > Server >>> >> does not exist or access denied. >>> >> SQL Native Error Code:17 >>> >> >>> >> >> Error At:Login: SQLConnect >>> >> SQL RC:-1 >>> >> State:01000 >>> >> SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed >>> >> database context to 'CDMS8'. >>> >> SQL Native Error Code:5701 >>> >> >>> >> >>> >> These error are on our production server only, on my test server >>> >> which >> is >>> >> the same configuration, I don't get any of these ODBC errors. In >>> >> both >>> > cases >>> >> the SQL Server is "local" to both machines. So their no possibility >>> >> of >>> >> network traffic, Firewalls, bad cables, etc. >>> >> >>> >> What would cause these errors? >>> >> >>> >> Thanks, >>> >> Weston Fryatt >>> >> Sr. Software Engineer >>> >> The SSI Group, Inc. >>> >> >>> >> >>> >> >>> > >>> > >>> >>> >> >> > > The retry loop does have a limit of 10 retries and so far I haven't seen it
fail because it ran out of retries. Sometimes it can takes it 5 or 6 times trying to login (SQLConnect). I'll try posting my problem over in the ODBC group and see if anyone else there has any ideas. Thanks for all of your help! Show quote "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message news:O8ACydSzGHA.4844@TK2MSFTNGP04.phx.gbl... > One issue with your loop... > > If the database actually goes down, you can get stuck in an endless loop > trying to connect. > > You probably want to have it try a maximum number of times then give up. > > I'm not sure what to suggest, but you will probably get more help in an > ODBC > group than here. > > "Weston Fryatt" <wfry***@gmail.com> wrote in message > news:urJ$1TSzGHA.3464@TK2MSFTNGP03.phx.gbl... >> You in my ODBC setup of the System DSN? You might be right, I'll have to >> double check that. >> >> But instead of using a SQL Connect string, I'm using ODBC's SQLConnect >> and >> passing in the ODBC DSN name, UserID and Password for the connection. It >> probably works about 80% or more of the time, and fails about 20% of the >> time.. I have the problem pretty much patched with a hacked work >> around... > I >> just go into a retry loop until it connects... but I should have to do > this. >> And on my test server, I can't make it fail, even under load. >> >> >> >> >> "Jim Underwood" <james.underwoodATfallonclinic.com> wrote in message >> news:uGZcy$RzGHA.1292@TK2MSFTNGP03.phx.gbl... >> >I am not sure about this, but if your connection string specifies the >> >server >> > by name, there may be a chance that the application is actually going >> > accross the network even though it does not need to. Again, I don't > know >> > if >> > this is the case, but I have seen other applications and database >> > platforms >> > behave this way. >> > >> > How often are you getting these errors? Does it sometimes work, or not > at >> > all? >> > >> > "Weston Fryatt" <wfry***@gmail.com> wrote in message >> > news:ORtAldQzGHA.1936@TK2MSFTNGP06.phx.gbl... >> >> Environment: >> >> Windows 2003 Enterprise Server (Production Server) >> >> SQL Server 2000 Standard Edition (with Service Pack 4 installed) >> >> >> >> Windows 2003 Enterprise Server (Test Server) >> >> SQL Server 2000 Enterprise (with Service Pack 4 installed) >> >> >> >> >> >> I'm getting three different ODBC error: >> >> >> >> >> Error At:Login: SQLConnect >> >> SQL RC:-1 >> >> State:HYT00 >> >> SQL Error:[Microsoft][ODBC SQL Server Driver]Timeout expired >> >> SQL Native Error Code:0 >> >> >> >> >> Error At:Login: SQLConnect >> >> SQL RC:-1 >> >> State:08001 >> >> SQL Error:[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SQL >> > Server >> >> does not exist or access denied. >> >> SQL Native Error Code:17 >> >> >> >> >> Error At:Login: SQLConnect >> >> SQL RC:-1 >> >> State:01000 >> >> SQL Error:[Microsoft][ODBC SQL Server Driver][SQL Server]Changed >> >> database context to 'CDMS8'. >> >> SQL Native Error Code:5701 >> >> >> >> >> >> These error are on our production server only, on my test server which > is >> >> the same configuration, I don't get any of these ODBC errors. In both >> > cases >> >> the SQL Server is "local" to both machines. So their no possibility of >> >> network traffic, Firewalls, bad cables, etc. >> >> >> >> What would cause these errors? >> >> >> >> Thanks, >> >> Weston Fryatt >> >> Sr. Software Engineer >> >> The SSI Group, Inc. >> >> >> >> >> >> >> > >> > >> >> > >  |
|||||||||||||||||||||||
Other interesting topics