Utiliser SQLExec et HExécuteRequête

**WDKyle** · 07/01/2015, 19h33

Bonsoir,

D'après vous, est-il mauvais, déconseillé d'utiliser 2 connexions à une base de données et utiliser dans certains cas SQLExec et dans d'autres HExécuteRequête/HExécuteRequêteSQL ?

J'avais du code qui fonctionnait bien en SQLExec, j'ai dû en passer certains en HExécuteRequête/HExécuteRequêteSQL et je n'arrive pas à tout passer. Je bloque sur la récupération de l'identifiant automatique lors d'une requête INSERT.

Ceci fonctionne parfaitement en SQLExec :

Code :

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

SQLExec("SELECT SCOPE_IDENTITY()", "REQ_IDAuto")

J'ai tenté ceci :

Code :

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

HExécuteRequêteSQL(REQ_ID, MaCNX, hRequêteSansCorrection, "SELECT SCOPE_IDENTITY() AS IDAuto")

J'ai systématiquement 0 en retour d'IDAuto.

Donc si je n'arrive pas à le faire avec HExécuteRequête/HExécuteRequêteSQL, cela ne me dérange pas de mixer les fonctions mais est-ce pas dangereux ?

Merci pour votre aide.

EDIT : Pour info, je suis connecté en OLEDB vers SQLServer.

**OnePoint** · 07/01/2015, 22h54

Bonjour WDKyle,

Je ne crois pas que ce soit possible…

Si tu as 2 connexions, alors je crois bien que tu as 2 sessions.
Et SCOPE_IDENTITY() exécuté dans la session SQLExec ne peut pas voir les id créés dans l'autre session qui correspond à MaCNX du HExécuteRequêteSQL.

Donc, logiquement ça ne peut pas fonctionner.

Mais pour en revenir au code

Code WLangage :

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

HExécuteRequêteSQL(REQ_ID, MaCNX, hRequêteSansCorrection, "SELECT SCOPE_IDENTITY() AS IDAuto")

et à IDAuto toujours à 0, je me demande si c'est vraiment SQL Server qui attribue l'identifiant, et si cet identifiant ne serait pas "forcé" par la couche d'accès aux données d'HyperFile.

D'où la question… comment la ligne dont tu veux récupérer l'identifiant a-t-elle été ajoutée ? Donnes-nous le code, par exemple.

Merci et bon courage.

**WDKyle** · 07/01/2015, 23h18

Bonsoir OnePoint,

Envoyé par OnePoint

Bonjour WDKyle,

Je ne crois pas que ce soit possible…

Si tu as 2 connexions, alors je crois bien que tu as 2 sessions.
Et SCOPE_IDENTITY() exécuté dans la session SQLExec ne peut pas voir les id créés dans l'autre session qui correspond à MaCNX du HExécuteRequêteSQL.

Donc, logiquement ça ne peut pas fonctionner.

Je ne veux pas mixer SQLExec et HExécuteRequêteSQL pour faire des INSERTS. SELECT en HExécuteRequêteSQL et INSERT/UPDATE/DELETE avec SQLExec.

Toujours impossible ?!

Envoyé par OnePoint

Mais pour en revenir au code

Code WLangage :

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

HExécuteRequêteSQL(REQ_ID, MaCNX, hRequêteSansCorrection, "SELECT SCOPE_IDENTITY() AS IDAuto")

et à IDAuto toujours à 0, je me demande si c'est vraiment SQL Server qui attribue l'identifiant, et si cet identifiant ne serait pas "forcé" par la couche d'accès aux données d'HyperFile.

D'où la question… comment la ligne dont tu veux récupérer l'identifiant a-t-elle été ajoutée ? Donnes-nous le code, par exemple.

Merci et bon courage.

Avec un INSERT tout bête... et coté code :

Code :

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

1
2
3
 
HExécuteRequête(REQ_Auditeur_Ajouter, MaCNX, hRequêteSansCorrection)
HExécuteRequêteSQL(REQ_ID, MaCNX, hRequêteSansCorrection, "SELECT SCOPE_IDENTITY() AS IDAuto")

**tbc92** · 08/01/2015, 00h56

Envoyé par OnePoint

Bonjour WDKyle,

Je ne crois pas que ce soit possible…

Si tu as 2 connexions, alors je crois bien que tu as 2 sessions.
Et SCOPE_IDENTITY() exécuté dans la session SQLExec ne peut pas voir les id créés dans l'autre session qui correspond à MaCNX du HExécuteRequêteSQL.

Donc, logiquement ça ne peut pas fonctionner.

Mais pour en revenir au code

Code WLangage :

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

HExécuteRequêteSQL(REQ_ID, MaCNX, hRequêteSansCorrection, "SELECT SCOPE_IDENTITY() AS IDAuto")

et à IDAuto toujours à 0, je me demande si c'est vraiment SQL Server qui attribue l'identifiant, et si cet identifiant ne serait pas "forcé" par la couche d'accès aux données d'HyperFile.

D'où la question… comment la ligne dont tu veux récupérer l'identifiant a-t-elle été ajoutée ? Donnes-nous le code, par exemple.

Merci et bon courage.

Bonsoir,

La première chose à faire, c'est de tester le code retour de HExecuteRequêteSQL(), s'il est à Faux, la fonction HerreurInfo() te donnera des informations.

Mon expérience, c'est Windev avec Oracle, ou Windev avec HyperFile, alors peut-être que je suis à côté de la plaque.
Mais à mon avis, la requête : SELECT SCOPE_IDENTITY() AS IDAuto n'est pas acceptée.
Pour ma part, j'essaierais :

Code SQL :

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

1
2
 
SELECT SCOPE_IDENTITY() AS IDAuto FROM Dual

**WDKyle** · 08/01/2015, 00h58

Envoyé par tbc92

Bonsoir,

La première chose à faire, c'est de tester le code retour de HExecuteRequêteSQL(), s'il est à Faux, la fonction HerreurInfo() te donnera des informations.

Mon expérience, c'est Windev avec Oracle, ou Windev avec HyperFile, alors peut-être que je suis à côté de la plaque.
Mais à mon avis, la requête : SELECT SCOPE_IDENTITY() AS IDAuto n'est pas acceptée.
Pour ma part, j'essaierais :

Code SQL :

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

1
2
 
SELECT SCOPE_IDENTITY() AS IDAuto FROM Dual

Bonsoir tbc92,

La requête passe mais retour 0 en idauto

**hpascal** · 08/01/2015, 15h45

Bonjour

Tu peux mixer les 2 types d'accès sans aucun problème. ça fait juste 2 connexions séparées c'est tout, je fais ça aussi parfois.

Envoyé par Onepoint

je me demande si c'est vraiment SQL Server qui attribue l'identifiant, et si cet identifiant ne serait pas "forcé" par la couche d'accès aux données d'HyperFile

Avec hRequêteSansCorrection Windev envoie le code tel quel et SQL Server renvoie un résultat. La couche d'accès aux données de Windev n'y touche pas (en principe)

Envoyé par tbc92

Mais à mon avis, la requête : SELECT SCOPE_IDENTITY() AS IDAuto n'est pas acceptée.

"SELECT SCOPE_IDENTITY() AS IDAuto" passe très bien. Si c'était incorrect ça bloquerait aussi avec SQLExec

Pour info, je viens de tester à l'instant un INSERT et un SELECT SCOPE_IDENTITY() avec HExecuteRequêteSQL et ça fonctionne très bien

Tu devrais peut être nous montrer ton code

**Nicolas_Jeanneau** · 08/01/2015, 15h46

Bonjour,

je me trompe peut-être mais pour moi, les identifiants automatiques n'ont jamais fonctionné avec SqlServer (accès natif ou pas) ...

bon courage,

Nicolas

**hpascal** · 08/01/2015, 15h49

Envoyé par Nicolas_Jeanneau

Bonjour,

je me trompe peut-être mais pour moi, les identifiants automatiques n'ont jamais fonctionné avec SqlServer (accès natif ou pas) ...

bon courage,

Nicolas

Heureusement que si

EDIT :
Il y plusieurs méthodes avec des différences de portée notamment :

SELECT @@IDENTITY
It returns the last IDENTITY value produced on a connection, regardless of the table that produced the value, and regardless of the scope of the statement that produced the value.
@@IDENTITY will return the last identity value entered into a table in your current session. While @@IDENTITY is limited to the current session, it is not limited to the current scope. If you have a trigger on a table that causes an identity to be created in another table, you will get the identity that was created last, even if it was the trigger that created it.

SELECT SCOPE_IDENTITY()
It returns the last IDENTITY value produced on a connection and by a statement in the same scope, regardless of the table that produced the value.
SCOPE_IDENTITY(), like @@IDENTITY, will return the last identity value created in the current session, but it will also limit it to your current scope as well. In other words, it will return the last identity value that you explicitly created, rather than any identity that was created by a trigger or a user defined function.

SELECT IDENT_CURRENT(‘tablename’)
It returns the last IDENTITY value produced in a table, regardless of the connection that created the value, and regardless of the scope of the statement that produced the value.
IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the identity value generated for a specific table in any session and any scope.

**dsr57** · 08/01/2015, 17h22

Bonjour

et si tu utilises @@identity au lieu de SCOPE_IDENTITY()

Bon dev

**WDKyle** · 08/01/2015, 17h26

Bonjour,

Je vous met du code des que possible sinon @@IDENTITY c'est plutot déconseiller car moins sur de tomber sur le bon idauto.

**Nicolas_Jeanneau** · 08/01/2015, 18h07

Je me suis mal exprimé : pour moi, WinDev ne sait pas gérer les identifiants automatiques de SQLServer ! Mais finalement, je crois me souvenir que c'est uniquement avec la fonction HAjoute ...

**hpascal** · 08/01/2015, 18h35

@Nicolas_Jeanneau : c'est bien ça, il n'y a que par un HAjoute qu'on peut récupérer le dernier id auto (via la rubrique de l'analyse). Avec SQLExec ou HExecuteRequeteSQL il faut le récupérer par du SQL.
Mais j'imagine qu'un HAjoute fait a peu près la même chose en interne, voire un max sur la colonne !

Il faudrait tracer les requêtes et je n'ai pas le Profiler (non livré en version Express)
Si quelqu'un peut tester

**Hemgé** · 08/01/2015, 18h42

Bonsoir,

Je voulais juste rappeler que l'instruction INSERT de PostgreSQL dispose d'une clause RETURNING (propre à PG et donc non standard) qui permet de rapatrier aisément l'identifiant.
Comme je ne connais pas SQLServer, j'ignore s'il dispose d'un équivalent.
Les échanges qui précèdent semblent indiquer que non, mais sait-on jamais ...

Hemgé

**WDKyle** · 08/01/2015, 18h45

Je l'ai le sql server profiler sous sqlserver 2014 express...

Tu est sur quelle version hpascal ?

**hpascal** · 08/01/2015, 18h52

Envoyé par WDKyle

Je l'ai le sql server profiler sous sqlserver 2014 express...

Tu es sur quelle version hpascal ?

2008 R2
Apparemment ce n'était pas fourni avec cette version
Ceci d'après cette page c'est le cas aussi avec la 2014 Express : http://msdn.microsoft.com/en-us/library/cc645993.aspx

Tu peux donc faire un petit test

Tu fais un HAjoute et tu regardes toutes les requêtes générées

**hpascal** · 08/01/2015, 19h00

Envoyé par Hemgé

Je voulais juste rappeler que l'instruction INSERT de PostgreSQL dispose d'une clause RETURNING (propre à PG et donc non standard) qui permet de rapatrier aisément l'identifiant.

Oui j'ai découvert ça il y a peu. C'est vraiment pratique !

**WDKyle** · 08/01/2015, 22h45

Voici par exemple un code qui ne fonctionne pas !

Code :

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
 
// AJOUT DANS LA BASE DE DONNEES
SQLTransaction(sqlDébut, Connexion_SQL_H)
 
SOU_IDAuto est une Source de Données
 
SI HExécuteRequête(REQ_Auditeur_Ajouter) = Vrai ALORS
	SI HExécuteRequêteSQL(SOU_IDAuto, Connexion_SQL_H, hRequêteSansCorrection, "SELECT SCOPE_IDENTITY() AS IDAuto") = Vrai ALORS
		SI HLitPremier(SOU_IDAuto, "", hSansRafraîchir) = Vrai ALORS
			Info(SOU_IDAuto.IDAuto)
		SINON
			SQLTransaction(sqlAnnule, Connexion_SQL_H)
			Erreur("Erreur : " + HErreurInfo(hErrComplet))
		FIN
	SINON
		SQLTransaction(sqlAnnule, Connexion_SQL_H)
		Erreur("Erreur : " + HErreurInfo(hErrComplet))
	FIN
	HLibèreRequête(SOU_IDAuto)
SINON
	SQLTransaction(sqlAnnule, Connexion_SQL_H)
	Erreur("Erreur : " + HErreurInfo(hErrComplet))
FIN
HLibèreRequête(REQ_Auditeur_Ajouter)
 
SQLTransaction(sqlFin, Connexion_SQL_H)

Résultat du Info(SOU_IDAuto.IDAuto) > 0

**hpascal** · 09/01/2015, 09h55

Je pense que le problème vient du mix de HExécuteRequête et HExécuteRequêteSQL
HExécuteRequêteSQL utilise la connexion Connexion_SQL_H, HExécuteRequête utilise la connexion courante

Et même si c'est la même connexion il y a peut être des contextes différents

Je suis sur que ça va fonctionner si tu fais ton INSERT avec HExécuteRequêteSQL

**dsr57** · 09/01/2015, 15h50

Bonjour à tous

Je viens de faire des tests en WD19

Avec les fonctions SQLxxx :

Code :

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
SI PAS SQLConnecte("MonServeur","sa","MDP","MaBase","SQL SERVER",hOledbSQLServer) ALORS
	SQLInfoGene()
	Erreur(SQL.Erreur)
SINON 
	SI PAS SQLExec("INSERT  into test (testValeur) VALUES ('') " ,"reqTest") ALORS
		SQLInfoGene("reqTest")
		Erreur(SQL.Erreur+RC+SQL.MesErreur)
	SINON
		SQLInfoGene("reqTest")
		SI PAS SQLExec("SELECT SCOPE_IDENTITY() as ID","reqTest") ALORS
			SQLInfoGene("reqTest")
			Erreur(SQL.Erreur+RC+SQL.MesErreur)
		SINON
			SQLPremier("reqTest")
			Info(SQLCol("reqTest",1))
		FIN
	FIN
FIN

Avec les fonctions Hxxx :

Code :

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
 
MaConnexion est une Connexion 
// Description de la connexion 
MaConnexion..Utilisateur = "sa" 
MaConnexion..MotDePasse = "pwd" 
MaConnexion..Serveur = "MonServeur" 
MaConnexion..BaseDeDonnées = "MaBase" 
MaConnexion..Provider = hOledbSQLServer
MaConnexion..Accès = hOLectureEcriture 
 
SI PAS HOuvreConnexion(MaConnexion) ALORS
	Erreur(HErreurInfo(hErrComplet))
SINON
	SI PAS HExécuteRequêteSQL("reqTest",MaConnexion,hRequêteSansCorrection,"INSERT  into test (testValeur) VALUES ('') ") ALORS
 
	SINON
		//info(sql.IdAuto)
		SI PAS HExécuteRequêteSQL("reqTest",MaConnexion,hRequêteSansCorrection,"SELECT SCOPE_IDENTITY() as ID") ALORS
			Erreur(HErreurInfo(hErrComplet))
		SINON
			HLitPremier("reqTest")
			Info(HRécupèreRubrique("reqTest",1))
		FIN
	FIN
FIN

cela fonctionne de mon coté, j'ai même mis un point d'arrêt après la requête de type INSERT, lancer manuellement dans le manager des requête requêtes de type INSERT ; le programme me retourne le bon ID

Bon dev

**WDKyle** · 09/01/2015, 19h25

Envoyé par hpascal

Je pense que le problème vient du mix de HExécuteRequête et HExécuteRequêteSQL
HExécuteRequêteSQL utilise la connexion Connexion_SQL_H, HExécuteRequête utilise la connexion courante

Et même si c'est la même connexion il y a peut être des contextes différents

Je suis sur que ça va fonctionner si tu fais ton INSERT avec HExécuteRequêteSQL

Je viens de tester avec le nom de connexion, même résultat > 0.

Code :

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
 
// AJOUT DANS LA BASE DE DONNEES
SQLTransaction(sqlDébut, Connexion_SQL_H)
 
SOU_IDAuto est une Source de Données
 
SI HExécuteRequête(REQ_Auditeur_Ajouter, Connexion_SQL_H) = Vrai ALORS
	SI HExécuteRequêteSQL(SOU_IDAuto, Connexion_SQL_H, hRequêteSansCorrection, "SELECT SCOPE_IDENTITY() AS IDAuto") = Vrai ALORS
		SI HLitPremier(SOU_IDAuto, "", hSansRafraîchir) = Vrai ALORS
			Info(SOU_IDAuto.IDAuto)
		SINON
			Erreur("Erreur : " + HErreurInfo(hErrComplet))
		FIN
	SINON
		Erreur("Erreur : " + HErreurInfo(hErrComplet))
	FIN
	HLibèreRequête(SOU_IDAuto)
SINON
	Erreur("Erreur : " + HErreurInfo(hErrComplet))
FIN
HLibèreRequête(REQ_Auditeur_Ajouter)
 
SQLTransaction(sqlAnnule, Connexion_SQL_H)

Idem avec les 2 requêtes faites depuis l'éditeur de requête :

Code :

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
 
SI HExécuteRequête(REQ_Auditeur_Ajouter, Connexion_SQL_H) = Vrai ALORS
	SI HExécuteRequête(REQ_IDAuto, Connexion_SQL_H, hRequêteSansCorrection) = Vrai ALORS
		SI HLitPremier(REQ_IDAuto, "", hSansRafraîchir) = Vrai ALORS
			Info(REQ_IDAuto.IDAuto)
		SINON
			Erreur("Erreur : " + HErreurInfo(hErrComplet))
		FIN
	SINON
		Erreur("Erreur : " + HErreurInfo(hErrComplet))
	FIN
	HLibèreRequête(REQ_IDAuto)
SINON
	Erreur("Erreur : " + HErreurInfo(hErrComplet))
FIN
HLibèreRequête(REQ_Auditeur_Ajouter)

ça ne me dérange pas d'avoir 2 connexions... Car là, je ne vois pas le soucis.

Utiliser SQLExec et HExécuteRequête [WD16]

WinDev

Discussions similaires

Partager

Partager