Bonjour,
Dans ce message je veux partager avec vous des précisions sur l'utilisation d'une variable source de données, en particulier en ce qui concerne la "portée" et le nom logique pour une source de données.
Dans deux messages, vmolines présente un problème important sur les Sources de données:
http://www.developpez.net/forums/d82...n/#post4905408
http://www.developpez.net/forums/d82...n/#post4905850
Dans l'aide en ligne de mon WD12 il est dit:
Dans l'aide en ligne sur le web il est dit:Une source de données est globale à tous les traitements du projet.
De par mon expérience je crois qu'il faut distinguer:Une source de données déclarée en globale est globale à tous les traitements du projet qui utilisent le contexte HyperFileSQL correspondant à celui où la source de données a été déclarée.
_ • d'une part, la variable de type source de données,
_ • d'autre part, le jeu de données correspondant à cette variable dans le contexte HyperFile.
Un jeu de données est global à tous les traitements qui utilisent le contexte HyperFileSQL correspondant à celui où la source de données a été déclarée.
Mais la "durée de vie" du jeu de données est directement liée à la portée dans laquelle la variable de type source de données est déclarée.
En fait, le contexte HyperFile est nécessairement global. Sitôt qu'on déclare une source de données, elle devient disponible et visible dans le contexte HyperFile, donc globalement.
En dehors de la portée où la variable source de données est déclarée, l'accès à cette source de données se fait seulement au moyen d'un nom logique (une chaîne de caractères).
Le problème relaté par vmolines est que le nom logique attribué à la source de données est identique au nom de la variable de type source de données.
Mais, ce qui n'est pas dit dans l'aide en ligne, c'est qu'il est possible de spécifier le nom logique. Ainsi, en spécifiant le nom logique de la source de données, on peut espérer éviter des "collisions" entre des sources de données qu'on aurait voulu limiter à une portée locale.
Dans l'exemple didactique ci-dessous, je "génère" un nom logique unique en concaténant une chaîne d'horodatage obtenue par la fonction HeureSys().
Code Wlangage : 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 src est une Source de Données sNomUnique est une chaîne SQL est une chaîne = "SELECT * FROM CLIENT" // générer un "nom logique" unique pour la source de données sNomUnique = src + HeureSys() // spécifier le "nom logique" de la source de données src = sNomUnique SI HExécuteRequêteSQL(src, hRequêteDéfaut, SQL) ALORS // on peut accéder à la source de donnée via la variable Info("Source -> Nb enr. = " + HNbEnr(src)) // on peut accéder à la source de donnée via le nom logique Info("Nom unique -> Nb enr. = " + HNbEnr(sNomUnique)) SINON Erreur() FIN
Et voici comment, en pratique, je l'utilise de façon abrégée dans mes procédures.
Code Wlangage : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 src est une Source de Données SQL est une chaîne = "SELECT * FROM CLIENT" // spécifier un "nom logique" unique pour la source de données src += HeureSys() SI HExécuteRequêteSQL(src, hRequêteDéfaut, SQL) ALORS ... SINON ... FIN
Remarque:
A la place de HeureSys(), il est sans doute préférable d'utiliser la fonction DonneIdentifiant() qui retourne un nombre entier différent à chaque appel, de façon à pouvoir générer une identifiant unique.
Pour les plus gourmands (les veinards qui ont WD15 ), il y a aussi la possibilité d'utiliser comme identifiant unique un GUID brut calculé par DonneGUID(guidBrut).
P.S. Merci à une personne de PC Soft qui m'a informé de la possibilité de nommer une variable source de données.
_
Partager