+ Reply to Thread
Results 1 to 7 of 7

SQLConnect

  1. SQLConnect

    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.

    I've already check and the ODBC System DSN is set to use "local host" as the
    name of the server to connect to, We use "Mixed Mode" and login as the "sa"
    account. Also the default database is set to the correct named database.

    What would cause these errors?

    Thanks,
    Weston Fryatt
    Sr. Software Engineer
    The SSI Group, Inc.





  2. Re: SQLConnect

    I would guess though that your test machine doesn't get the
    same traffic and the same activity as the production server.
    So it really isn't odd to have issues in one environment and
    not the other even with the same configurations.
    The first one...locking or blocking issues could do that,
    UMS issues, a lot of things. You need to be monitoring the
    server to see what's going on when this happens.

    The second one...a lot of things. Refer to the following for
    more information:
    Potential causes of the "SQL Server does not exist or access
    denied" error message
    http://support.microsoft.com/?id=328306

    The third one is not an error. That's an informational
    message which can be ignored. You'd need to handle
    informational messages in your app.

    -Sue

    On Fri, 1 Sep 2006 08:20:22 -0500, "Weston Fryatt"
    wrote:

    >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.
    >
    >I've already check and the ODBC System DSN is set to use "local host" as the
    >name of the server to connect to, We use "Mixed Mode" and login as the "sa"
    >account. Also the default database is set to the correct named database.
    >
    >What would cause these errors?
    >
    >Thanks,
    >Weston Fryatt
    >Sr. Software Engineer
    >The SSI Group, Inc.
    >
    >
    >



  3. Re: SQLConnect

    I would guess though that your test machine doesn't get the
    same traffic and the same activity as the production server.
    So it really isn't odd to have issues in one environment and
    not the other even with the same configurations.
    The first one...locking or blocking issues could do that,
    UMS issues, a lot of things. You need to be monitoring the
    server to see what's going on when this happens.

    The second one...a lot of things. Refer to the following for
    more information:
    Potential causes of the "SQL Server does not exist or access
    denied" error message
    http://support.microsoft.com/?id=328306

    The third one is not an error. That's an informational
    message which can be ignored. You'd need to handle
    informational messages in your app.

    -Sue

    On Fri, 1 Sep 2006 08:20:22 -0500, "Weston Fryatt"
    wrote:

    >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.
    >
    >I've already check and the ODBC System DSN is set to use "local host" as the
    >name of the server to connect to, We use "Mixed Mode" and login as the "sa"
    >account. Also the default database is set to the correct named database.
    >
    >What would cause these errors?
    >
    >Thanks,
    >Weston Fryatt
    >Sr. Software Engineer
    >The SSI Group, Inc.
    >
    >
    >



  4. Re: SQLConnect


    "Sue Hoegemeier" wrote in message
    newsao0g21kmmjma646aai2e02adbevaf3p8t@4ax.com...
    >I would guess though that your test machine doesn't get the
    > same traffic and the same activity as the production server.


    Actually, I have configured the test server to process the same data as the
    production server. The Test server has never had any of thes error in its
    log. The only different here is SQL Server, Production is running SQL Server
    2000 Standard Edition, and Test Server is running SQL 2000 Server Enterprise
    Edition (MSDN Version). Both server are running Windows 2003 Server
    Enterprise with current service packs.

    Both servers (hardward) are the same, HP ProLaint ML 350 (Dual Xeon 3.06Ghz
    with 4 gig of memory). The only major difference between the two machine is
    my test server is a tower version and the production server is a rack mount.

    I've had this problem for a while, but have a hacked workaround. I was told
    some months ago that Serivce Pack 4 for SQL Server 2000 would solve all of
    my problems, but never did, And I haven't had the time to followup.

    > So it really isn't odd to have issues in one environment and
    > not the other even with the same configurations.
    > The first one...locking or blocking issues could do that,
    > UMS issues, a lot of things. You need to be monitoring the
    > server to see what's going on when this happens.


    It very well could be a locking and blocking issue, but why don't I see the
    some problem on the test server running the same data and same load? Is
    there that much of a difference between SQL Server 2000 Enterprise vers
    Standard? Could that be the problem?

    Background information: The application the processes the data is completely
    multitreaded client/server app using RPC. Since RPC can make "x" number of
    connections to the server app at the same time, I have to log into the
    database (using ODBC SQLConnect) on each RPC function call. So I could have
    1 or 2 database login or I could have hundreds. (Both boxes right now are
    using the "sa" SQL Account to login). As each function call fall out of
    scope, I close the database connection.

    Anymore idea? I'd like to try putting SQL Server 2000 Enterprise (MSDN) on
    the production server as a test, but my IS department won't allow me because
    that would violate our license. And they don't want to buy a Enterprise
    edition just to test this theory.

    Any other ideas, comments or suggestions?

    Thanks,
    Weston Fryatt



    > The second one...a lot of things. Refer to the following for
    > more information:
    > Potential causes of the "SQL Server does not exist or access
    > denied" error message
    > http://support.microsoft.com/?id=328306


    The server apps and SQL Server both run on the same server so there
    shouldn't be any network traffic because all of the connections even though
    they are TCP are all local to the same box. I have checked the System DSN
    for my ODBC connection and it using "localhost" instead of the machine name,
    so there shouldn't be any DNS issues trying to figure out where this machine
    is.

    > The third one is not an error. That's an informational
    > message which can be ignored. You'd need to handle
    > informational messages in your app.


    Even though this isn't an error, It still bothers me that this warning, only
    shows up on the production server and not the test server.




    >
    > -Sue
    >
    > On Fri, 1 Sep 2006 08:20:22 -0500, "Weston Fryatt"
    > wrote:
    >
    >>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.
    >>
    >>I've already check and the ODBC System DSN is set to use "local host" as
    >>the
    >>name of the server to connect to, We use "Mixed Mode" and login as the
    >>"sa"
    >>account. Also the default database is set to the correct named database.
    >>
    >>What would cause these errors?
    >>
    >>Thanks,
    >>Weston Fryatt
    >>Sr. Software Engineer
    >>The SSI Group, Inc.
    >>
    >>
    >>

    >




  5. Re: SQLConnect


    "Sue Hoegemeier" wrote in message
    newsao0g21kmmjma646aai2e02adbevaf3p8t@4ax.com...
    >I would guess though that your test machine doesn't get the
    > same traffic and the same activity as the production server.


    Actually, I have configured the test server to process the same data as the
    production server. The Test server has never had any of thes error in its
    log. The only different here is SQL Server, Production is running SQL Server
    2000 Standard Edition, and Test Server is running SQL 2000 Server Enterprise
    Edition (MSDN Version). Both server are running Windows 2003 Server
    Enterprise with current service packs.

    Both servers (hardward) are the same, HP ProLaint ML 350 (Dual Xeon 3.06Ghz
    with 4 gig of memory). The only major difference between the two machine is
    my test server is a tower version and the production server is a rack mount.

    I've had this problem for a while, but have a hacked workaround. I was told
    some months ago that Serivce Pack 4 for SQL Server 2000 would solve all of
    my problems, but never did, And I haven't had the time to followup.

    > So it really isn't odd to have issues in one environment and
    > not the other even with the same configurations.
    > The first one...locking or blocking issues could do that,
    > UMS issues, a lot of things. You need to be monitoring the
    > server to see what's going on when this happens.


    It very well could be a locking and blocking issue, but why don't I see the
    some problem on the test server running the same data and same load? Is
    there that much of a difference between SQL Server 2000 Enterprise vers
    Standard? Could that be the problem?

    Background information: The application the processes the data is completely
    multitreaded client/server app using RPC. Since RPC can make "x" number of
    connections to the server app at the same time, I have to log into the
    database (using ODBC SQLConnect) on each RPC function call. So I could have
    1 or 2 database login or I could have hundreds. (Both boxes right now are
    using the "sa" SQL Account to login). As each function call fall out of
    scope, I close the database connection.

    Anymore idea? I'd like to try putting SQL Server 2000 Enterprise (MSDN) on
    the production server as a test, but my IS department won't allow me because
    that would violate our license. And they don't want to buy a Enterprise
    edition just to test this theory.

    Any other ideas, comments or suggestions?

    Thanks,
    Weston Fryatt



    > The second one...a lot of things. Refer to the following for
    > more information:
    > Potential causes of the "SQL Server does not exist or access
    > denied" error message
    > http://support.microsoft.com/?id=328306


    The server apps and SQL Server both run on the same server so there
    shouldn't be any network traffic because all of the connections even though
    they are TCP are all local to the same box. I have checked the System DSN
    for my ODBC connection and it using "localhost" instead of the machine name,
    so there shouldn't be any DNS issues trying to figure out where this machine
    is.

    > The third one is not an error. That's an informational
    > message which can be ignored. You'd need to handle
    > informational messages in your app.


    Even though this isn't an error, It still bothers me that this warning, only
    shows up on the production server and not the test server.




    >
    > -Sue
    >
    > On Fri, 1 Sep 2006 08:20:22 -0500, "Weston Fryatt"
    > wrote:
    >
    >>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.
    >>
    >>I've already check and the ODBC System DSN is set to use "local host" as
    >>the
    >>name of the server to connect to, We use "Mixed Mode" and login as the
    >>"sa"
    >>account. Also the default database is set to the correct named database.
    >>
    >>What would cause these errors?
    >>
    >>Thanks,
    >>Weston Fryatt
    >>Sr. Software Engineer
    >>The SSI Group, Inc.
    >>
    >>
    >>

    >




  6. Re: SQLConnect

    There are enough indicators that there are other differences
    that I wouldn't bet on it being just a difference between
    the Enterprise Edition and the Standard Edition. Just
    looking at the third informational message that you get
    somewhere (in an app I would guess) hitting one server and
    not the other says something about some differences.
    The SQL Sever does not exist or access is denied - network
    issues can play a part in some cases and possibly you do
    have the exact same network components and configurations on
    each of these - as in the same path to each server through
    the same devices, via all the same IPs, the same server name
    for each server, the servers having the same DNS entries -
    things along those lines.
    Seems you want to focus on how it's the difference between
    Enterprise and Standard. So instead of purchasing Enterprise
    for your production environment (they were correct when they
    said you would need to purchase that version to put it on
    the production server) you could change your test
    environment over to Standard. Then you should have all of
    the issues in test that you have in production. Not that I'd
    recommending putting the energy into focusing on just that
    issue but it is what it is.
    That environment in Test would probably be a better setup
    anyway - if you guys are into maintaining same hardware,
    exactly the same activity at the same time on both systems,
    and there are absolutely no other differences at all between
    the two, it doesn't make much sense to run two different
    editions.

    -Sue

    On Fri, 8 Sep 2006 10:21:38 -0500, "Weston Fryatt"
    wrote:

    >
    >"Sue Hoegemeier" wrote in message
    >newsao0g21kmmjma646aai2e02adbevaf3p8t@4ax.com...
    >>I would guess though that your test machine doesn't get the
    >> same traffic and the same activity as the production server.

    >
    >Actually, I have configured the test server to process the same data as the
    >production server. The Test server has never had any of thes error in its
    >log. The only different here is SQL Server, Production is running SQL Server
    >2000 Standard Edition, and Test Server is running SQL 2000 Server Enterprise
    >Edition (MSDN Version). Both server are running Windows 2003 Server
    >Enterprise with current service packs.
    >
    >Both servers (hardward) are the same, HP ProLaint ML 350 (Dual Xeon 3.06Ghz
    >with 4 gig of memory). The only major difference between the two machine is
    >my test server is a tower version and the production server is a rack mount.
    >
    >I've had this problem for a while, but have a hacked workaround. I was told
    >some months ago that Serivce Pack 4 for SQL Server 2000 would solve all of
    >my problems, but never did, And I haven't had the time to followup.
    >
    >> So it really isn't odd to have issues in one environment and
    >> not the other even with the same configurations.
    >> The first one...locking or blocking issues could do that,
    >> UMS issues, a lot of things. You need to be monitoring the
    >> server to see what's going on when this happens.

    >
    >It very well could be a locking and blocking issue, but why don't I see the
    >some problem on the test server running the same data and same load? Is
    >there that much of a difference between SQL Server 2000 Enterprise vers
    >Standard? Could that be the problem?
    >
    >Background information: The application the processes the data is completely
    >multitreaded client/server app using RPC. Since RPC can make "x" number of
    >connections to the server app at the same time, I have to log into the
    >database (using ODBC SQLConnect) on each RPC function call. So I could have
    >1 or 2 database login or I could have hundreds. (Both boxes right now are
    >using the "sa" SQL Account to login). As each function call fall out of
    >scope, I close the database connection.
    >
    >Anymore idea? I'd like to try putting SQL Server 2000 Enterprise (MSDN) on
    >the production server as a test, but my IS department won't allow me because
    >that would violate our license. And they don't want to buy a Enterprise
    >edition just to test this theory.
    >
    >Any other ideas, comments or suggestions?
    >
    >Thanks,
    >Weston Fryatt
    >
    >
    >
    >> The second one...a lot of things. Refer to the following for
    >> more information:
    >> Potential causes of the "SQL Server does not exist or access
    >> denied" error message
    >> http://support.microsoft.com/?id=328306

    >
    >The server apps and SQL Server both run on the same server so there
    >shouldn't be any network traffic because all of the connections even though
    >they are TCP are all local to the same box. I have checked the System DSN
    >for my ODBC connection and it using "localhost" instead of the machine name,
    >so there shouldn't be any DNS issues trying to figure out where this machine
    >is.
    >
    >> The third one is not an error. That's an informational
    >> message which can be ignored. You'd need to handle
    >> informational messages in your app.

    >
    >Even though this isn't an error, It still bothers me that this warning, only
    >shows up on the production server and not the test server.
    >
    >
    >
    >
    >>
    >> -Sue
    >>
    >> On Fri, 1 Sep 2006 08:20:22 -0500, "Weston Fryatt"
    >> wrote:
    >>
    >>>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.
    >>>
    >>>I've already check and the ODBC System DSN is set to use "local host" as
    >>>the
    >>>name of the server to connect to, We use "Mixed Mode" and login as the
    >>>"sa"
    >>>account. Also the default database is set to the correct named database.
    >>>
    >>>What would cause these errors?
    >>>
    >>>Thanks,
    >>>Weston Fryatt
    >>>Sr. Software Engineer
    >>>The SSI Group, Inc.
    >>>
    >>>
    >>>

    >>

    >



  7. Re: SQLConnect

    There are enough indicators that there are other differences
    that I wouldn't bet on it being just a difference between
    the Enterprise Edition and the Standard Edition. Just
    looking at the third informational message that you get
    somewhere (in an app I would guess) hitting one server and
    not the other says something about some differences.
    The SQL Sever does not exist or access is denied - network
    issues can play a part in some cases and possibly you do
    have the exact same network components and configurations on
    each of these - as in the same path to each server through
    the same devices, via all the same IPs, the same server name
    for each server, the servers having the same DNS entries -
    things along those lines.
    Seems you want to focus on how it's the difference between
    Enterprise and Standard. So instead of purchasing Enterprise
    for your production environment (they were correct when they
    said you would need to purchase that version to put it on
    the production server) you could change your test
    environment over to Standard. Then you should have all of
    the issues in test that you have in production. Not that I'd
    recommending putting the energy into focusing on just that
    issue but it is what it is.
    That environment in Test would probably be a better setup
    anyway - if you guys are into maintaining same hardware,
    exactly the same activity at the same time on both systems,
    and there are absolutely no other differences at all between
    the two, it doesn't make much sense to run two different
    editions.

    -Sue

    On Fri, 8 Sep 2006 10:21:38 -0500, "Weston Fryatt"
    wrote:

    >
    >"Sue Hoegemeier" wrote in message
    >newsao0g21kmmjma646aai2e02adbevaf3p8t@4ax.com...
    >>I would guess though that your test machine doesn't get the
    >> same traffic and the same activity as the production server.

    >
    >Actually, I have configured the test server to process the same data as the
    >production server. The Test server has never had any of thes error in its
    >log. The only different here is SQL Server, Production is running SQL Server
    >2000 Standard Edition, and Test Server is running SQL 2000 Server Enterprise
    >Edition (MSDN Version). Both server are running Windows 2003 Server
    >Enterprise with current service packs.
    >
    >Both servers (hardward) are the same, HP ProLaint ML 350 (Dual Xeon 3.06Ghz
    >with 4 gig of memory). The only major difference between the two machine is
    >my test server is a tower version and the production server is a rack mount.
    >
    >I've had this problem for a while, but have a hacked workaround. I was told
    >some months ago that Serivce Pack 4 for SQL Server 2000 would solve all of
    >my problems, but never did, And I haven't had the time to followup.
    >
    >> So it really isn't odd to have issues in one environment and
    >> not the other even with the same configurations.
    >> The first one...locking or blocking issues could do that,
    >> UMS issues, a lot of things. You need to be monitoring the
    >> server to see what's going on when this happens.

    >
    >It very well could be a locking and blocking issue, but why don't I see the
    >some problem on the test server running the same data and same load? Is
    >there that much of a difference between SQL Server 2000 Enterprise vers
    >Standard? Could that be the problem?
    >
    >Background information: The application the processes the data is completely
    >multitreaded client/server app using RPC. Since RPC can make "x" number of
    >connections to the server app at the same time, I have to log into the
    >database (using ODBC SQLConnect) on each RPC function call. So I could have
    >1 or 2 database login or I could have hundreds. (Both boxes right now are
    >using the "sa" SQL Account to login). As each function call fall out of
    >scope, I close the database connection.
    >
    >Anymore idea? I'd like to try putting SQL Server 2000 Enterprise (MSDN) on
    >the production server as a test, but my IS department won't allow me because
    >that would violate our license. And they don't want to buy a Enterprise
    >edition just to test this theory.
    >
    >Any other ideas, comments or suggestions?
    >
    >Thanks,
    >Weston Fryatt
    >
    >
    >
    >> The second one...a lot of things. Refer to the following for
    >> more information:
    >> Potential causes of the "SQL Server does not exist or access
    >> denied" error message
    >> http://support.microsoft.com/?id=328306

    >
    >The server apps and SQL Server both run on the same server so there
    >shouldn't be any network traffic because all of the connections even though
    >they are TCP are all local to the same box. I have checked the System DSN
    >for my ODBC connection and it using "localhost" instead of the machine name,
    >so there shouldn't be any DNS issues trying to figure out where this machine
    >is.
    >
    >> The third one is not an error. That's an informational
    >> message which can be ignored. You'd need to handle
    >> informational messages in your app.

    >
    >Even though this isn't an error, It still bothers me that this warning, only
    >shows up on the production server and not the test server.
    >
    >
    >
    >
    >>
    >> -Sue
    >>
    >> On Fri, 1 Sep 2006 08:20:22 -0500, "Weston Fryatt"
    >> wrote:
    >>
    >>>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.
    >>>
    >>>I've already check and the ODBC System DSN is set to use "local host" as
    >>>the
    >>>name of the server to connect to, We use "Mixed Mode" and login as the
    >>>"sa"
    >>>account. Also the default database is set to the correct named database.
    >>>
    >>>What would cause these errors?
    >>>
    >>>Thanks,
    >>>Weston Fryatt
    >>>Sr. Software Engineer
    >>>The SSI Group, Inc.
    >>>
    >>>
    >>>

    >>

    >



+ Reply to Thread