PHWinfo banniere

Titres
PORTAIL ANNUAIRE ARTICLES COMPARATEUR HÉBERGEURS DEVIS FORUMS RÉDUCTEUR D'URL
Précédent   PHWinfo > Forums Hébergement > Forum Hébergement serveur > comp.db.ms-sqlserver > ODBC mystery
S'inscrire FAQ Membres Recherche Messages du jour Marquer les forums comme lus
ODBC mystery

Réponse
 
LinkBack Outils de la discussion
Vieux 05/09/2008, 19h22   #1
james_geissman@countrywide.com
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut ODBC mystery

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
  Réponse avec citation
Vieux 05/09/2008, 23h22   #2
Erland Sommarskog
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: ODBC mystery

(james_geissman@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, esquel@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

  Réponse avec citation
Vieux 06/09/2008, 06h22   #3
james_geissman@countrywide.com
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: ODBC mystery

> 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
  Réponse avec citation
Vieux 06/09/2008, 11h12   #4
Erland Sommarskog
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: ODBC mystery

(james_geissman@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, esquel@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

  Réponse avec citation
Vieux 08/09/2008, 23h04   #5
james_geissman@countrywide.com
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: ODBC mystery

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
  Réponse avec citation
Vieux 08/09/2008, 23h34   #6
Erland Sommarskog
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: ODBC mystery

(james_geissman@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 there. :-)


--
Erland Sommarskog, SQL Server MVP, esquel@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

  Réponse avec citation
Réponse


Outils de la discussion

Règles de messages
Vous ne pouvez pas créer de nouvelles discussions
Vous ne pouvez pas envoyer des réponses
Vous ne pouvez pas envoyer des pièces jointes
Vous ne pouvez pas modifier vos messages

Les balises BB sont activées : oui
Les smileys sont activés : oui
La balise [IMG] est activée : oui
Le code HTML peut être employé : non
Trackbacks are oui
Pingbacks are oui
Refbacks are oui


Fuseau horaire GMT +1. Il est actuellement 02h29.


Édité par : vBulletin® version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0 RC5 Tous droits réservés.
Version française #16 par l'association vBulletin francophone
PHWinfo est un site Éducation Sans Frontières ©2000-2008
Ad Management by RedTyger
©Tous droits réservés par les parties respectives
Page generated in 0,10489 seconds with 14 queries