Discussion :

[progxch]

Bonjour,

je souhaite récupérer l'id auto incrémenté d'une base SQL server depuis Windev (en OLEDB, sans accès natif) et malheureusement cela ne fonctionne pas dans toutes les situations.

J'ai fait un projet test qui montre le problème, notamment lorsque l'on a plusieurs requêtes (avec des noms différents) sur la même base. Il est disponible ici : test_SQL et en pièce jointe de ce message.

Avec la syntaxe SQLConnecte c'est dans toutes les situations qu'il est impossible de récupérer l'ID auto généré.

Ma question: comment récupérer cet ID auto dans toutes les situations sans accès natif ?

Voici pour ceux qui n'ont pas un environnement Windev à disposition un des codes qui ne fonctionne pas (avec HouvreConnexion) :

Code windev :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
SI PAS BDD_connecte(SAI_Serveur,SAI_Utilisateur,SAI_Mot_de_passe,SAI_Nom_BD) ALORS
	ToastAffiche("Problème pour se connecter à la base SQL server")
SINON
	sReq3 est une chaîne = [
		INSERT INTO test1 (col_test, col_desc, col_date) VALUES (%1, %2, %3)
	]
 
	sNomReq3 est une chaîne = "REQ_"+DonneGUID(guidBrut)
	sNomReq2 est une chaîne = "REQ_"+DonneGUID(guidBrut)
	sNomReq1 est une chaîne = "REQ_"+DonneGUID(guidBrut)
 
	sReq1 est une chaîne = [
		SELECT * FROM test1
	]
	SI PAS HExécuteRequêteSQL(sNomReq1,COL_ProcéduresGlobales_HOuvreConnexion.gcnxBDDSQLServer, hRequêteSansCorrection,sReq1) ALORS
		Erreur(HErreurInfo(hErrMessage))
		RENVOYER Faux
	FIN
	nCompteur est un entier = Hasard(1,9999)
	sReq3 = ChaîneConstruit(sReq3,nCompteur,"'description "+Hasard(1,99999)+"'","{d'"+DateVersChaîne(EntierVersDate(Hasard(DateVersEntier("20140101"),DateVersEntier(DateSys()))),"AAAA-MM-JJ")+"'}")
	SI PAS HExécuteRequêteSQL(sNomReq3,COL_ProcéduresGlobales_HOuvreConnexion.gcnxBDDSQLServer, hRequêteSansCorrection,sReq3) ALORS
		Erreur(HErreurInfo(hErrMessage))
		RENVOYER Faux
	FIN
	sReq2 est une chaîne = [
		SELECT SCOPE_IDENTITY() AS col_ID FROM test1
	]
	SI PAS HExécuteRequêteSQL(sNomReq2,COL_ProcéduresGlobales_HOuvreConnexion.gcnxBDDSQLServer, hRequêteSansCorrection,sReq2) ALORS
		Erreur(HErreurInfo(hErrMessage))
		RENVOYER Faux
	FIN
	HLitPremier(sNomReq2)
	Info({sNomReq2+".col_ID"})
 
FIN

Le code de la procédure BDD_connecte :

Code windev :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
PROCEDURE BDD_connecte(LOCAL sServeur est une chaîne, LOCAL sUser est une chaîne, LOCAL sMDP est une chaîne, LOCAL sNomBD est une chaîne)
sMess est une chaîne = ""
 
HFermeConnexion(gcnxBDDSQLServer)
 
H.ModeSQLServer = 3
HDécritConnexion(gcnxBDDSQLServer,sUser,sMDP,sServeur,sNomBD,hOledbSQLServer,hOLectureEcriture)
H.ModeSQLServer = 3
SI PAS HOuvreConnexion(gcnxBDDSQLServer) ALORS
	sMess = "Problème de connexion à la base de données SQL Server"+HErreurInfo(hErrMessage)
	SI PAS EnModeWebservice() ET PAS EnModeService() ALORS
		ToastAffiche(sMess)
	FIN
	RENVOYER Faux
SINON
	RENVOYER Vrai
FIN

Merci pour vos idées et/ou suggestions!

[hpascal]

Bonjour

J'utilisais SCOPE_IDENTITY en OLEDB sans problème il me semble.
Là je n'ai pas de SQL Server sous la main pour tester

Tu as testé d'autres méthodes que SCOPE_IDENTITY ?

Un post qui en parle : http://www.developpez.net/forums/d14...e/#post8089840

[progxch]

Bonjour hpascal,

merci pour ta réponse.

J'ai testé SELECT @@IDENTITY mais malheureusement même souci.

Le SELECT IDENT_CURRENT(‘tablename’) n'est pas une bonne solution car il revient à lire la dernière (plus haute) valeur et ça ne résoud pas les insertions très rapprochée de différentes sources. C'est donc une fausse bonne idée (dans mon cas).

Le plus étrange est le comportement "non-cloisonné" entre deux requêtes qui ont un nom différent.

Si on fait l'INSERT puis le SELECT SCOPE_IDENTITY() ça fonctionne.
Si on fait l'INSERT puis une autre requête (un SELECT) et que l'on fait un HAnnuleDéclaration sur le SELECT => ça fonctionne
Si on fait l'INSERT puis une autre requête (un SELECT) => ça ne fonctionne plus!

Entre-temps j'ai aussi soumis le problème au ST et voici leur réponse :

**********
J'ai lu votre description avec attention et je vous remercie pour sa précision et la qualité des éléments fournis. J'ai reproduis le comportement décrit et j'ai transmis vos éléments à notre équipe de développement pour qu'une étude soit réalisée.

Si il devait y avoir une correction alors elle sera réalisée par notre équipe de développement dans la version en cours de commercialisation. Une fois ce correctif disponible, une nouvelle phase de test du module sera effectuée par notre équipe qualité. Ensuite il vous sera transmis par le Support Technique Gratuit.

Je suis sincèrement désolé de la gêne occasionnée par cet incident et je vous remercie de votre patience.

Note : L'incident a été enregistré avec la référence 92 686. Merci d'utiliser cette référence si vous contactez le Support Technique Gratuit sur le même sujet.
**********

Il y a donc bel et bien malheureusement un soucis au niveau Windev.

[hpascal]

Ok
Tiens nous au courant si tu as un retour

[dsr57]

Bonjour

Si tu utilises les fonctions :

• SqlConnecte pour la connection
• SqlExec pour exécuter ta requête de type Insert
• SqlInfoGene pour initialiser les variables SQL
• tu as la variables Sql.idAuto qui devrait (l'utilisation du conditionnel est volontaire ) te donner l'id auto généré

Bon dev

[hpascal]

Bonne idée mais sql.idauto fonctionne avec les bases HF seulement

On en parle dans cette page : http://doc.pcsoft.fr/fr-FR/?2034001&...ions-sql#NOTE3

et là : http://doc.pcsoft.fr/fr-FR/?3072007&...RAGRAPHE000247

[themayu]

Bonjour,

Vous pouvez contourner le problème en utilisant la clause OUTPUT dans vôtre requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
sReq3 est une chaîne = [
		INSERT INTO test1 (col_test, col_desc, col_date) OUTPUT INSERTED.id VALUES (%1, %2, %3)
	]

Ceci en admettant que "id" soit le nom de votre clé primaire.

C'est le seul moyen que j'ai réussi à faire fonctionner après plusieurs heures de recherche, testé pour l'instant avec SQL Server 2008 et une connexion ODBC par contre, pas OLEDB.

Note :
Sur une base PostGre en ODBC, on peut arriver au même résultat en collant "RETURNING id" à la fin de la requête ..

[progxch]

Merci pour vos interventions et conseils!

@dsr57
Comme l'a mentionné hpascal ce n'est malheureusement pas possible dans ce cas, j'ai fait un test et ça renvoie toujours 0.

@themayu
J'ai testé votre solution et chez moi ça fonctionne partiellement. Je m'explique, j'arrive à récupérer l'ID inséré MAIS mon INSERT me provoque une insertion de 10 lignes (parfois plus) dans la base SQL Server de manière aléatoire! Tout en restant en OleDB!

Si je prends la requête générée et que je la "passe" avec HeidiSQL ou SQL Management => qu'un seul enregistrement est crée (comme on peut s'y attendre).

Voici mon code complet :

Code Windev :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
SI PAS BDD_connecte(SAI_Serveur,SAI_Utilisateur,SAI_Mot_de_passe,SAI_Nom_BD) ALORS
	ToastAffiche("Problème pour se connecter à la base SQL server")
SINON
	sReq3 est une chaîne = [
		INSERT INTO test1 (col_test, col_desc, col_date) OUTPUT INSERTED.col_ID VALUES (%1, %2, %3) 
	]
 
	sNomReq3 est une chaîne = "REQ_3"
	sNomReq2 est une chaîne = "REQ_2"
	sNomReq1 est une chaîne = "REQ_1"
	sReq1 est une chaîne = [
		SELECT * FROM test1
	]
	SI PAS HExécuteRequêteSQL(sNomReq1,COL_ProcéduresGlobales_HOuvreConnexion.gcnxBDDSQLServer, hRequêteSansCorrection,sReq1) ALORS
		Erreur(HErreurInfo(hErrMessage))
		RENVOYER Faux
	FIN
	nCompteur est un entier = Hasard(1,9999)
	sReq3 = ChaîneConstruit(sReq3,nCompteur,"'description "+Hasard(1,99999)+"'","{d'"+DateVersChaîne(EntierVersDate(Hasard(DateVersEntier("20140101"),DateVersEntier(DateSys()))),"AAAA-MM-JJ")+"'}")
	SI PAS HExécuteRequêteSQL(sNomReq3,COL_ProcéduresGlobales_HOuvreConnexion.gcnxBDDSQLServer, hRequêteSansCorrection,sReq3) ALORS
		Erreur(HErreurInfo(hErrMessage))
		RENVOYER Faux
	FIN
 
	HLitPremier({sNomReq3})
	Info({sNomReq3+".col_ID"})
 
FIN

C'est vraiment un problème à ne plus rien y comprendre!

Je suis sous Windows 8.1, ma base de données est sous une machine virtuelle Windows server 2012 avec un SQL Server 2012.

[themayu]

Point que j'ai oublié de préciser, je n'utilises pas les ordres H..... mais les ordres SQL....
Pour mes inserts, la procédure ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
SI SQLExec(Req,REQUID) ALORS
  SQLPremier(REQUID)
  SI SQL.NbLig  > 0 ALORS
    maclé = SQLCol(REQUID,0)
  FIN
FIN

Avec Windows 7 et Windev 19

[hpascal]

Je viens d'essayer la syntaxe proposée par @themayu

Ma config : VM avec SQL Server 2008 R2
Mon poste en Windows 8.1
Accès par OLEDB (SQLNCLI10 puis SQLNCLI11)

Pour un insert fait, voilà le nombre de lignes ajoutées selon la fonction utilisée et le provider :


HExecuteRequeteSQL avec SQLNCLI10 : 16
HExecuteRequeteSQL avec SQLNCLI11 : 9
SQLExec avec SQLNCLI10 : 4
SQLExec avec SQLNCLI11 : 2

Chez moi ce n'est pas aléatoire, c'est toujours le même nombre de lignes

La même requête exécutée sous SQL Management n'ajoute qu'un seul enregistrement

Etrange comme fonctionnement non ?
En gros il n'y a que sous Windev que c'est inutilisable

@themayu :
Sous PG "RETURNING id" fonctionne aussi sans problème avec l'accès natif

[themayu]

Intriguant tout ça, j'espère que je n'aurais ce problème aléatoire dans le futur, faut que je fasse des essais sur d'autre configuration !

Pour la connexion j'utilise "ODBC Driver 11 for SQL Server", "MSODBCSQL11"

[themayu]

@hpascal

En utilisant ton logiciel du site de dépôt de PCSoft, et la connexion ODBC, les enregistrement sont bien ajoutés 1 à 1 ...
Toujours avec ton logiciel, mais une connexion OLEDB, les enregistrements sont enregistrés par 4 également !

Si quelqu'un peut confirmer ce résultat avec les drivers indiqués dans mon post précédent

[hpascal]

Outils_SQL utilise SQLExec, c'est là que j'ai fait mes tests d'ailleurs
Je vais tester en ODBC et je te tiens au courant

[hpascal]

Test effectué sur Outils_SQL en ODBC

J'ai essayé les versions 10 et 11 du driver

Là j'ai bien une seule ligne ajoutée. Fonctionnement normal donc

J'aimerais bien comprendre pourquoi on a ce comportement en OLEDB ...

[themayu]

Étrange en effet ....... merci pour le retour en tout cas, cette solution semble fonctionner dans différentes conditions donc, c'est rassurant !!

Pour ce qui est de l'utilisation d'OLEDB, pour du SQL Server ce n'est plus recommandé depuis un moment maintenant, mais c'est un autre débat

[Hibernatus34]

Bonjour,

Le bug que vous avez avec un batch SQL est "normal". Il n'est pas permis d'exécuter un batch renvoyant plusieurs résultats en curseur serveur. (source : Using ODBC with Microsoft SQL Server)
Essayez de passer votre connexion en curseur client, ou d'exécuter "SET NOCOUNT ON" avant l'insertion.

Mais je ne comprends pas pourquoi vous n'utilisez pas simplement HAjoute.

PS. La seule "bonne" manière de récupérer l'ID auto est SELECT SCOPE_IDENTITY(). Les autres méthodes ne sont pas fiables en accès concurrents. (et la clause OUTPUT ne fonctionnera probablement pas s'il y a un trigger)

[Narwe]

Voici mon code complet :

Code Windev :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
[...]
	HLitPremier({sNomReq3})

Ne faut-il pas rajouter le paramètre HSansRafraichir ?
J'avais ce problème sur une connexion MySQL en accès Natif (je sais, ça n'a donc rien à voir) sur un appel d'un procédure stockée qui faisait une incrémentation d'un compteur et qui me renvoyait la valeur. Le compteur s'incrémenté 2 à 2.
Le problème était que le HLitPremier ré-exécute la requête sans ce paramètre.

[hpascal]

Salut @Hibernatus34

Bien vu, je pensais que le mode était en curseur client par défaut
Je viens de chercher dans l'aide, c'est hCurseurServeur + hCurseurOpenKeySet + hCurseurOptimiste

[progxch]

Merci à tous pour vos interventions!

La solution d'Hibernatus34 est correcte, avec un curseur client (ajout de la constante hCurseurClient) cela fonctionne maintenant comme escompté. Merci beaucoup!

Voici le changement à faire dans la déclaration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

HDécritConnexion(gcnxBDDSQLServer,sUser,sMDP,sServeur,sNomBD,hOledbSQLServer,hOLectureEcriture,"WD CLIENT VERSION=2012",hCurseurClient)

Pour répondre également à la question du pourquoi ne pas faire un hAjoute c'est simplement car nous développons une classe qui sera réutilisée dans beaucoup de projets. Du coup, dans certains cas aucun problème pour faire un hAjoute, dans d'autre ça pourrait être plus complexe (ajout sur plusieurs tables par exemple).

Je préfère prendre un peu plus de temps pour développer une classe qui sera plus robuste dans des situations différentes que de faire une solution "à la vas-vite" qui me posera problème plus tard.