Is the "connectivity only installation" is equvilant to installing MDAC on
the client machines, or the "connectivity only installation" has more
functionality to do.
Thanks
It is basically an MDAC installation.
Rand
This posting is provided "as is" with no warranties and confers no rights.
sqlsql
Showing posts with label mdac. Show all posts
Showing posts with label mdac. Show all posts
Sunday, March 25, 2012
connectivity only installation
Is the "connectivity only installation" is equvilant to installing MDAC on
the client machines, or the "connectivity only installation" has more
functionality to do.
ThanksIt is basically an MDAC installation.
Rand
This posting is provided "as is" with no warranties and confers no rights.
the client machines, or the "connectivity only installation" has more
functionality to do.
ThanksIt is basically an MDAC installation.
Rand
This posting is provided "as is" with no warranties and confers no rights.
Monday, March 19, 2012
Connectioni leak with MDAC 2.82
Hi, I have troubles with a threaded application on W2003 server. It seems to leave open connections behind time to time, it sums to hundreds over a day (the application make thousends). It is using the SQL ADO provider, MDAC 2.82.1830.0, SQL Server 8.00.2039 (SP4), Windows 5.2 (3790).
Is there a knwon bug like this? Is there a way to trace the ADO provider?are you sure you are explicitly closing your connections?|||What is your code that opens and closes connection to the server?|||
Hi, sorry for the delay, the forum alert seems not to work for me either :-)
Yes. I am closing all connections, the program leaves only about 5-10% of the connections behind, not all of them. Also, I run the same code using ODBC provider and that works absolutely fine. I my code there is a chance to leave connection behind in case of error, but than I would see error messages inmy log, which I don't. Here is the code:
_ConnectionPtr
AsyncOpen(struct s_profiles *profile)
{
time_t start;
string sConnStr;
HRESULT hr;
SYSTEMTIME st1,st2;
_ConnectionPtr pConn = NULL;
char msg[1024];
try {
start = time(NULL);
GetSystemTime(&st1); //time before connect
TESTHR(pConn.CreateInstance(__uuidof(Connection)));
pConn->ConnectionTimeout = profile->conn->timeout; //set ADO Connection Timeout (default 30sec)
pConn->CommandTimeout = profile->timeout; //set ADO Command Timeout (default 30sec)
if (pConn->State == adStateOpen) {
nimLog(1,"Profile: %s, connection: %s already opem", profile->name, profile->connection);
return pConn; //Already open
}
if (strcmp(profile->cursor,"server") == 0)
pConn->CursorLocation = adUseServer; //use server cursor
else
pConn->CursorLocation = adUseClient; //use client cursor (default)
sConnStr = CreateConnString(profile->conn);
hr = pConn->Open(_bstr_t(sConnStr.c_str()),bsNull,bsNull,adAsyncConnect);
if (FAILED(hr))
{
nimLog(0,"Profile %s, AsyncOpen - failed for connection '%s'",profile->name, profile->connection);
return pConn;
}
while (pConn->State == adStateConnecting)
{
//nimLog(0,"Profile: %s - Wait for Connection to open", profile->name);
if(time(NULL) > (start + profile->conn->timeout + gSetup->COM_tout_delay))
{
nimLog(0,"Profile %s, AsyncOpen - connection timeout",profile->name;
pConn->Cancel();
pConn = NULL;
return pConn;
}
Sleep(5);
}
nimLog(2,"Profile %s, AsyncOpen - connected to database",profile->name);
if (FAILED(hr))
{
nimLog(0,"Open - failed for connection '%s'",profile->connection);
return 0;
}
}
catch(_com_error &e ) {
nimLog(0,"Profile: %s, Error in AsyncOpen", profile->name);
LogComError(e, profile->name, 0, "Open");
return 0;
}
catch(...){
nimLog(0,"Profile: %s, Unknown error in Open", profile->name);
sprintf(msg,"Profile %s, unknown error in Open", profile->name);
return 0;
}
//return (pConn->State == adStateOpen ? 1 : 0);
return pConn;
}
//close
try
{
hr = pConn->Close();
if (FAILED(hr))
{
nimLog(0,"Close connection failed (%s:%d)",__FILE__,__LINE__);
EXIT_THREAD(0);
}
pConn = NULL;
}
Thanks for help!
|||Is Cancel method same as Close for the ADO Connection in C++? I do not know C++, but if this is the case, then code looks good. What you could do is to run SQL Profiler to trace activity between the server and your application. It could provide additional information as well|||Close and Cancel are not exactly the same, Cancel is used to close an asynchronous request, Close to end after you're done. I am using asynchronous Open to be able to bail out if timeout reach, than I need Cancel.
To use the Profiler shows, unfortunately only half of the story. I can see what the ADO provider send towards SQL, but not what my application sends to ADO. At the end I can see every once in a whole there is a connection not closed, but no idea why - did the application not sent the close? Not to be seen in profiler. And ODBC like trace does not exeists, at least to my knowledge.
I am believing now there is something wrong with the ADO provider on that one machine, as it doens't happen on others and also it works there with ODBC. The question remains what is wrong, I cannot see anything obvious. I only observed, that the response time with ADO was considerable slower than with ODBC, althoug I would expect it the other way around.
Any other ideas out there?
|||It is possible that Cancel is not enough. Can you try to use Close to see if it helps or you cannot?|||Unfortunately, it is a production machine where it happens, and I am limited in my activities there. But on my test machine Cancel works, quite the oposite, Close doesn't work there. But to this part of code I get only in "timeout" situation, where I get a message - I didn't get any timeout at all yet on the production machine. I would say it must be something else.|||I am wondering if your ADO connection is actually getting pooled.
Add "Pooling=false;" to your ado connection string. If the problem goes away, its not an issue, remove the keyword/value pair and carry on. If the problem persists, I am wondering if you need an analog to your _ConnectionPtr->CreateInstance that releases the instance?
|||Make sure that the connection is closed--even if the code throws an exception.|||Hi Dbrich,
Same problem what you faced long back ago.
I have troubles with a threaded application on W2003 server. It seems to leave open connections behind time to time, it sums to hundreds over a day (the application make thousands). It is using the SQL ADO provider, MDAC 2.82.1830.0, SQL Server 8.00.2039 (SP4), Windows 5.2 (3790),SP4 for SQL Server.
actually when i run the application on my machine i didn't find any connection leak but on production machine i find connection leak.
Is there a know bug like this? Is there a way to trace the ADO provider?
In my SQL Profiler I got this error number 16945,16955,208
Connectioni leak with MDAC 2.82
Hi, I have troubles with a threaded application on W2003 server. It seems to leave open connections behind time to time, it sums to hundreds over a day (the application make thousends). It is using the SQL ADO provider, MDAC 2.82.1830.0, SQL Server 8.00.2039 (SP4), Windows 5.2 (3790).
Is there a knwon bug like this? Is there a way to trace the ADO provider?are you sure you are explicitly closing your connections?|||What is your code that opens and closes connection to the server?|||
Hi, sorry for the delay, the forum alert seems not to work for me either :-)
Yes. I am closing all connections, the program leaves only about 5-10% of the connections behind, not all of them. Also, I run the same code using ODBC provider and that works absolutely fine. I my code there is a chance to leave connection behind in case of error, but than I would see error messages inmy log, which I don't. Here is the code:
_ConnectionPtr
AsyncOpen(struct s_profiles *profile)
{
time_t start;
string sConnStr;
HRESULT hr;
SYSTEMTIME st1,st2;
_ConnectionPtr pConn = NULL;
char msg[1024];
try {
start = time(NULL);
GetSystemTime(&st1); //time before connect
TESTHR(pConn.CreateInstance(__uuidof(Connection)));
pConn->ConnectionTimeout = profile->conn->timeout; //set ADO Connection Timeout (default 30sec)
pConn->CommandTimeout = profile->timeout; //set ADO Command Timeout (default 30sec)
if (pConn->State == adStateOpen) {
nimLog(1,"Profile: %s, connection: %s already opem", profile->name, profile->connection);
return pConn; //Already open
}
if (strcmp(profile->cursor,"server") == 0)
pConn->CursorLocation = adUseServer; //use server cursor
else
pConn->CursorLocation = adUseClient; //use client cursor (default)
sConnStr = CreateConnString(profile->conn);
hr = pConn->Open(_bstr_t(sConnStr.c_str()),bsNull,bsNull,adAsyncConnect);
if (FAILED(hr))
{
nimLog(0,"Profile %s, AsyncOpen - failed for connection '%s'",profile->name, profile->connection);
return pConn;
}
while (pConn->State == adStateConnecting)
{
//nimLog(0,"Profile: %s - Wait for Connection to open", profile->name);
if(time(NULL) > (start + profile->conn->timeout + gSetup->COM_tout_delay))
{
nimLog(0,"Profile %s, AsyncOpen - connection timeout",profile->name;
pConn->Cancel();
pConn = NULL;
return pConn;
}
Sleep(5);
}
nimLog(2,"Profile %s, AsyncOpen - connected to database",profile->name);
if (FAILED(hr))
{
nimLog(0,"Open - failed for connection '%s'",profile->connection);
return 0;
}
}
catch(_com_error &e ) {
nimLog(0,"Profile: %s, Error in AsyncOpen", profile->name);
LogComError(e, profile->name, 0, "Open");
return 0;
}
catch(...){
nimLog(0,"Profile: %s, Unknown error in Open", profile->name);
sprintf(msg,"Profile %s, unknown error in Open", profile->name);
return 0;
}
//return (pConn->State == adStateOpen ? 1 : 0);
return pConn;
}
//close
try
{
hr = pConn->Close();
if (FAILED(hr))
{
nimLog(0,"Close connection failed (%s:%d)",__FILE__,__LINE__);
EXIT_THREAD(0);
}
pConn = NULL;
}
Thanks for help!
|||Is Cancel method same as Close for the ADO Connection in C++? I do not know C++, but if this is the case, then code looks good. What you could do is to run SQL Profiler to trace activity between the server and your application. It could provide additional information as well|||Close and Cancel are not exactly the same, Cancel is used to close an asynchronous request, Close to end after you're done. I am using asynchronous Open to be able to bail out if timeout reach, than I need Cancel.
To use the Profiler shows, unfortunately only half of the story. I can see what the ADO provider send towards SQL, but not what my application sends to ADO. At the end I can see every once in a whole there is a connection not closed, but no idea why - did the application not sent the close? Not to be seen in profiler. And ODBC like trace does not exeists, at least to my knowledge.
I am believing now there is something wrong with the ADO provider on that one machine, as it doens't happen on others and also it works there with ODBC. The question remains what is wrong, I cannot see anything obvious. I only observed, that the response time with ADO was considerable slower than with ODBC, althoug I would expect it the other way around.
Any other ideas out there?
|||It is possible that Cancel is not enough. Can you try to use Close to see if it helps or you cannot?|||Unfortunately, it is a production machine where it happens, and I am limited in my activities there. But on my test machine Cancel works, quite the oposite, Close doesn't work there. But to this part of code I get only in "timeout" situation, where I get a message - I didn't get any timeout at all yet on the production machine. I would say it must be something else.|||I am wondering if your ADO connection is actually getting pooled.
Add "Pooling=false;" to your ado connection string. If the problem goes away, its not an issue, remove the keyword/value pair and carry on. If the problem persists, I am wondering if you need an analog to your _ConnectionPtr->CreateInstance that releases the instance?
|||Make sure that the connection is closed--even if the code throws an exception.|||Hi Dbrich,
Same problem what you faced long back ago.
I have troubles with a threaded application on W2003 server. It seems to leave open connections behind time to time, it sums to hundreds over a day (the application make thousands). It is using the SQL ADO provider, MDAC 2.82.1830.0, SQL Server 8.00.2039 (SP4), Windows 5.2 (3790),SP4 for SQL Server.
actually when i run the application on my machine i didn't find any connection leak but on production machine i find connection leak.
Is there a know bug like this? Is there a way to trace the ADO provider?
In my SQL Profiler I got this error number 16945,16955,208
Sunday, March 11, 2012
Connection without MDAC2.6
Hello Faculties
If a client is not upgraded with MDAC 2.6, is it still possible to
connect to SQL Server 2000 from that client?
If a client is not upgraded with MDAC 2.6, is it still possible to
connect to SQL Server 2000 from that client?
Thanks in advance
Debashishdebashish (debashish_majumdar@.rediffmail.com) writes:
> Hello Faculties
> If a client is not upgraded with MDAC 2.6, is it still possible to
> connect to SQL Server 2000 from that client?
Yes, but you may experience limitations in functionality. For instance,
MDAC 2.5 and earlier does not support named instances. You may not be able
to use the bigint data type, or XML data.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
Connection to SQL Server 2005 lost
We have developed a VB6 client program accsessing SQL Sever 7.0 via ADO
(Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
years, but after upgrading to SQL Server 2005, the database connection is
sometimes lost during larger operation involving open/close of several
recordsets. The general error message says:
“[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsist or access
denied". "Simpler" parts of the program involving just a recordset or two
always work fine. Any idea of what is going on here?
Have you tried using the SQL Native Client (SNAC) instead to see if that
makes a difference?
http://msdn2.microsoft.com/en-us/data/aa937733.aspx
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
> We have developed a VB6 client program accsessing SQL Sever 7.0 via ADO
> (Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
> years, but after upgrading to SQL Server 2005, the database connection is
> sometimes lost during larger operation involving open/close of several
> recordsets. The general error message says:
> “[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsist or
> access
> denied". "Simpler" parts of the program involving just a recordset or two
> always work fine. Any idea of what is going on here?
|||Thank you for the suggestion.
We have not tried the native client, because the FAQ says:
Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
server?
A. Applications deployed before SQL Server 2005 was released can and should
continue to use MDAC.
Most likely it is a server configuration problem. Our program is used by
many clients, accessing the datebase from different computers/configurations,
and all of them experience this error message when conneting to a given SQL
Server 2005 Server. Some of our clients from other firms also have their own
SQL Server 2005 running, and they have successfully managed to connect to
their database using MDAC and never experience this error message.
"Andrew J. Kelly" wrote:
> Have you tried using the SQL Native Client (SNAC) instead to see if that
> makes a difference?
> http://msdn2.microsoft.com/en-us/data/aa937733.aspx
>
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
> message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
>
|||Sorry I don't have another answer for you. I have not heard of or seen this
particular issue before.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
|||Ah, I would STILL upgrade to SNAC. I agree that if the application is
working and deployed it should not be disturbed, but yours is not working
and SNAC solves any number of issues like this.
__________________________________________________ ________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
__________________________________________________ __________________________________________
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
|||We upgraded to SNAC, but still experience the very same error. The text of
the error message reported is a little bit different, thought. It now says
"Named Pipes Provider: No process is on the other end of the pipe." We did
get rid of the error message when we changed the recordsets cursor from
server-side to client-side (CursorLocation = adUseClient).
"William Vaughn" wrote:
> Ah, I would STILL upgrade to SNAC. I agree that if the application is
> working and deployed it should not be disturbed, but yours is not working
> and SNAC solves any number of issues like this.
> --
> __________________________________________________ ________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205 (Pacific time)
> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
> __________________________________________________ __________________________________________
> "Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
> message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...
>
|||You are putting less work on the SQL Server by doing that and is generally a
good idea anyway. But you should also think about changing to TCP instead of
using named pipes.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:530FDB75-0B6B-46E3-A9CA-FFD3E2B3F75F@.microsoft.com...[vbcol=seagreen]
> We upgraded to SNAC, but still experience the very same error. The text of
> the error message reported is a little bit different, thought. It now says
> "Named Pipes Provider: No process is on the other end of the pipe." We did
> get rid of the error message when we changed the recordsets cursor from
> server-side to client-side (CursorLocation = adUseClient).
>
> "William Vaughn" wrote:
|||It sounds like the server is rejecting the Open. Make sure that the server
configuration is not limiting the total number of connections in any way.
These might have been configured to comply with license or other artifical
constraints.
__________________________________________________ ________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
__________________________________________________ __________________________________________
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:530FDB75-0B6B-46E3-A9CA-FFD3E2B3F75F@.microsoft.com...[vbcol=seagreen]
> We upgraded to SNAC, but still experience the very same error. The text of
> the error message reported is a little bit different, thought. It now says
> "Named Pipes Provider: No process is on the other end of the pipe." We did
> get rid of the error message when we changed the recordsets cursor from
> server-side to client-side (CursorLocation = adUseClient).
>
> "William Vaughn" wrote:
(Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
years, but after upgrading to SQL Server 2005, the database connection is
sometimes lost during larger operation involving open/close of several
recordsets. The general error message says:
“[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsist or access
denied". "Simpler" parts of the program involving just a recordset or two
always work fine. Any idea of what is going on here?
Have you tried using the SQL Native Client (SNAC) instead to see if that
makes a difference?
http://msdn2.microsoft.com/en-us/data/aa937733.aspx
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
> We have developed a VB6 client program accsessing SQL Sever 7.0 via ADO
> (Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
> years, but after upgrading to SQL Server 2005, the database connection is
> sometimes lost during larger operation involving open/close of several
> recordsets. The general error message says:
> “[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsist or
> access
> denied". "Simpler" parts of the program involving just a recordset or two
> always work fine. Any idea of what is going on here?
|||Thank you for the suggestion.
We have not tried the native client, because the FAQ says:
Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
server?
A. Applications deployed before SQL Server 2005 was released can and should
continue to use MDAC.
Most likely it is a server configuration problem. Our program is used by
many clients, accessing the datebase from different computers/configurations,
and all of them experience this error message when conneting to a given SQL
Server 2005 Server. Some of our clients from other firms also have their own
SQL Server 2005 running, and they have successfully managed to connect to
their database using MDAC and never experience this error message.
"Andrew J. Kelly" wrote:
> Have you tried using the SQL Native Client (SNAC) instead to see if that
> makes a difference?
> http://msdn2.microsoft.com/en-us/data/aa937733.aspx
>
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
> message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
>
|||Sorry I don't have another answer for you. I have not heard of or seen this
particular issue before.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
|||Ah, I would STILL upgrade to SNAC. I agree that if the application is
working and deployed it should not be disturbed, but yours is not working
and SNAC solves any number of issues like this.
__________________________________________________ ________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
__________________________________________________ __________________________________________
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
|||We upgraded to SNAC, but still experience the very same error. The text of
the error message reported is a little bit different, thought. It now says
"Named Pipes Provider: No process is on the other end of the pipe." We did
get rid of the error message when we changed the recordsets cursor from
server-side to client-side (CursorLocation = adUseClient).
"William Vaughn" wrote:
> Ah, I would STILL upgrade to SNAC. I agree that if the application is
> working and deployed it should not be disturbed, but yours is not working
> and SNAC solves any number of issues like this.
> --
> __________________________________________________ ________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205 (Pacific time)
> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
> __________________________________________________ __________________________________________
> "Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
> message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...
>
|||You are putting less work on the SQL Server by doing that and is generally a
good idea anyway. But you should also think about changing to TCP instead of
using named pipes.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:530FDB75-0B6B-46E3-A9CA-FFD3E2B3F75F@.microsoft.com...[vbcol=seagreen]
> We upgraded to SNAC, but still experience the very same error. The text of
> the error message reported is a little bit different, thought. It now says
> "Named Pipes Provider: No process is on the other end of the pipe." We did
> get rid of the error message when we changed the recordsets cursor from
> server-side to client-side (CursorLocation = adUseClient).
>
> "William Vaughn" wrote:
|||It sounds like the server is rejecting the Open. Make sure that the server
configuration is not limiting the total number of connections in any way.
These might have been configured to comply with license or other artifical
constraints.
__________________________________________________ ________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
__________________________________________________ __________________________________________
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:530FDB75-0B6B-46E3-A9CA-FFD3E2B3F75F@.microsoft.com...[vbcol=seagreen]
> We upgraded to SNAC, but still experience the very same error. The text of
> the error message reported is a little bit different, thought. It now says
> "Named Pipes Provider: No process is on the other end of the pipe." We did
> get rid of the error message when we changed the recordsets cursor from
> server-side to client-side (CursorLocation = adUseClient).
>
> "William Vaughn" wrote:
Connection to SQL Server 2005 lost
We have developed a VB6 client program accsessing SQL Sever 7.0 via ADO
(Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
years, but after upgrading to SQL Server 2005, the database connection is
sometimes lost during larger operation involving open/close of several
recordsets. The general error message says:
“[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsist
or access
denied". "Simpler" parts of the program involving just a recordset or two
always work fine. Any idea of what is going on here?Have you tried using the SQL Native Client (SNAC) instead to see if that
makes a difference?
http://msdn2.microsoft.com/en-us/data/aa937733.aspx
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
> We have developed a VB6 client program accsessing SQL Sever 7.0 via ADO
> (Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
> years, but after upgrading to SQL Server 2005, the database connection is
> sometimes lost during larger operation involving open/close of several
> recordsets. The general error message says:
> “[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsis
t or
> access
> denied". "Simpler" parts of the program involving just a recordset or two
> always work fine. Any idea of what is going on here?|||Thank you for the suggestion.
We have not tried the native client, because the FAQ says:
Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
server?
A. Applications deployed before SQL Server 2005 was released can and should
continue to use MDAC.
Most likely it is a server configuration problem. Our program is used by
many clients, accessing the datebase from different computers/configurations
,
and all of them experience this error message when conneting to a given SQL
Server 2005 Server. Some of our clients from other firms also have their own
SQL Server 2005 running, and they have successfully managed to connect to
their database using MDAC and never experience this error message.
"Andrew J. Kelly" wrote:
> Have you tried using the SQL Native Client (SNAC) instead to see if that
> makes a difference?
> http://msdn2.microsoft.com/en-us/data/aa937733.aspx
>
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
> message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
>|||Sorry I don't have another answer for you. I have not heard of or seen this
particular issue before.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
>|||Ah, I would STILL upgrade to SNAC. I agree that if the application is
working and deployed it should not be disturbed, but yours is not working
and SNAC solves any number of issues like this.
________________________________________
__________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
________________________________________
____________________________________
________________
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
>
(Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
years, but after upgrading to SQL Server 2005, the database connection is
sometimes lost during larger operation involving open/close of several
recordsets. The general error message says:
“[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsist
or access
denied". "Simpler" parts of the program involving just a recordset or two
always work fine. Any idea of what is going on here?Have you tried using the SQL Native Client (SNAC) instead to see if that
makes a difference?
http://msdn2.microsoft.com/en-us/data/aa937733.aspx
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
> We have developed a VB6 client program accsessing SQL Sever 7.0 via ADO
> (Provider=sqloledb) and MDAC 2.8. This program has worked flawlessly for
> years, but after upgrading to SQL Server 2005, the database connection is
> sometimes lost during larger operation involving open/close of several
> recordsets. The general error message says:
> “[DBNETLIB][ConnectionOpen,Connect()).]SQL Server does not exsis
t or
> access
> denied". "Simpler" parts of the program involving just a recordset or two
> always work fine. Any idea of what is going on here?|||Thank you for the suggestion.
We have not tried the native client, because the FAQ says:
Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
server?
A. Applications deployed before SQL Server 2005 was released can and should
continue to use MDAC.
Most likely it is a server configuration problem. Our program is used by
many clients, accessing the datebase from different computers/configurations
,
and all of them experience this error message when conneting to a given SQL
Server 2005 Server. Some of our clients from other firms also have their own
SQL Server 2005 running, and they have successfully managed to connect to
their database using MDAC and never experience this error message.
"Andrew J. Kelly" wrote:
> Have you tried using the SQL Native Client (SNAC) instead to see if that
> makes a difference?
> http://msdn2.microsoft.com/en-us/data/aa937733.aspx
>
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Glenn Handeland" <Glenn Handeland@.discussions.microsoft.com> wrote in
> message news:9A2E8820-DEFC-4209-B019-8A0996CF7FDF@.microsoft.com...
>|||Sorry I don't have another answer for you. I have not heard of or seen this
particular issue before.
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
>|||Ah, I would STILL upgrade to SNAC. I agree that if the application is
working and deployed it should not be disturbed, but yours is not working
and SNAC solves any number of issues like this.
________________________________________
__________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205 (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
________________________________________
____________________________________
________________
"Glenn Handeland" <GlennHandeland@.discussions.microsoft.com> wrote in
message news:C425386F-DA1A-4D79-AEFB-AE29F7AC6606@.microsoft.com...[vbcol=seagreen]
> Thank you for the suggestion.
> We have not tried the native client, because the FAQ says:
> Q. Must I upgrade clients to use SQL Native Client as soon as I upgrade my
> server?
> A. Applications deployed before SQL Server 2005 was released can and
> should
> continue to use MDAC.
> Most likely it is a server configuration problem. Our program is used by
> many clients, accessing the datebase from different
> computers/configurations,
> and all of them experience this error message when conneting to a given
> SQL
> Server 2005 Server. Some of our clients from other firms also have their
> own
> SQL Server 2005 running, and they have successfully managed to connect to
> their database using MDAC and never experience this error message.
>
> "Andrew J. Kelly" wrote:
>
Subscribe to:
Posts (Atom)