[ODBC] Gestion des erreurs

Version imprimable

19/04/2006, 12h14
tsp

[ODBC] Gestion des erreurs

Bonjour,
j'ai fait une DLL en c++ qui attaque n'importe quelle base de donnée avec ODBC. J'utilise les fonctions SQLConnectDriver, SQLExecDirect de la librairie sql.h. Chacune de ces fonctions renvoient un code SQLRETURN, lorsque celui ci est égal à SQL_ERROR, on peut aller chercher l'erreur avec la fonction SQLGetDiagRec. Maintenant que la présentation est faite, j'aimerais savoir qui en théorie renvoie cette erreur ?? Parce que je me suis rendu compte que si par exemple je fais une erreur dans ma chaine de connexion, à savoir :

"DIVER={MySQL ODBC 3.51 Driver};server=192.168.99.2;Option=16834;Database=rh;UID=test;PASSWORD=1234;"

en ecrivant DIVER au lieu de DRIVER, il y a une erreur qui m'est retournée par le gestionnaire de pilote ODBC :

[Microsoft][Gestionnaire de pilotes ODBC] Échec du dialogue

erreur qui est trés loin d'etre explicite, mais qui peux paraitre logique étant donné qu'il a planté sur le premier mot donc ne sait meme pas quel driver je veux utiliser.

Maintenant si je fais mon erreur apres le driver, à savoir par exemple :

"DIVER={MySQL ODBC 3.51 Driver};srver=192.168.99.2;Option=16834;Database=rh;UID=test;PASSWORD=1234;"

SRVER au lieu de SERVEUR, j'obtiens une erreur de la part du driver MySQL

[MySQL][ODBC 3.51 Driver]Invalid window handle for connection completion argument.

Pour l'instant tout semble logique. Mais ce que je ne comprends pas c'est quand je fais une erreur sur une requete SQL, par exemple en demandant l'execution de :

"Slect * from table"

j'obtiens toujours, quelle que soit mon erreur, l'erreur suivante :

[Microsoft][Gestionnaire de pilotes ODBC] Erreur de séquence de la fonction

Ce qui est loin d'etre une erreur explicite. De plus je suis sur d'avoir deja eu une erreur explicite en retour d'une erreur SQL. De plus cette erreur me semble renvoyée par le gestionnaire ODBC et non par le driver MYSql, ce que je ne trouve pas logique

Donc voici mes questions, suis je fou ? ou en effet ce n'est pas normal ? Ensuite j'aimerais savoir si quelqu'un aurait une idée de pourquoi j'obtiens une erreur du gestionnaire de pilotes ODBC plutot que du driver MySQL.

Merci d'avance.

P.S : si j'execute une requete sans erreur j'obtiens bien le bon résultat.
19/04/2006, 13h15
abelman

J'ai trouvé ceci si ça peut t'aider

Citation:

Envoyé par MSDN

New Information - SQL Server 2000 SP3.
Two ODBC function calls can be used to retrieve ODBC messages: SQLGetDiagRec and SQLGetDiagField. To obtain primary ODBC-related information in the SQLState, pfNative, and ErrorMessage diagnostic fields, call SQLGetDiagRec until it returns SQL_NO_DATA. For each diagnostic record, SQLGetDiagField can be called to retrieve individual fields. All driver-specific fields must be retrieved using SQLGetDiagField.
SQLGetDiagRec and SQLGetDiagField are processed by ODBC Driver Manager, not an individual driver. ODBC Driver Manager does not cache driver-specific diagnostic fields until a successful connection has been made. Calling SQLGetDiagField for driver-specific diagnostic fields is not possible before a successful connection. This includes the ODBC connection commands, even if they return SQL_SUCCESS_WITH_INFO. Driver-specific diagnostic fields will not be available until the next ODBC function call.
Examples

The example shows a simple error handler that calls SQLGetDiagRec for the standard ODBC information. It then tests for a valid connection, and if there is, it calls SQLGetDiagField for the Microsoft® SQL Server™ ODBC driver-specific diagnostic fields.
The complete sample code is in this file: ProcessODBCErrors.cpp. You can download an archive containing the sample from the SQL Server Downloads page at this Microsoft Web site.
This sample was developed for ODBC version 3.0 or later. It was developed with Microsoft Visual C++® version 6.0, and may expose properties of the Microsoft Foundation Classes.

[IMG]ms-help://ms.msdnqtr.2003feb.1036/howtosql/Basics/securitynote.gif[/IMG] Security Note When possible, use Windows Authentication. If Windows Authentication is not available, prompt users to enter their credentials at run time. Avoid storing credentials in a file. If you must persist credentials, you should encrypt them with the Win32 cryptoAPI.
19/04/2006, 14h45
tsp

Il semblerait en effet que cela me donne les reponses a mes questions. Cependant, j'ai fait un bout de code avec la fonction SQLGetDiagField, en utilisant tous les DiagIdentifier et je ne retrouve pas les erreurs spécifiques au driver. Je retombe toujours sur mon erreur du gestionnaire de pilote ODBC. Tu as copié ce texte où ? parce que l'exemple m'interresse.
21/04/2006, 09h17
tsp

et hop je remonte mon message pour un second tour au cas où. merci.
21/04/2006, 13h50
abelman

Citation:

Envoyé par tsp

Tu as copié ce texte où ? parce que l'exemple m'interresse.

Sur MSDN de VC6 mais je n'arrive pas à trouver la page équivalente sur la version en ligne.

Sinon le premier paramètre de cette fonction doit être l'une de ces valeur

SQL_HANDLE_ENV
SQL_HANDLE_DBC
SQL_HANDLE_STMT
SQL_HANDLE_DESC

Essaye de passer SQL_HANDLE_STMT pour voir

voici ce que j'avais fait pour tester toutes les valeurs :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
while(SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_MESSAGE_TEXT, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),NULL) != SQL_NO_DATA)
    {   
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_MESSAGE_TEXT, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_CURSOR_ROW_COUNT, (SQLPOINTER)(&iEntier), SQL_IS_SMALLINT,&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_DYNAMIC_FUNCTION, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_DYNAMIC_FUNCTION_CODE, (SQLPOINTER)(&iEntier), SQL_IS_SMALLINT,&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_COLUMN_NUMBER, (SQLPOINTER)(&iEntier), SQL_IS_SMALLINT,&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_NUMBER, (SQLPOINTER)(&iEntier), SQL_IS_SMALLINT,&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_ROW_COUNT, (SQLPOINTER)(&iEntier), SQL_IS_SMALLINT,&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_NATIVE, (SQLPOINTER)(&iEntier), SQL_IS_SMALLINT,&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_ROW_NUMBER, (SQLPOINTER)(&iEntier), SQL_IS_SMALLINT,&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_CLASS_ORIGIN, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_CONNECTION_NAME, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_SERVER_NAME, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_SQLSTATE, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_SUBCLASS_ORIGIN, (SQLPOINTER)(&ErrMsg), sizeof(ErrMsg),&infolen);
SQLGetDiagField(SQL_HANDLE_STMT, *pshHandle, i, SQL_DIAG_RETURNCODE, (SQLPOINTER)(&srRetour), SQL_IS_POINTER,&infolen);
        i += 1;
    EcritFichier(to_string(ErrMsg));
    }

et je ne retrouve rien qui m'aille. Mais je confirme une nouvelle fois que si je fais une erreur dans ma chaine de connexion, c'est bien une erreur retournée par le driver que j'obtiens, sinon c'est le gestionnaire de pilotes ODBC

21/04/2006, 16h13
abelman

Et en essayant avec les trois autres ?
SQL_HANDLE_ENV
SQL_HANDLE_DBC
SQL_HANDLE_DESC

Le problème était le suivant : entre mon SQLExecuteDirect et la recupération de mon erreur, j'executais la fonction SQLRowCount :
Code:

1 2 3 4 5 6 7 8 this->srRetour = SQLExecDirect(this->shStmt,(SQLCHAR*)this->sQuery.c_str(),SQL_NTS); srRowCount = SQLRowCount(this->shStmt, &siRowCount); // s'il y a une erreur lors de l'execution de la requete SQL if(this->srRetour == SQL_ERROR || this->srRetour == SQL_STILL_EXECUTING || this->srRetour == SQL_INVALID_HANDLE|| this->srRetour == SQL_NEED_DATA) { TreatingMessage("Error in Executing SQL",&this->shStmt, SQL_HANDLE_STMT); }
ce qui alterait le statement, ce qui fait que je n'avais pas le bon message d'erreur. J'ai donc deplacé l'execution de la fonction SQLRowCount apres la recuperation du message d'erreur et là j'obtiens le bon.

Conclusion : la gestion du message d'erreur doit immédiatement suivre la fonction qui l'a créé, sans faire appel à une autre fonction odbc entre temps.

25/04/2006, 10h01
abelman

Citation:

Envoyé par tsp

Conclusion : la gestion du message d'erreur doit immédiatement suivre la fonction qui l'a créé, sans faire appel à une autre fonction odbc entre temps.

"Elémentaire mon cher Watson" comme dirais l'autre ;)