Odd issue with bound columns when fetching data.

I'm using ODBC 3.0 in code written in C.

I have an service that connects using a system DSN using the SQL Server 2000 driver. On my development system with SQL Server 2005 Express installed, the queries work fine. I prepare a statement and then bind the columns that will be in the result set. On my system, I get all the data as it should be but on a live system, I do not get the proper data for the last three rows. I don't get any error messages from the query or the column binding and there are also no extra information messages that I can retrieve.

The table is something like the following. The names are changed to protect the guilty.

CREATE TABLE DOWNLOAD

(

FIELD_1 NUMERIC( 6,0 ),

ID CHAR( 15),

FNAME( 30 ),

LNAME( 40 ),

CLIENT_ID NUMERIC( 9,0),

CLIENT_NAME CHAR( 50 ),

CODE NUMERIC( 4,0 ),

PHONE CHAR( 10 )

)

go

On my system, running the exact same binary code as the client machine, I get all of the data from all of the columns as it should be. The problem is when I run on a client's system, the CLIENT_NAME, CODE, and PHONE columns return null values even when there is data there. On my development system the SQL Server instance runs on the same machine. On the client's sytem I am connecting to a remote instance of SQL Server 2000 on another system on the network.

My quandry is what could be different between the two systems that is causing me the problems?

Can you ran SQL Profiler on both machines and see if there is any difference?|||I've turned the logging on at the client side. The logs don't show any errors and it looks like the column binding in SQLBindCol is correct. I haven't seen the server side logs but the gurus on the server side say that they can't see anything wrong there. I've played around with the SQL statement and tried using CONVERT() to change the CHAR to VARCHAR but that doesn't seem to help.

I'm at a total loss why the same code running on my development system runs fine but fails on another system. My guess is that there is some configuration difference but I don't know what that is because I am using the samve version of the SQL Server 2000 ODBC driver on both machines. Its not like there is anything odd or non standard in the table definition either.

|||Just as an update and possibly more information.

I've got it working now but I don't like the solution. What I ended up doing is not binding the columns and calling SQLGetData() after the fetch to get the column data. I don't like this because it costs me about 500 ms for the each time I call the function.

I'd still like to find a solution for why the bound columns don't work.
|||1) I would still recommend you to run SQL Profiler on the servers.
2) How do you bind exactly? Is it possible for you to write (and post the source here) a small ODBC application which demonstrates this problem?|||This is the code I use to bind the columns:

BOOL BindRecord( SQLHSTMT hStmt, PACCDATA_FIELD *pRecord, PINT piRecCount )
{
BOOL bRval = FALSE;
PACCDATA_FIELD pField;
SQLRETURN r;
INT iCnt;
CHAR szBuf[128];
SQLINTEGER len;

if( pRecord && *pRecord )
{
for( iCnt = 0; iCnt < *piRecCount; iCnt++ )
{
pField = *pRecord + iCnt;
len = pField->nLen;

switch( pField->iType )
{
case SQL_CHAR:
r = SQLBindCol( hStmt, pField->iColNum, SQL_C_CHAR, pField->pcVal, pField->nDataSize, &len );
break;

case SQL_DATETIME:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->ucVal, pField->nDataSize, &len );
break;

case SQL_DECIMAL:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->ucVal, pField->nDataSize, &len );
break;

case SQL_NUMERIC:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->lVal, pField->nDataSize, &len );
break;

case SQL_INTEGER:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->lVal, pField->nDataSize, &len );
break;

case SQL_SMALLINT:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->sVal, pField->nDataSize, &len );
break;

case SQL_DOUBLE:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->dVal, pField->nDataSize, &len );
break;

case SQL_FLOAT:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->dVal, pField->nDataSize, &len );
break;

case SQL_REAL:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->fVal, pField->nDataSize, &len );
break;

case SQL_VARCHAR:
r = SQLBindCol( hStmt, pField->iColNum, SQL_C_CHAR, pField->pvcVal, pField->nDataSize + 1, &len );
break;

case SQL_UNKNOWN_TYPE:
ST_WriteLog( "st_ctimpact", "BindRecord", "Field data type is SQL_UNKNOWN_TYPE", ST_LOG_DEBUG );
default:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, pField->ptr, pField->nDataSize, &len );
break;
}

if( r == SQL_SUCCESS_WITH_INFO )
{
lstrcpy( szBuf, "Field name: " );
lstrcat( szBuf, pField->szColName );
ST_WriteLog( "st_AcceleratedData", "BindRecord", szBuf, ST_LOG_WARNING );
ShowSQLMessages( "BindRecord", SQL_HANDLE_STMT, hStmt );
bRval = TRUE;
}
else if( r != SQL_SUCCESS )
{
lstrcpy( szBuf, "Field name: " );
lstrcat( szBuf, pField->szColName );
ST_WriteLog( "st_AcceleratedData", "BindRecord", szBuf, ST_LOG_WARNING );
ShowSQLErrors( "BindRecord", SQL_HANDLE_STMT, hStmt );
}
else
bRval = TRUE;
}
}
return( bRval );
}

A key to remember is that other columns that are bound in this way, and have the same data types, are returning data just fine. I've looked at the logs on the client side where this code works, and there are no errors and the prameters look correct as far as I can tell. Also this code works as advertized on my system but not on the live system. Right now, I don't think my customer will be willing to let me mess around on their system trying to come up with an application that would recreate the problem. Also note that I cannot recreate the problem on my own system. I had hoped that it would be broken on my system so I could debug and find out what was the problem but because it works, I can't.
|||I do not think you have to mess around with your customer system.
I would suggest you write a straightforward ODBC application from scratch just going against this very table.
Use some static arrays and bind directly with SQLBindCol, so to exclude any dependecies on how PACCDATA_FIELD or other parts of your custom code are written.
Then when you are sure it works as supposed on your machine, try it against your customer's.|||Then I guess you didn't read the thread all that well. I don't have to write a test app. The live code works fine on my system on the same table definition in the same database name as the live system. The problem is when I deployed the code, some of the bound columns don't return data. Since I can't recreate the problem on my system, I'm at a loss as to what the problem is.
|||I'm not sure if it is possilbe to resolve your issue without actual experimentation. Your system is not identical to the live system, is it? So your argument that the code works on your system is not helpful to you. If you really want to find out where the problem is you might try and start narrowing down on the issue. That is what I suggested to you.|||It just seemed to me that you asking me to make a test case that is exactly what I have running. I think I might have it working now and it must have something to do with my adding RTRIM() and CONVERT() functions in the select statement. I removed them and it seems to work better now.

Odd issue with bound columns when fetching data.

I'm using ODBC 3.0 in code written in C.

I have an service that connects using a system DSN using the SQL Server 2000 driver. On my development system with SQL Server 2005 Express installed, the queries work fine. I prepare a statement and then bind the columns that will be in the result set. On my system, I get all the data as it should be but on a live system, I do not get the proper data for the last three rows. I don't get any error messages from the query or the column binding and there are also no extra information messages that I can retrieve.

The table is something like the following. The names are changed to protect the guilty.

CREATE TABLE DOWNLOAD

(

FIELD_1 NUMERIC( 6,0 ),

ID CHAR( 15),

FNAME( 30 ),

LNAME( 40 ),

CLIENT_ID NUMERIC( 9,0),

CLIENT_NAME CHAR( 50 ),

CODE NUMERIC( 4,0 ),

PHONE CHAR( 10 )

)

go

On my system, running the exact same binary code as the client machine, I get all of the data from all of the columns as it should be. The problem is when I run on a client's system, the CLIENT_NAME, CODE, and PHONE columns return null values even when there is data there. On my development system the SQL Server instance runs on the same machine. On the client's sytem I am connecting to a remote instance of SQL Server 2000 on another system on the network.

My quandry is what could be different between the two systems that is causing me the problems?

Can you ran SQL Profiler on both machines and see if there is any difference?|||I've turned the logging on at the client side. The logs don't show any errors and it looks like the column binding in SQLBindCol is correct. I haven't seen the server side logs but the gurus on the server side say that they can't see anything wrong there. I've played around with the SQL statement and tried using CONVERT() to change the CHAR to VARCHAR but that doesn't seem to help.

I'm at a total loss why the same code running on my development system runs fine but fails on another system. My guess is that there is some configuration difference but I don't know what that is because I am using the samve version of the SQL Server 2000 ODBC driver on both machines. Its not like there is anything odd or non standard in the table definition either.

|||Just as an update and possibly more information.

I've got it working now but I don't like the solution. What I ended up doing is not binding the columns and calling SQLGetData() after the fetch to get the column data. I don't like this because it costs me about 500 ms for the each time I call the function.

I'd still like to find a solution for why the bound columns don't work.
|||1) I would still recommend you to run SQL Profiler on the servers.
2) How do you bind exactly? Is it possible for you to write (and post the source here) a small ODBC application which demonstrates this problem?|||This is the code I use to bind the columns:

BOOL BindRecord( SQLHSTMT hStmt, PACCDATA_FIELD *pRecord, PINT piRecCount )
{
BOOL bRval = FALSE;
PACCDATA_FIELD pField;
SQLRETURN r;
INT iCnt;
CHAR szBuf[128];
SQLINTEGER len;

if( pRecord && *pRecord )
{
for( iCnt = 0; iCnt < *piRecCount; iCnt++ )
{
pField = *pRecord + iCnt;
len = pField->nLen;

switch( pField->iType )
{
case SQL_CHAR:
r = SQLBindCol( hStmt, pField->iColNum, SQL_C_CHAR, pField->pcVal, pField->nDataSize, &len );
break;

case SQL_DATETIME:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->ucVal, pField->nDataSize, &len );
break;

case SQL_DECIMAL:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->ucVal, pField->nDataSize, &len );
break;

case SQL_NUMERIC:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->lVal, pField->nDataSize, &len );
break;

case SQL_INTEGER:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->lVal, pField->nDataSize, &len );
break;

case SQL_SMALLINT:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->sVal, pField->nDataSize, &len );
break;

case SQL_DOUBLE:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->dVal, pField->nDataSize, &len );
break;

case SQL_FLOAT:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->dVal, pField->nDataSize, &len );
break;

case SQL_REAL:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->fVal, pField->nDataSize, &len );
break;

case SQL_VARCHAR:
r = SQLBindCol( hStmt, pField->iColNum, SQL_C_CHAR, pField->pvcVal, pField->nDataSize + 1, &len );
break;

case SQL_UNKNOWN_TYPE:
ST_WriteLog( "st_ctimpact", "BindRecord", "Field data type is SQL_UNKNOWN_TYPE", ST_LOG_DEBUG );
default:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, pField->ptr, pField->nDataSize, &len );
break;
}

if( r == SQL_SUCCESS_WITH_INFO )
{
lstrcpy( szBuf, "Field name: " );
lstrcat( szBuf, pField->szColName );
ST_WriteLog( "st_AcceleratedData", "BindRecord", szBuf, ST_LOG_WARNING );
ShowSQLMessages( "BindRecord", SQL_HANDLE_STMT, hStmt );
bRval = TRUE;
}
else if( r != SQL_SUCCESS )
{
lstrcpy( szBuf, "Field name: " );
lstrcat( szBuf, pField->szColName );
ST_WriteLog( "st_AcceleratedData", "BindRecord", szBuf, ST_LOG_WARNING );
ShowSQLErrors( "BindRecord", SQL_HANDLE_STMT, hStmt );
}
else
bRval = TRUE;
}
}
return( bRval );
}

A key to remember is that other columns that are bound in this way, and have the same data types, are returning data just fine. I've looked at the logs on the client side where this code works, and there are no errors and the prameters look correct as far as I can tell. Also this code works as advertized on my system but not on the live system. Right now, I don't think my customer will be willing to let me mess around on their system trying to come up with an application that would recreate the problem. Also note that I cannot recreate the problem on my own system. I had hoped that it would be broken on my system so I could debug and find out what was the problem but because it works, I can't.
|||I do not think you have to mess around with your customer system.
I would suggest you write a straightforward ODBC application from scratch just going against this very table.
Use some static arrays and bind directly with SQLBindCol, so to exclude any dependecies on how PACCDATA_FIELD or other parts of your custom code are written.
Then when you are sure it works as supposed on your machine, try it against your customer's.|||Then I guess you didn't read the thread all that well. I don't have to write a test app. The live code works fine on my system on the same table definition in the same database name as the live system. The problem is when I deployed the code, some of the bound columns don't return data. Since I can't recreate the problem on my system, I'm at a loss as to what the problem is.
|||I'm not sure if it is possilbe to resolve your issue without actual experimentation. Your system is not identical to the live system, is it? So your argument that the code works on your system is not helpful to you. If you really want to find out where the problem is you might try and start narrowing down on the issue. That is what I suggested to you.|||It just seemed to me that you asking me to make a test case that is exactly what I have running. I think I might have it working now and it must have something to do with my adding RTRIM() and CONVERT() functions in the select statement. I removed them and it seems to work better now.

Odd issue with bound columns when fetching data.

I'm using ODBC 3.0 in code written in C.

I have an service that connects using a system DSN using the SQL Server 2000 driver. On my development system with SQL Server 2005 Express installed, the queries work fine. I prepare a statement and then bind the columns that will be in the result set. On my system, I get all the data as it should be but on a live system, I do not get the proper data for the last three rows. I don't get any error messages from the query or the column binding and there are also no extra information messages that I can retrieve.

The table is something like the following. The names are changed to protect the guilty.

CREATE TABLE DOWNLOAD

(

FIELD_1 NUMERIC( 6,0 ),

ID CHAR( 15),

FNAME( 30 ),

LNAME( 40 ),

CLIENT_ID NUMERIC( 9,0),

CLIENT_NAME CHAR( 50 ),

CODE NUMERIC( 4,0 ),

PHONE CHAR( 10 )

)

go

On my system, running the exact same binary code as the client machine, I get all of the data from all of the columns as it should be. The problem is when I run on a client's system, the CLIENT_NAME, CODE, and PHONE columns return null values even when there is data there. On my development system the SQL Server instance runs on the same machine. On the client's sytem I am connecting to a remote instance of SQL Server 2000 on another system on the network.

My quandry is what could be different between the two systems that is causing me the problems?

Can you ran SQL Profiler on both machines and see if there is any difference?|||I've turned the logging on at the client side. The logs don't show any errors and it looks like the column binding in SQLBindCol is correct. I haven't seen the server side logs but the gurus on the server side say that they can't see anything wrong there. I've played around with the SQL statement and tried using CONVERT() to change the CHAR to VARCHAR but that doesn't seem to help.

I'm at a total loss why the same code running on my development system runs fine but fails on another system. My guess is that there is some configuration difference but I don't know what that is because I am using the samve version of the SQL Server 2000 ODBC driver on both machines. Its not like there is anything odd or non standard in the table definition either.

|||Just as an update and possibly more information.

I've got it working now but I don't like the solution. What I ended up doing is not binding the columns and calling SQLGetData() after the fetch to get the column data. I don't like this because it costs me about 500 ms for the each time I call the function.

I'd still like to find a solution for why the bound columns don't work.
|||1) I would still recommend you to run SQL Profiler on the servers.
2) How do you bind exactly? Is it possible for you to write (and post the source here) a small ODBC application which demonstrates this problem?|||This is the code I use to bind the columns:

BOOL BindRecord( SQLHSTMT hStmt, PACCDATA_FIELD *pRecord, PINT piRecCount )
{
BOOL bRval = FALSE;
PACCDATA_FIELD pField;
SQLRETURN r;
INT iCnt;
CHAR szBuf[128];
SQLINTEGER len;

if( pRecord && *pRecord )
{
for( iCnt = 0; iCnt < *piRecCount; iCnt++ )
{
pField = *pRecord + iCnt;
len = pField->nLen;

switch( pField->iType )
{
case SQL_CHAR:
r = SQLBindCol( hStmt, pField->iColNum, SQL_C_CHAR, pField->pcVal, pField->nDataSize, &len );
break;

case SQL_DATETIME:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->ucVal, pField->nDataSize, &len );
break;

case SQL_DECIMAL:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->ucVal, pField->nDataSize, &len );
break;

case SQL_NUMERIC:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->lVal, pField->nDataSize, &len );
break;

case SQL_INTEGER:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->lVal, pField->nDataSize, &len );
break;

case SQL_SMALLINT:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->sVal, pField->nDataSize, &len );
break;

case SQL_DOUBLE:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->dVal, pField->nDataSize, &len );
break;

case SQL_FLOAT:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->dVal, pField->nDataSize, &len );
break;

case SQL_REAL:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, &pField->fVal, pField->nDataSize, &len );
break;

case SQL_VARCHAR:
r = SQLBindCol( hStmt, pField->iColNum, SQL_C_CHAR, pField->pvcVal, pField->nDataSize + 1, &len );
break;

case SQL_UNKNOWN_TYPE:
ST_WriteLog( "st_ctimpact", "BindRecord", "Field data type is SQL_UNKNOWN_TYPE", ST_LOG_DEBUG );
default:
r = SQLBindCol( hStmt, pField->iColNum, pField->iType, pField->ptr, pField->nDataSize, &len );
break;
}

if( r == SQL_SUCCESS_WITH_INFO )
{
lstrcpy( szBuf, "Field name: " );
lstrcat( szBuf, pField->szColName );
ST_WriteLog( "st_AcceleratedData", "BindRecord", szBuf, ST_LOG_WARNING );
ShowSQLMessages( "BindRecord", SQL_HANDLE_STMT, hStmt );
bRval = TRUE;
}
else if( r != SQL_SUCCESS )
{
lstrcpy( szBuf, "Field name: " );
lstrcat( szBuf, pField->szColName );
ST_WriteLog( "st_AcceleratedData", "BindRecord", szBuf, ST_LOG_WARNING );
ShowSQLErrors( "BindRecord", SQL_HANDLE_STMT, hStmt );
}
else
bRval = TRUE;
}
}
return( bRval );
}

A key to remember is that other columns that are bound in this way, and have the same data types, are returning data just fine. I've looked at the logs on the client side where this code works, and there are no errors and the prameters look correct as far as I can tell. Also this code works as advertized on my system but not on the live system. Right now, I don't think my customer will be willing to let me mess around on their system trying to come up with an application that would recreate the problem. Also note that I cannot recreate the problem on my own system. I had hoped that it would be broken on my system so I could debug and find out what was the problem but because it works, I can't.
|||I do not think you have to mess around with your customer system.
I would suggest you write a straightforward ODBC application from scratch just going against this very table.
Use some static arrays and bind directly with SQLBindCol, so to exclude any dependecies on how PACCDATA_FIELD or other parts of your custom code are written.
Then when you are sure it works as supposed on your machine, try it against your customer's.|||Then I guess you didn't read the thread all that well. I don't have to write a test app. The live code works fine on my system on the same table definition in the same database name as the live system. The problem is when I deployed the code, some of the bound columns don't return data. Since I can't recreate the problem on my system, I'm at a loss as to what the problem is.
|||I'm not sure if it is possilbe to resolve your issue without actual experimentation. Your system is not identical to the live system, is it? So your argument that the code works on your system is not helpful to you. If you really want to find out where the problem is you might try and start narrowing down on the issue. That is what I suggested to you.|||It just seemed to me that you asking me to make a test case that is exactly what I have running. I think I might have it working now and it must have something to do with my adding RTRIM() and CONVERT() functions in the select statement. I removed them and it seems to work better now.

ODBCBCP Driver Mismatch

Hello,
I am receiving the following error message whenever I try to replicate using Snapshot repl. (or any type of replication) from the snapshot agent:
Error Message: The process could not bulk copy out of table '[dbo].[syncobj_xxxxxxxx]'.
Error Details: ODBCBCP/Driver version mismatch
(Source: ODBC SQL Server Driver (ODBC); Error number: 0)
I have checked the versions of the odbcbcp.dll on both of my SQL Servers (both of which are win2k3 w/ SQL Server 2000 sp3) and they are both 2000.85.1022.0. The version number of sqlsrv32.dll and sqlsrv32.rll are 2000.85.1025.0. Do all three have to mat
ch, is that my problem? Please HELP!! I can't replicate at all!
there are some reports that this problem can be solved by upgrading to a
consistent MDAC versions on both machines.
"Paul Pelletier" <anonymous@.discussions.microsoft.com> wrote in message
news:3E372B82-39B2-4A93-B7DE-5B7740527F13@.microsoft.com...
> Hello,
> I am receiving the following error message whenever I try to replicate
using Snapshot repl. (or any type of replication) from the snapshot agent:
> Error Message: The process could not bulk copy out of table
'[dbo].[syncobj_xxxxxxxx]'.
> Error Details: ODBCBCP/Driver version mismatch
> (Source: ODBC SQL Server Driver (ODBC); Error number: 0)
> I have checked the versions of the odbcbcp.dll on both of my SQL Servers
(both of which are win2k3 w/ SQL Server 2000 sp3) and they are both
2000.85.1022.0. The version number of sqlsrv32.dll and sqlsrv32.rll are
2000.85.1025.0. Do all three have to match, is that my problem? Please
HELP!! I can't replicate at all!
|||Hillary,
I have, I re-applied MDAC 2.7 on both SQL Servers and still the same problem. Any other possible solutions?
Do all there files have to have the same version numbers?
Thanks,
Paul
|||Check the version of the ODBC32.dll. It could be the one that is
mismatched. It should be version 3.525.1022.0.
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||It is mismatched in a sense. The odbcbcp.dll is version 2000.85.1022.0. The sqlsrv32.dll is 2000.85.1025.0. The sqlsrv32.rll is 2000.85.1025.0. So really the one that is mismatched is the sqlsrv32.dll, but which version should be the correct version f
or all three, the 1025 or 1022?
Thanks again,
Paul
|||Sorry about the previous post, I did not completely read your post and I missed the fact that you were talking about a completely different dll, I'm a tard! Anyway both of the odbc32.dll do match on both machines and they are in fact 3.525.1022.0. Where
now?

ODBC/OLEDB support for HTTP-based comms to SQL server?

Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
server over HTTP/port 80?
In other words, I want to be able to issue SQL commands (INSERTs,
UPDATEs, SELECTs) from a client application to a database that happens
to be sitting on a server somewhere that I can only reach via HTTP
(https actually), due to firewall restrictions. I don't want to have
to modify my application, but note that it has the ability to use any
ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
connection string supplied. I certainly don't want to have to care that
requests and results are being transmitted in XML SOAP format (or
whatever).
>From the various connection strings I've seen around, and the little
information I've seen regarding HTTP requests to SQL server, it
certainly isn't possible with the standard drivers etc. that Microsoft
supply, but if so, surely there's a demand for such a thing?
In article <1163482089.627876.121280@.h54g2000cwb.googlegroups .com>, wizofaus@.hotmail.com wrote:
>Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
>server over HTTP/port 80?
>In other words, I want to be able to issue SQL commands (INSERTs,
>UPDATEs, SELECTs) from a client application to a database that happens
>to be sitting on a server somewhere that I can only reach via HTTP
>(https actually), due to firewall restrictions. I don't want to have
>to modify my application, but note that it has the ability to use any
>ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
>connection string supplied. I certainly don't want to have to care that
>requests and results are being transmitted in XML SOAP format (or
>whatever).
>information I've seen regarding HTTP requests to SQL server, it
>certainly isn't possible with the standard drivers etc. that Microsoft
>supply, but if so, surely there's a demand for such a thing?
>
You're not limited to http, you're limited to port 80
Just set SQL Server to listen on port 80, instead of the traditional 1433.
It sounds like this is at least partly internet accesible.
Be REAL careful about exposed SQL Servers on the net. There are a lot of
exploits...
|||Brian Bunin wrote:
> In article <1163482089.627876.121280@.h54g2000cwb.googlegroups .com>, wizofaus@.hotmail.com wrote:
> You're not limited to http, you're limited to port 80
> Just set SQL Server to listen on port 80, instead of the traditional 1433.
> It sounds like this is at least partly internet accesible.
No, because the firewall explicitly examines the packets to ensure they
are HTTP(S) packets only.
And actually I'd expect to use port 443.

> Be REAL careful about exposed SQL Servers on the net. There are a lot of
> exploits...
Well of course, but as it is the machine has open Terminal Service
access (of course you need a username and password ), so it's not
really less secure exposing another port for direct SQL server access.
The database doesn't hold particularly critical or sensitive data
anyway.
But SQL server *does* have (or at least, can support, along with IIS) a
web based interface...so why shouldn't I be able to talk to it without
caring that it is web-based or otherwise?
|||wizofaus@.hotmail.com wrote:
> Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
> server over HTTP/port 80?
> In other words, I want to be able to issue SQL commands (INSERTs,
> UPDATEs, SELECTs) from a client application to a database that happens
> to be sitting on a server somewhere that I can only reach via HTTP
> (https actually), due to firewall restrictions. I don't want to have
> to modify my application, but note that it has the ability to use any
> ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
> connection string supplied. I certainly don't want to have to care that
> requests and results are being transmitted in XML SOAP format (or
> whatever).
> information I've seen regarding HTTP requests to SQL server, it
> certainly isn't possible with the standard drivers etc. that Microsoft
> supply, but if so, surely there's a demand for such a thing?
>
Have you considered creating some web methods?
That would allow you to consume and utilize SQL data over port 80, but
not open up your entire range of functions.
The Texeme Construct
http://you-read-it-here-first.com

ODBC/OLEDB support for HTTP-based comms to SQL server?

Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
server over HTTP/port 80?
In other words, I want to be able to issue SQL commands (INSERTs,
UPDATEs, SELECTs) from a client application to a database that happens
to be sitting on a server somewhere that I can only reach via HTTP
(https actually), due to firewall restrictions. I don't want to have
to modify my application, but note that it has the ability to use any
ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
connection string supplied. I certainly don't want to have to care that
requests and results are being transmitted in XML SOAP format (or
whatever).
>From the various connection strings I've seen around, and the little
information I've seen regarding HTTP requests to SQL server, it
certainly isn't possible with the standard drivers etc. that Microsoft
supply, but if so, surely there's a demand for such a thing?In article <1163482089.627876.121280@.h54g2000cwb.googlegroups.com>, wizofaus@.hotmail.com wro
te:
>Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
>server over HTTP/port 80?
>In other words, I want to be able to issue SQL commands (INSERTs,
>UPDATEs, SELECTs) from a client application to a database that happens
>to be sitting on a server somewhere that I can only reach via HTTP
>(https actually), due to firewall restrictions. I don't want to have
>to modify my application, but note that it has the ability to use any
>ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
>connection string supplied. I certainly don't want to have to care that
>requests and results are being transmitted in XML SOAP format (or
>whatever).
>information I've seen regarding HTTP requests to SQL server, it
>certainly isn't possible with the standard drivers etc. that Microsoft
>supply, but if so, surely there's a demand for such a thing?
>
You're not limited to http, you're limited to port 80
Just set SQL Server to listen on port 80, instead of the traditional 1433.
It sounds like this is at least partly internet accesible.
Be REAL careful about exposed SQL Servers on the net. There are a lot of
exploits...|||Brian Bunin wrote:
> In article <1163482089.627876.121280@.h54g2000cwb.googlegroups.com>, wizofa
us@.hotmail.com wrote:
> You're not limited to http, you're limited to port 80
> Just set SQL Server to listen on port 80, instead of the traditional 1433.
> It sounds like this is at least partly internet accesible.
No, because the firewall explicitly examines the packets to ensure they
are HTTP(S) packets only.
And actually I'd expect to use port 443.

> Be REAL careful about exposed SQL Servers on the net. There are a lot of
> exploits...
Well of course, but as it is the machine has open Terminal Service
access (of course you need a username and password ), so it's not
really less secure exposing another port for direct SQL server access.
The database doesn't hold particularly critical or sensitive data
anyway.
But SQL server *does* have (or at least, can support, along with IIS) a
web based interface...so why shouldn't I be able to talk to it without
caring that it is web-based or otherwise?|||wizofaus@.hotmail.com wrote:
> Does there exist an ODBC or OLEDB/ADODB driver for talking to SQL
> server over HTTP/port 80?
> In other words, I want to be able to issue SQL commands (INSERTs,
> UPDATEs, SELECTs) from a client application to a database that happens
> to be sitting on a server somewhere that I can only reach via HTTP
> (https actually), due to firewall restrictions. I don't want to have
> to modify my application, but note that it has the ability to use any
> ODBC, ADO/OLEDB or a direct SQL native driver, depending on the
> connection string supplied. I certainly don't want to have to care that
> requests and results are being transmitted in XML SOAP format (or
> whatever).
> information I've seen regarding HTTP requests to SQL server, it
> certainly isn't possible with the standard drivers etc. that Microsoft
> supply, but if so, surely there's a demand for such a thing?
>
Have you considered creating some web methods?
That would allow you to consume and utilize SQL data over port 80, but
not open up your entire range of functions.
The Texeme Construct
http://you-read-it-here-first.com

ODBC, SQL Server, "FOR XML" & Cursors error

Hi,


Has anybody had any luck using the Microsoft SQLServer ODBC drivers (Driver version: 03.81.9030, ODBC version : 03.52)

to connect to a SQL Server 2000 database and passing in a SELECT with a FOR XML clause. I keep

getting Error [Microsoft][ODBC SQL Server Driver][SQL Server]The FOR XML clause is not allowed in a CURSOR statement

., State: 42000, Error: 6819.

Is there a work around (eg putting the select in a stored procedure) or am I missing something ?

I am using SQLExecDirect() to execute the statement.

Or could any one suggest a better way to retrieve data from a standard table in XML formated string?


Please Help!!If you are using a cursor or a loop (it may actually work in a loop, but methinks NOT), then create a stored procedure that contains just SELECT...FOR XML AUTO/RAW/whatever. But I don't see a point doing that because further processing of the data retrieved in XML format within a stored procedure is not supported. Check this site for general guidelines on using FOR XML clause:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsql/ac_openxml_0alh.asp

ODBC, SQL Server Driver alias error

I am running SQL Server 2000, trying to create a new database and
received the following error:
[Microsoft][ODBC SQL Server Driver][SQL Server Login]
is aliased or mapped to a user in one or more databases. Drop the
user or alias before dropping the login.
Can anyone assist me with this error.
Thanks."Dave" <dave@.groupfive.net> wrote in message
news:993ef28c.0403120844.663b8391@.posting.google.com...
> I am running SQL Server 2000, trying to create a new database and
> received the following error:
> [Microsoft][ODBC SQL Server Driver][SQL Server Login]
> is aliased or mapped to a user in one or more databases. Drop the
> user or alias before dropping the login.
If you do not have system administrator rights, please see the following
article:
http://support.microsoft.com/defaul...3&Product=sql2k
Steve

ODBC vs OLEDB driver for SQLserver

Hi:
Which is the preferable driver to connect to the latest SQLServer
(SQL2000) ?
I have an application written in vb6, some of the data entry screen
hang (but most of the time it work perfectly), we have to clear off all
the sql connection from Enterprise manager and relogin into the system
again.
Is it because the driver we used (ODBC driver) cause the problem ?
because another application which use OLEDB driver has no problem at
all.
Any idea ?
Thanks
JCVoonHi
Look at the following page:
http://msdn.microsoft.com/data/mdac/default.aspx?pull=/library/en-us/dnmdac/html/data_mdacroadmap.asp
OLE DB is the newer technology over ODBC.
If you screens hang, check for clocking when this is occurring (run sp_who2
in Query Analyzer) to see what is going on. You might have one user blocking
another user.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"jcvoon" <jcvoon_99@.yahoo.com> wrote in message
news:1128133741.955485.315030@.o13g2000cwo.googlegroups.com...
> Hi:
> Which is the preferable driver to connect to the latest SQLServer
> (SQL2000) ?
> I have an application written in vb6, some of the data entry screen
> hang (but most of the time it work perfectly), we have to clear off all
> the sql connection from Enterprise manager and relogin into the system
> again.
> Is it because the driver we used (ODBC driver) cause the problem ?
> because another application which use OLEDB driver has no problem at
> all.
> Any idea ?
> Thanks
> JCVoon
>|||Mike Epprecht
Thanks for the reply.
I'm not SQL expert, can u please tell me when one user will block
another user ?
Regards
JCVoon

ODBC vs OLEDB driver for SQLserver

Hi:
Which is the preferable driver to connect to the latest SQLServer
(SQL2000) ?
I have an application written in vb6, some of the data entry screen
hang (but most of the time it work perfectly), we have to clear off all
the sql connection from Enterprise manager and relogin into the system
again.
Is it because the driver we used (ODBC driver) cause the problem ?
because another application which use OLEDB driver has no problem at
all.
Any idea ?
Thanks
JCVoon
Hi
Look at the following page:
http://msdn.microsoft.com/data/mdac/...dacroadmap.asp
OLE DB is the newer technology over ODBC.
If you screens hang, check for clocking when this is occurring (run sp_who2
in Query Analyzer) to see what is going on. You might have one user blocking
another user.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"jcvoon" <jcvoon_99@.yahoo.com> wrote in message
news:1128133741.955485.315030@.o13g2000cwo.googlegr oups.com...
> Hi:
> Which is the preferable driver to connect to the latest SQLServer
> (SQL2000) ?
> I have an application written in vb6, some of the data entry screen
> hang (but most of the time it work perfectly), we have to clear off all
> the sql connection from Enterprise manager and relogin into the system
> again.
> Is it because the driver we used (ODBC driver) cause the problem ?
> because another application which use OLEDB driver has no problem at
> all.
> Any idea ?
> Thanks
> JCVoon
>
|||Mike Epprecht
Thanks for the reply.
I'm not SQL expert, can u please tell me when one user will block
another user ?
Regards
JCVoon

ODBC vs OLEDB driver for SQLserver

Hi:
Which is the preferable driver to connect to the latest SQLServer
(SQL2000) ?
I have an application written in vb6, some of the data entry screen
hang (but most of the time it work perfectly), we have to clear off all
the sql connection from Enterprise manager and relogin into the system
again.
Is it because the driver we used (ODBC driver) cause the problem ?
because another application which use OLEDB driver has no problem at
all.
Any idea ?
Thanks
JCVoonHi
Look at the following page:
http://msdn.microsoft.com/data/mdac...mdacroadmap.asp
OLE DB is the newer technology over ODBC.
If you screens hang, check for clocking when this is occurring (run sp_who2
in Query Analyzer) to see what is going on. You might have one user blocking
another user.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"jcvoon" <jcvoon_99@.yahoo.com> wrote in message
news:1128133741.955485.315030@.o13g2000cwo.googlegroups.com...
> Hi:
> Which is the preferable driver to connect to the latest SQLServer
> (SQL2000) ?
> I have an application written in vb6, some of the data entry screen
> hang (but most of the time it work perfectly), we have to clear off all
> the sql connection from Enterprise manager and relogin into the system
> again.
> Is it because the driver we used (ODBC driver) cause the problem ?
> because another application which use OLEDB driver has no problem at
> all.
> Any idea ?
> Thanks
> JCVoon
>|||Mike Epprecht
Thanks for the reply.
I'm not SQL expert, can u please tell me when one user will block
another user ?
Regards
JCVoon

ODBC Virtual Driver

Hi,
I have the following requirement :

I need to have a way to intercept the SQL queries from an application written in VB and using a ODBC driver and modify the SQL queries before it goes through the ODBC driver and then to the database. This I need to do without modifying the original application.

The solution I have in mind is to write a ODBC virtual driver and configure my application to use my virtual ODBC driver. The ODBC virtual driver in turn will use the actual ODBC driver to the database. The virtual driver will basically intercept the SQL queries, modify it and then give it to the real ODBC driver.

My question is

1. Is this a feasible solution?
2. What should I do in order to implement the vitrtual ODBC driver.
3. Any pointer will be appreciated.

Thanks
Jake.NEver heard of virtual odbc driver, but you may find some information from http://www.microsoft.com site.|||Hi,
What I meant by Virtual driver is basically a ODBC proxy which can sit between my application and the ODBC driver and intercept the SQL queries.

Thanks
Jake

Originally posted by Satya
NEver heard of virtual odbc driver, but you may find some information from http://www.microsoft.com site.|||I'm working from memory here, but I think an ODBC Proxy something like you are describing is included as a VC project in the ODBC Driver SDK.

-PatP

ODBC Version with MDAC 2.8?

I am unable to determine what version of Microsoft's SQL Server ODBC
driver comes with MDAC 2.8.
Currently I'm using driver "SQL SERVER" SQLSRV32.DLL, 10/27/2003,
version 2000.81.9042.00 (with Windows 2000, SQL Server 2000, Access XP)
and I only want to upgrade to MDAC 2.8 if it updates this ODBC driver.
Any ideas?
MDAC 2.8 installs version 2000.85.1022.0
-Sue
On Fri, 16 Apr 2004 18:40:42 GMT, John Smith
<JohnSmith@.hotmail.com> wrote:

>I am unable to determine what version of Microsoft's SQL Server ODBC
>driver comes with MDAC 2.8.
>Currently I'm using driver "SQL SERVER" SQLSRV32.DLL, 10/27/2003,
>version 2000.81.9042.00 (with Windows 2000, SQL Server 2000, Access XP)
>and I only want to upgrade to MDAC 2.8 if it updates this ODBC driver.
>Any ideas?

ODBC Version with MDAC 2.8?

I am unable to determine what version of Microsoft's SQL Server ODBC
driver comes with MDAC 2.8.
Currently I'm using driver "SQL SERVER" SQLSRV32.DLL, 10/27/2003,
version 2000.81.9042.00 (with Windows 2000, SQL Server 2000, Access XP)
and I only want to upgrade to MDAC 2.8 if it updates this ODBC driver.
Any ideas?MDAC 2.8 installs version 2000.85.1022.0
-Sue
On Fri, 16 Apr 2004 18:40:42 GMT, John Smith
<JohnSmith@.hotmail.com> wrote:

>I am unable to determine what version of Microsoft's SQL Server ODBC
>driver comes with MDAC 2.8.
>Currently I'm using driver "SQL SERVER" SQLSRV32.DLL, 10/27/2003,
>version 2000.81.9042.00 (with Windows 2000, SQL Server 2000, Access XP)
>and I only want to upgrade to MDAC 2.8 if it updates this ODBC driver.
>Any ideas?

ODBC to SQL Express - SQL Driver versus SQL Native Client

I have a SQL express database which I need to access from a shared hosting plan. I can create an ODBC connection through the hosting provider's control panel for SQL Server, but it won't connect. I tested this locally and discovered that the SQL Native Client connects fine, but the previous SQL Server driver does not. This seems to only happen with SQL 2005 Express edition; it works with the Developer Edition. Does SQL Express only use the Native SQL Client?

Thanks in advance for your help!

NO, it does not, you can connect using the ADO / ADO.NET as well. Which error information do you get ? Are you using a user instance ? This is though only supported by the SNAC client.

Jens K. Suessmeyer

http://www.sqlserver2005.de

|||

Thank you!!! The issue was that it was installed as a user instance and not the default instance. With a user instance, you can apparently only connect using the SQL Native Client. I reinstalled SQL 2005 Express as the default instance and the older SQL Server ODBC driver worked!

ODBC Text Driver Issue for Tab delimited File

I am trying to do a ODBC Connection to a Tab delimited file. However it is
not parsing the tabs. Any advice?
Thanks
Here is my connection string:
Private ConnectionString As String = "Driver={Microsoft Text Driver (*.txt;
*.csv)};DRIVERID=27;Fil=Text;Format=TABDELIMITED;" & _
"COLNAMEHEADER=TRUE;DefaultDir=" & _
Application.StartupPath
And my calls to query the file:
Dim Adapter As New OdbcDataAdapter("SELECT * FROM Test.csv", Con)
When you use the Text Driver, the format is determined by
the schema.ini file. The format statement goes in the
schema.ini file. That's how I remember it anyway.
The following link has more information on the drive and a
link to information on the schema.ini file - watch out for
line wrap on the link:
http://msdn.microsoft.com/library/de..._details. asp
-Sue
On Tue, 1 Feb 2005 06:55:04 -0800, "Neil"
<Neil@.discussions.microsoft.com> wrote:

>I am trying to do a ODBC Connection to a Tab delimited file. However it is
>not parsing the tabs. Any advice?
>Thanks
>Here is my connection string:
> Private ConnectionString As String = "Driver={Microsoft Text Driver (*.txt;
>*.csv)};DRIVERID=27;Fil=Text;Format=TABDELIMITED; " & _
> "COLNAMEHEADER=TRUE;DefaultDir=" & _
> Application.StartupPath
>And my calls to query the file:
> Dim Adapter As New OdbcDataAdapter("SELECT * FROM Test.csv", Con)
>
>
|||Thanks Sue. That was the solution.
Neil
"Sue Hoegemeier" wrote:

> When you use the Text Driver, the format is determined by
> the schema.ini file. The format statement goes in the
> schema.ini file. That's how I remember it anyway.
> The following link has more information on the drive and a
> link to information on the schema.ini file - watch out for
> line wrap on the link:
> http://msdn.microsoft.com/library/de..._details. asp
> -Sue
> On Tue, 1 Feb 2005 06:55:04 -0800, "Neil"
> <Neil@.discussions.microsoft.com> wrote:
>
>

ODBC Text Driver Issue for Tab delimited File

I am trying to do a ODBC Connection to a Tab delimited file. However it is
not parsing the tabs. Any advice?
Thanks
Here is my connection string:
Private ConnectionString As String = "Driver={Microsoft Text Driver (*.
txt;
*. csv)};DRIVERID=27;Fil=Text;Format=TABDEL
IMITED;" & _
"COLNAMEHEADER=TRUE;DefaultDir=" & _
Application.StartupPath
And my calls to query the file:
Dim Adapter As New OdbcDataAdapter("SELECT * FROM Test.csv", Con)When you use the Text Driver, the format is determined by
the schema.ini file. The format statement goes in the
schema.ini file. That's how I remember it anyway.
The following link has more information on the drive and a
link to information on the schema.ini file - watch out for
line wrap on the link:
http://msdn.microsoft.com/library/d...ail
s.asp
-Sue
On Tue, 1 Feb 2005 06:55:04 -0800, "Neil"
<Neil@.discussions.microsoft.com> wrote:

>I am trying to do a ODBC Connection to a Tab delimited file. However it is
>not parsing the tabs. Any advice?
>Thanks
>Here is my connection string:
> Private ConnectionString As String = "Driver={Microsoft Text Driver (
*.txt;
>*. csv)};DRIVERID=27;Fil=Text;Format=TABDEL
IMITED;" & _
> "COLNAMEHEADER=TRUE;DefaultDir=" & _
> Application.StartupPath
>And my calls to query the file:
> Dim Adapter As New OdbcDataAdapter("SELECT * FROM Test.csv", Con)
>
>|||Thanks Sue. That was the solution.
Neil
"Sue Hoegemeier" wrote:

> When you use the Text Driver, the format is determined by
> the schema.ini file. The format statement goes in the
> schema.ini file. That's how I remember it anyway.
> The following link has more information on the drive and a
> link to information on the schema.ini file - watch out for
> line wrap on the link:
> http://msdn.microsoft.com/library/d...a
ils.asp
> -Sue
> On Tue, 1 Feb 2005 06:55:04 -0800, "Neil"
> <Neil@.discussions.microsoft.com> wrote:
>
>

odbc sql server driver timeout expired

Hi,

Has anyone ever had trouble using the query analyzer tool through a vpn
client? I'm able to connect outside of work to a sqlserver db on my
company lan with enterprise mgr, but the query analyzer times out every
time I try to connect from outside of work. Both utilities work fine at
work (no vpn tunnel).

The exact error is:

Unable to connect to server blahblahblah:
ODBC: Msg 0, Level 16, State 1
[Microsoft][ODBC SQL Server Driver] Timeout expired

I've tried increasing the sqlserver odbc driver's CPTimeout without success.

Appreciate any advice.
Eric"efinney" <efinney@.mitre.org> wrote in message
news:cjvgck$a1f$1@.newslocal.mitre.org...
> Hi,
> Has anyone ever had trouble using the query analyzer tool through a vpn
> client? I'm able to connect outside of work to a sqlserver db on my
> company lan with enterprise mgr, but the query analyzer times out every
> time I try to connect from outside of work. Both utilities work fine at
> work (no vpn tunnel).
> The exact error is:
> Unable to connect to server blahblahblah:
> ODBC: Msg 0, Level 16, State 1
> [Microsoft][ODBC SQL Server Driver] Timeout expired
> I've tried increasing the sqlserver odbc driver's CPTimeout without
> success.
> Appreciate any advice.
> Eric

Assuming there are no name resolution issues, then you need to make sure the
correct ports are open over the VPN:

http://support.microsoft.com/defaul...2&Product=sql2k

Simon|||Hi Eric

Can you do

Telnet <SQL Server's name or IP address> 1433

If it connects to port 1433 through VPN then it means your connection
is good then you can start diagnosing why you are getting timeouts,
perhaps slow connection or flakey VPN connection.

Regards

Shehzad

efinney <efinney@.mitre.org> wrote in message news:<cjvgck$a1f$1@.newslocal.mitre.org>...
> Hi,
> Has anyone ever had trouble using the query analyzer tool through a vpn
> client? I'm able to connect outside of work to a sqlserver db on my
> company lan with enterprise mgr, but the query analyzer times out every
> time I try to connect from outside of work. Both utilities work fine at
> work (no vpn tunnel).
> The exact error is:
> Unable to connect to server blahblahblah:
> ODBC: Msg 0, Level 16, State 1
> [Microsoft][ODBC SQL Server Driver] Timeout expired
> I've tried increasing the sqlserver odbc driver's CPTimeout without success.
> Appreciate any advice.
> Eric

ODBC SQL Server Driver connection issues

Issue:
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (rec
v()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Connection Broken
above error is recieved during a heavy SQL query from Query Analyzer & a
OLEDB application client. Other queries like sp_who2 operate fine.
Environment:
SQL Servers running both SQL 2000 & 2005 (currently disabled) patched and
hotfix'd to most recent. Windows 2003 Servers patched and hotfix'd also. MDA
C
2.8.
Interestingly, when the query is run with SQL Server Management Studio it
runs just fine. Is there a compatiblity issue running both of these SQL
server versions on the same machine? When I run the query from a different
machine without the server software, just the two client versions I don't
experience this network connectivity issue.
ThanksOn May 24, 9:33 pm, Outlook 2003 user
<Outlook2003u...@.discussions.microsoft.com> wrote:
> Issue:
> [Microsoft][ODBCSQL Server Driver][DBNETLIB]ConnectionRead (re
cv()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
> Connection Broken
> above error is recieved during a heavy SQL query from Query Analyzer & aOL
EDBapplication client. Other queries like sp_who2 operate fine.
> Environment:
> SQL Servers running both SQL 2000 & 2005 (currently disabled) patched and
> hotfix'd to most recent. Windows 2003 Servers patched and hotfix'd also. M
DAC
> 2.8.
> Interestingly, when the query is run with SQL Server Management Studio it
> runs just fine. Is there a compatiblity issue running both of these SQL
> server versions on the same machine? When I run the query from a different
> machine without the server software, just the two client versions I don't
> experience this network connectivity issue.
> Thanks
Check for registry setting SynAttack in KB|||Thanks, but I added that a while ago with no success.
"M A Srinivas" wrote:

> On May 24, 9:33 pm, Outlook 2003 user
> <Outlook2003u...@.discussions.microsoft.com> wrote:
> Check for registry setting SynAttack in KB
>|||Just a follow-up to my post.
I figured out that the TOE was not operating correctly. This situation was
happening on new DELL 2950 & 1950 Servers with TCP/IP Offloading Engine
enables. After completely disabling this feature, via Microsoft & DELL
hardware the erroneous ODBC error stop occurring.
Thanks,
Outlook 2003 User (lol)
"Outlook 2003 user" wrote:
[vbcol=seagreen]
> Thanks, but I added that a while ago with no success.
> "M A Srinivas" wrote:
>

ODBC SQL Server Driver connection issues

Issue:
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionRead (recv()).
Server: Msg 11, Level 16, State 1, Line 0
General network error. Check your network documentation.
Connection Broken
above error is recieved during a heavy SQL query from Query Analyzer & a
OLEDB application client. Other queries like sp_who2 operate fine.
Environment:
SQL Servers running both SQL 2000 & 2005 (currently disabled) patched and
hotfix'd to most recent. Windows 2003 Servers patched and hotfix'd also. MDAC
2.8.
Interestingly, when the query is run with SQL Server Management Studio it
runs just fine. Is there a compatiblity issue running both of these SQL
server versions on the same machine? When I run the query from a different
machine without the server software, just the two client versions I don't
experience this network connectivity issue.
Thanks
On May 24, 9:33 pm, Outlook 2003 user
<Outlook2003u...@.discussions.microsoft.com> wrote:
> Issue:
> [Microsoft][ODBCSQL Server Driver][DBNETLIB]ConnectionRead (recv()).
> Server: Msg 11, Level 16, State 1, Line 0
> General network error. Check your network documentation.
> Connection Broken
> above error is recieved during a heavy SQL query from Query Analyzer & aOLEDBapplication client. Other queries like sp_who2 operate fine.
> Environment:
> SQL Servers running both SQL 2000 & 2005 (currently disabled) patched and
> hotfix'd to most recent. Windows 2003 Servers patched and hotfix'd also. MDAC
> 2.8.
> Interestingly, when the query is run with SQL Server Management Studio it
> runs just fine. Is there a compatiblity issue running both of these SQL
> server versions on the same machine? When I run the query from a different
> machine without the server software, just the two client versions I don't
> experience this network connectivity issue.
> Thanks
Check for registry setting SynAttack in KB
|||Thanks, but I added that a while ago with no success.
"M A Srinivas" wrote:

> On May 24, 9:33 pm, Outlook 2003 user
> <Outlook2003u...@.discussions.microsoft.com> wrote:
> Check for registry setting SynAttack in KB
>
|||Just a follow-up to my post.
I figured out that the TOE was not operating correctly. This situation was
happening on new DELL 2950 & 1950 Servers with TCP/IP Offloading Engine
enables. After completely disabling this feature, via Microsoft & DELL
hardware the erroneous ODBC error stop occurring.
Thanks,
Outlook 2003 User (lol)
"Outlook 2003 user" wrote:
[vbcol=seagreen]
> Thanks, but I added that a while ago with no success.
> "M A Srinivas" wrote: