By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,412 Members | 1,630 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,412 IT Pros & Developers. It's quick & easy.

ODBC mystery

P: n/a
There's a SP on all of our servers that includes a #temp table where
every column is varchar(255). The SP populates the table and at the
end does a select *. One column is populated from the length column
in syscolumns, which is a smallint.

The dataset is retrieved in a C++ program using ODBC. (#define
ODBCVER 0x0351 from sql.h) It does SQLGetData with a data type of
SQL_CHAR. This works fine on the SQL 2000 servers. But we have one
SQL 2005 server, and on that one, the SQLGetData for the column that
was originally numeric throws an exception, although it works if the
data type is given as SQL_REAL.

I suspect it's somehow related to ODBC version vs. SQL version. I'd
appreciate a tip on what to look for. BTW, I have SQL 2005 Express
Edition installed on my workstation (which is where I discovered
this), and the service is usually running. Also MDAC 2.8 SP1, and
ODBC version 3.525.1117.0.

Thanks,
Jim Geissman
Sep 5 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
(ja************@countrywide.com) writes:
There's a SP on all of our servers that includes a #temp table where
every column is varchar(255). The SP populates the table and at the
end does a select *. One column is populated from the length column
in syscolumns, which is a smallint.

The dataset is retrieved in a C++ program using ODBC. (#define
ODBCVER 0x0351 from sql.h) It does SQLGetData with a data type of
SQL_CHAR. This works fine on the SQL 2000 servers. But we have one
SQL 2005 server, and on that one, the SQLGetData for the column that
was originally numeric throws an exception, although it works if the
data type is given as SQL_REAL.
And the error message is?

And the column you are having problem with is the one with
syscolumns.length?
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

Sep 5 '08 #2

P: n/a
And the error message is?
>
And the column you are having problem with is the one with
syscolumns.length?

Erland Sommarskog, SQL Server MVP, esq...@sommarskog.se
Thanks, Erland.

I'm not sure about the error message. I'll see if I can identify it
on Monday. It throws a C++ exception, which is caught several levels
above the ODBC wrapper object, so I may need to add some code to catch
it in the procedure that calls SQLGetData.

And yes, it's the column filled with syscolumns.length.

Jim
Sep 6 '08 #3

P: n/a
(ja************@countrywide.com) writes:
I'm not sure about the error message. I'll see if I can identify it
on Monday. It throws a C++ exception, which is caught several levels
above the ODBC wrapper object, so I may need to add some code to catch
it in the procedure that calls SQLGetData.
My experience is that getting hold of the actual error message is
essential to resolves such issues effeciently. Without a good error
message you are just fumbling around in completely dark room.

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

Sep 6 '08 #4

P: n/a
The SQL return code is 0 or SUCCESS. But somewhere between that point
and returning to the calling code C++ throws an exception, which I
haven't been able to identify yet (don't know what type of
exception). I'll let you know if I learn more.

Jim
Sep 8 '08 #5

P: n/a
(ja************@countrywide.com) writes:
The SQL return code is 0 or SUCCESS. But somewhere between that point
and returning to the calling code C++ throws an exception, which I
haven't been able to identify yet (don't know what type of
exception). I'll let you know if I learn more.
So it is likely to be a C++ problem. Not sure that I can help there. :-)
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Links for SQL Server Books Online:
SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx
SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx
SQL 2000: http://www.microsoft.com/sql/prodinf...ons/books.mspx

Sep 8 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.