Windev 11, ID automatiques sous Oracle, séquences et trigger
18 réponses
Loko
Bonjour
J'utilise Windev 11 avec Oracle 10g.
J'ai une table avec un champ clef primaire de type compteur, j'ai donc
cr=E9=E9 une s=E9quence sp=E9ciale ce champ dans Oracle, ainsi qu'un trigger=
Before Insert qui remplit automatiquement le champ concern=E9 avec le
nextval de ma s=E9quence.
Un test d'insert directement sous Oracle confirme le bon
fonctionnement de l'ensemble.
Ensuite sous Windev, ca marche moyennement :
- en acc=E8s OLE DB le nouvel enregistrement est bien cr=E9=E9 par un
HAjoute et si je trace juste apres la valeur du champ concern=E9 Windev
retrouve bien la nextval cr=E9=E9 par la base Oracle.
- par contre en acc=E8s natif cela ne fonctionne pas : le nouvel
enregistrement est cr=E9=E9 mais la valeur du champ reste =E0 z=E9ro.
- J'ai essay=E9 en d=E9clarant le champ en ID automatique dans l'analyse
et j'ai =E9galement essay=E9 en le d=E9clarant comme un num=E9rique standard=
(en clef unique, evidemment), dans les 2 cas ca fonctionne en OLE DB
mais pas en acc=E8s natif.
Je voudrais donc savoir comment retrouver le num=E9ro g=E9n=E9r=E9 par Oracl=
e
dans Windev. Je ne peux pas relire la base et recuperer la valeur
maximale, ce n'est pas fiable, si plusieurs utilisateurs font des
ajouts en meme temps.
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il faut utiliser un select maseq.currval pour connaitre le dernier numéro généré par la séquence (dans la même transaction)
"Emmanuel LECOESTER" a écrit dans le message de news:47e351ac$0$887$
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un papier et je te promets la reconnaissance d'un grand monde.
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère toujours cet id fonctionnel dans la même transaction car ton argument recevable au demeurant de perte d'id est identique ici : tu casses ta transaction ben tu perds ton id de sequence et tu ne le retrouveras
jamais.
"Loko" a écrit dans le message de news:
On 20 mar, 19:53, "Emmanuel LECOESTER" wrote:
Concernant les auto_id sous Oracle la technique du trigger est interessante mais pour retrouver le masequence.currentval ben tu ne sais pas...
D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un
coup
dans la sequence et tu gères ton insert toi même avec ton id (deux variable : id_courant, id_max, si id_courant = id_max alors reprendre les 100 sequences suivantes).
Evite le select max(id) a partir de 1millions d'enreg un insert rame ;-)
Je rejoins l'intervention de patrice pour affecter l'id que si il est
vide
:)
De plus cette technique laisse des "trous" dans les numéros si l'utilisateur réserve 100id mais ne les utilise pas tous, ferme son logiciel Windev puis le relance. Or au niveau législatif je n'ai pas le droit d'avoir des trous dans mes numéros ...
Si le résultat en OLEDB est différent de celui de l'accès natif, c'est que le Hajoute ne fait pas la même chose.
Le plus simple est de faire du SQL, de gérer les transactions, comme cela on n'a pas de mauvaise surprise.
Lire également un manuel sur la base qu'on utilise est de bonne augure (ou au moins avoir un manuel à portée de main).
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
patrice a écrit :
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il faut
utiliser un select maseq.currval pour connaitre le dernier numéro généré par
la séquence (dans la même transaction)
"Emmanuel LECOESTER" <elecoest@netcourrier.com> a écrit dans le message de
news:47e351ac$0$887$ba4acef3@news.orange.fr...
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un
papier et je te promets la reconnaissance d'un grand monde.
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère
toujours cet id fonctionnel dans la même transaction car ton argument
recevable au demeurant de perte d'id est identique ici : tu casses ta
transaction ben tu perds ton id de sequence et tu ne le retrouveras
jamais.
"Loko" <arnaudgeslin@gmail.com> a écrit dans le message de news:
e7ab3e3d-38b3-439e-b86b-22514318048f@a70g2000hsh.googlegroups.com...
On 20 mar, 19:53, "Emmanuel LECOESTER" <eleco...@netcourrier.com>
wrote:
Concernant les auto_id sous Oracle la technique du trigger est
interessante
mais pour retrouver le masequence.currentval ben tu ne sais pas...
D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un
coup
dans la sequence et tu gères ton insert toi même avec ton id (deux
variable
: id_courant, id_max, si id_courant = id_max alors reprendre les 100
sequences suivantes).
Evite le select max(id) a partir de 1millions d'enreg un insert rame ;-)
Je rejoins l'intervention de patrice pour affecter l'id que si il est
vide
:)
De plus cette technique laisse des "trous" dans les numéros si
l'utilisateur réserve 100id mais ne les utilise pas tous, ferme son
logiciel Windev puis le relance. Or au niveau législatif je n'ai pas
le droit d'avoir des trous dans mes numéros ...
Si le résultat en OLEDB est différent de celui de l'accès natif, c'est
que le Hajoute ne fait pas la même chose.
Le plus simple est de faire du SQL, de gérer les transactions, comme
cela on n'a pas de mauvaise surprise.
Lire également un manuel sur la base qu'on utilise est de bonne augure
(ou au moins avoir un manuel à portée de main).
--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il faut utiliser un select maseq.currval pour connaitre le dernier numéro généré par la séquence (dans la même transaction)
"Emmanuel LECOESTER" a écrit dans le message de news:47e351ac$0$887$
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un papier et je te promets la reconnaissance d'un grand monde.
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère toujours cet id fonctionnel dans la même transaction car ton argument recevable au demeurant de perte d'id est identique ici : tu casses ta transaction ben tu perds ton id de sequence et tu ne le retrouveras
jamais.
"Loko" a écrit dans le message de news:
On 20 mar, 19:53, "Emmanuel LECOESTER" wrote:
Concernant les auto_id sous Oracle la technique du trigger est interessante mais pour retrouver le masequence.currentval ben tu ne sais pas...
D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un
coup
dans la sequence et tu gères ton insert toi même avec ton id (deux variable : id_courant, id_max, si id_courant = id_max alors reprendre les 100 sequences suivantes).
Evite le select max(id) a partir de 1millions d'enreg un insert rame ;-)
Je rejoins l'intervention de patrice pour affecter l'id que si il est
vide
:)
De plus cette technique laisse des "trous" dans les numéros si l'utilisateur réserve 100id mais ne les utilise pas tous, ferme son logiciel Windev puis le relance. Or au niveau législatif je n'ai pas le droit d'avoir des trous dans mes numéros ...
Si le résultat en OLEDB est différent de celui de l'accès natif, c'est que le Hajoute ne fait pas la même chose.
Le plus simple est de faire du SQL, de gérer les transactions, comme cela on n'a pas de mauvaise surprise.
Lire également un manuel sur la base qu'on utilise est de bonne augure (ou au moins avoir un manuel à portée de main).
-- suivre ce lien pour répondre: http://cerbermail.com/?2KrV3YZXnn Daniel ;-)
Emmanuel LECOESTER
"patrice" a écrit dans le message de news: 47e3754c$0$15874$
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il faut utiliser un select maseq.currval pour connaitre le dernier numéro généré par la séquence (dans la même transaction)
Pour moi non... le currentval c'est la derniere valeur de sequence donc tous users confondus.
"Emmanuel LECOESTER" a écrit dans le message de news:47e351ac$0$887$
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un papier et je te promets la reconnaissance d'un grand monde.
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère toujours cet id fonctionnel dans la même transaction car ton argument recevable au demeurant de perte d'id est identique ici : tu casses ta transaction ben tu perds ton id de sequence et tu ne le retrouveras
jamais.
"Loko" a écrit dans le message de news:
On 20 mar, 19:53, "Emmanuel LECOESTER" wrote: > Concernant les auto_id sous Oracle la technique du trigger est > interessante > mais pour retrouver le masequence.currentval ben tu ne sais pas... > > D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un
coup
> dans la sequence et tu gères ton insert toi même avec ton id (deux > variable > : id_courant, id_max, si id_courant = id_max alors reprendre les 100 > sequences suivantes). > > Evite le select max(id) a partir de 1millions d'enreg un insert rame > ;-) > > Je rejoins l'intervention de patrice pour affecter l'id que si il est
vide
> :)
De plus cette technique laisse des "trous" dans les numéros si l'utilisateur réserve 100id mais ne les utilise pas tous, ferme son logiciel Windev puis le relance. Or au niveau législatif je n'ai pas le droit d'avoir des trous dans mes numéros ...
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 47e3754c$0$15874$426a74cc@news.free.fr...
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il
faut
utiliser un select maseq.currval pour connaitre le dernier numéro généré
par
la séquence (dans la même transaction)
Pour moi non... le currentval c'est la derniere valeur de sequence donc tous
users confondus.
"Emmanuel LECOESTER" <elecoest@netcourrier.com> a écrit dans le message de
news:47e351ac$0$887$ba4acef3@news.orange.fr...
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un
papier et je te promets la reconnaissance d'un grand monde.
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère
toujours cet id fonctionnel dans la même transaction car ton argument
recevable au demeurant de perte d'id est identique ici : tu casses ta
transaction ben tu perds ton id de sequence et tu ne le retrouveras
jamais.
"Loko" <arnaudgeslin@gmail.com> a écrit dans le message de news:
e7ab3e3d-38b3-439e-b86b-22514318048f@a70g2000hsh.googlegroups.com...
On 20 mar, 19:53, "Emmanuel LECOESTER" <eleco...@netcourrier.com>
wrote:
> Concernant les auto_id sous Oracle la technique du trigger est
> interessante
> mais pour retrouver le masequence.currentval ben tu ne sais pas...
>
> D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un
coup
> dans la sequence et tu gères ton insert toi même avec ton id (deux
> variable
> : id_courant, id_max, si id_courant = id_max alors reprendre les 100
> sequences suivantes).
>
> Evite le select max(id) a partir de 1millions d'enreg un insert rame
> ;-)
>
> Je rejoins l'intervention de patrice pour affecter l'id que si il est
vide
> :)
De plus cette technique laisse des "trous" dans les numéros si
l'utilisateur réserve 100id mais ne les utilise pas tous, ferme son
logiciel Windev puis le relance. Or au niveau législatif je n'ai pas
le droit d'avoir des trous dans mes numéros ...
"patrice" a écrit dans le message de news: 47e3754c$0$15874$
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il faut utiliser un select maseq.currval pour connaitre le dernier numéro généré par la séquence (dans la même transaction)
Pour moi non... le currentval c'est la derniere valeur de sequence donc tous users confondus.
"Emmanuel LECOESTER" a écrit dans le message de news:47e351ac$0$887$
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un papier et je te promets la reconnaissance d'un grand monde.
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère toujours cet id fonctionnel dans la même transaction car ton argument recevable au demeurant de perte d'id est identique ici : tu casses ta transaction ben tu perds ton id de sequence et tu ne le retrouveras
jamais.
"Loko" a écrit dans le message de news:
On 20 mar, 19:53, "Emmanuel LECOESTER" wrote: > Concernant les auto_id sous Oracle la technique du trigger est > interessante > mais pour retrouver le masequence.currentval ben tu ne sais pas... > > D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un
coup
> dans la sequence et tu gères ton insert toi même avec ton id (deux > variable > : id_courant, id_max, si id_courant = id_max alors reprendre les 100 > sequences suivantes). > > Evite le select max(id) a partir de 1millions d'enreg un insert rame > ;-) > > Je rejoins l'intervention de patrice pour affecter l'id que si il est
vide
> :)
De plus cette technique laisse des "trous" dans les numéros si l'utilisateur réserve 100id mais ne les utilise pas tous, ferme son logiciel Windev puis le relance. Or au niveau législatif je n'ai pas le droit d'avoir des trous dans mes numéros ...
Emmanuel LECOESTER
Disons que dans le OLEDB, l'accès travaille au niveau du rowid et comme une des fonctiosn ODBC/OLEDB est de récupérer la valeur d'une autoincrément ton provider (oracle ou microsoft) à du développé cette fonction.
Concernant la transaction je te laisse chercher sur le net ;) Dans un SGBD tout est transaction (principe ACID de tête)
"Loko" a écrit dans le message de news:
Re bonjour Emmanuel
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un papier et je te promets la reconnaissance d'un grand monde.
Ok, au moins je sais maintenant à quoi m'en tenir ;-)
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère toujours cet id fonctionnel dans la même transaction car ton argument recevable au demeurant de perte d'id est identique ici : tu casses ta transaction ben tu perds ton id de sequence et tu ne le retrouveras jamais.
Je ne comprends pas bien ta réponse. Peux tu stp me préciser ce que tu entends par "transaction" ? Concretement, au niveau du code Windev, ca correspond à quoi ?
De plus, cela ne m'explique pas pourquoi cela fonctionne très bien en OLE DB (dans mon logiciel Windev , juste apres le HAjoute() mon champ a bien la valeur qu'Oracle lui a assignée) et pas en accès natif
Disons que dans le OLEDB, l'accès travaille au niveau du rowid et comme une
des fonctiosn ODBC/OLEDB est de récupérer la valeur d'une autoincrément ton
provider (oracle ou microsoft) à du développé cette fonction.
Concernant la transaction je te laisse chercher sur le net ;) Dans un SGBD
tout est transaction (principe ACID de tête)
"Loko" <arnaudgeslin@gmail.com> a écrit dans le message de news:
ef78bda5-79bd-42df-bda2-b99f6b6008ea@x41g2000hsb.googlegroups.com...
Re bonjour Emmanuel
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un
papier et je te promets la reconnaissance d'un grand monde.
Ok, au moins je sais maintenant à quoi m'en tenir ;-)
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère
toujours cet id fonctionnel dans la même transaction car ton argument
recevable au demeurant de perte d'id est identique ici : tu casses ta
transaction ben tu perds ton id de sequence et tu ne le retrouveras
jamais.
Je ne comprends pas bien ta réponse. Peux tu stp me préciser ce que tu
entends par "transaction" ? Concretement, au niveau du code Windev, ca
correspond à quoi ?
De plus, cela ne m'explique pas pourquoi cela fonctionne très bien en
OLE DB (dans mon logiciel Windev , juste apres le HAjoute() mon champ
a bien la valeur qu'Oracle lui a assignée) et pas en accès natif
Disons que dans le OLEDB, l'accès travaille au niveau du rowid et comme une des fonctiosn ODBC/OLEDB est de récupérer la valeur d'une autoincrément ton provider (oracle ou microsoft) à du développé cette fonction.
Concernant la transaction je te laisse chercher sur le net ;) Dans un SGBD tout est transaction (principe ACID de tête)
"Loko" a écrit dans le message de news:
Re bonjour Emmanuel
Exact. Donc ce que je te propose : si tu trouves une solution, tu fais un papier et je te promets la reconnaissance d'un grand monde.
Ok, au moins je sais maintenant à quoi m'en tenir ;-)
Gérer un id de facturation par sequence... j'ai jamais vu :-/ on génère toujours cet id fonctionnel dans la même transaction car ton argument recevable au demeurant de perte d'id est identique ici : tu casses ta transaction ben tu perds ton id de sequence et tu ne le retrouveras jamais.
Je ne comprends pas bien ta réponse. Peux tu stp me préciser ce que tu entends par "transaction" ? Concretement, au niveau du code Windev, ca correspond à quoi ?
De plus, cela ne m'explique pas pourquoi cela fonctionne très bien en OLE DB (dans mon logiciel Windev , juste apres le HAjoute() mon champ a bien la valeur qu'Oracle lui a assignée) et pas en accès natif
patrice
Emmanuel LECOESTER a écrit :
"patrice" a écrit dans le message de news: 47e3754c$0$15874$
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il faut utiliser un select maseq.currval pour connaitre le dernier numéro généré par la séquence (dans la même transaction)
Pour moi non... le currentval c'est la derniere valeur de sequence donc tous users confondus.
non, et heureusement :) d'ailleurs si tu fais pas un nextval dans ta session, currval génére une erreur.
tiens, ptit extrait de http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/views002.htm#sthref2227 la valeur currval est le dernier nextval de la session.
Once a sequence number is generated, the sequence number is available only to the session that generated the number. Independent of transactions committing or rolling back, other users referencing order_seq.NEXTVAL obtain unique values. If two users are accessing the same sequence concurrently, then the sequence numbers each user receives might have gaps because sequence numbers are also being generated by the other user.
Using Sequence Numbers with CURRVAL To use or refer to the current sequence value of your session, reference seq_name.CURRVAL. CURRVAL can only be used if seq_name.NEXTVAL has been referenced in the current user session (in the current or a previous transaction). CURRVAL can be referenced as many times as necessary, including multiple times within the same statement. The next sequence number is not generated until NEXTVAL is referenced. Continuing with the previous example, you would finish placing the customer's order by inserting the line items for the order:
Emmanuel LECOESTER a écrit :
"patrice" <patrice_labracherie_nospam@free.fr> a écrit dans le message de
news: 47e3754c$0$15874$426a74cc@news.free.fr...
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il
faut
utiliser un select maseq.currval pour connaitre le dernier numéro généré
par
la séquence (dans la même transaction)
Pour moi non... le currentval c'est la derniere valeur de sequence donc tous
users confondus.
non, et heureusement :)
d'ailleurs si tu fais pas un nextval dans ta session, currval génére une
erreur.
tiens, ptit extrait de
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/views002.htm#sthref2227
la valeur currval est le dernier nextval de la session.
Once a sequence number is generated, the sequence number is available
only to the session that generated the number. Independent of
transactions committing or rolling back, other users referencing
order_seq.NEXTVAL obtain unique values. If two users are accessing the
same sequence concurrently, then the sequence numbers each user receives
might have gaps because sequence numbers are also being generated by the
other user.
Using Sequence Numbers with CURRVAL
To use or refer to the current sequence value of your session, reference
seq_name.CURRVAL. CURRVAL can only be used if seq_name.NEXTVAL has been
referenced in the current user session (in the current or a previous
transaction). CURRVAL can be referenced as many times as necessary,
including multiple times within the same statement. The next sequence
number is not generated until NEXTVAL is referenced. Continuing with the
previous example, you would finish placing the customer's order by
inserting the line items for the order:
"patrice" a écrit dans le message de news: 47e3754c$0$15874$
J'ai jamais travaillé avec windev&oracle, mais en oracle tout court, il faut utiliser un select maseq.currval pour connaitre le dernier numéro généré par la séquence (dans la même transaction)
Pour moi non... le currentval c'est la derniere valeur de sequence donc tous users confondus.
non, et heureusement :) d'ailleurs si tu fais pas un nextval dans ta session, currval génére une erreur.
tiens, ptit extrait de http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/views002.htm#sthref2227 la valeur currval est le dernier nextval de la session.
Once a sequence number is generated, the sequence number is available only to the session that generated the number. Independent of transactions committing or rolling back, other users referencing order_seq.NEXTVAL obtain unique values. If two users are accessing the same sequence concurrently, then the sequence numbers each user receives might have gaps because sequence numbers are also being generated by the other user.
Using Sequence Numbers with CURRVAL To use or refer to the current sequence value of your session, reference seq_name.CURRVAL. CURRVAL can only be used if seq_name.NEXTVAL has been referenced in the current user session (in the current or a previous transaction). CURRVAL can be referenced as many times as necessary, including multiple times within the same statement. The next sequence number is not generated until NEXTVAL is referenced. Continuing with the previous example, you would finish placing the customer's order by inserting the line items for the order:
Loko
> Ok, mais ca n'a rien à voir avec le commit. En OLEDB, si on outre une transaction hAjoute ne la commit pas. Visiblement OLEDB se charge de la récupération de l'identifiant, chose que ne fait pas l'accès natif (il faudrait peut être le signaler à PCSoft)
c'est sans doute parceque j'utilise le moteur OLE DB fourni par Oracle et non pas celui de Windev.
> Ok, mais ca n'a rien à voir avec le commit.
En OLEDB, si on outre une transaction hAjoute ne la commit pas.
Visiblement OLEDB se charge de la récupération de l'identifiant, chose
que ne fait pas l'accès natif (il faudrait peut être le signaler à
PCSoft)
c'est sans doute parceque j'utilise le moteur OLE DB fourni par Oracle
et non pas celui de Windev.
> Ok, mais ca n'a rien à voir avec le commit. En OLEDB, si on outre une transaction hAjoute ne la commit pas. Visiblement OLEDB se charge de la récupération de l'identifiant, chose que ne fait pas l'accès natif (il faudrait peut être le signaler à PCSoft)
c'est sans doute parceque j'utilise le moteur OLE DB fourni par Oracle et non pas celui de Windev.
Loko
Bonjour tout le monde.
Je viens d'avoir une solution très simple : au lieu de faire FichierVersEcran() c'est HLit(MaTable) qu'il faut faire juste après le HAjoute. HLit relit l'enregistrement en se basant sur le rowid, donc l'enregistrement courant qui vient d'etre ajouté, et du coup j'ai bien ma valeur d'ID automatique en mémoire.
PS : je ne souhaite pas m'embeter avec des ouvertures/fermetures de transaction, c'est surement utile dans certains cas mais pas pour moi.
PS2 : Gilles, encore merci pour ta solution mais je ne prendrai finalement pas le temps de la tester puisque j'en ai trouvé une autre.
A bientôt Loko
Bonjour tout le monde.
Je viens d'avoir une solution très simple : au lieu de faire
FichierVersEcran() c'est HLit(MaTable) qu'il faut faire juste après le
HAjoute.
HLit relit l'enregistrement en se basant sur le rowid, donc
l'enregistrement courant qui vient d'etre ajouté, et du coup j'ai bien
ma valeur d'ID automatique en mémoire.
PS : je ne souhaite pas m'embeter avec des ouvertures/fermetures de
transaction, c'est surement utile dans certains cas mais pas pour moi.
PS2 : Gilles, encore merci pour ta solution mais je ne prendrai
finalement pas le temps de la tester puisque j'en ai trouvé une autre.
Je viens d'avoir une solution très simple : au lieu de faire FichierVersEcran() c'est HLit(MaTable) qu'il faut faire juste après le HAjoute. HLit relit l'enregistrement en se basant sur le rowid, donc l'enregistrement courant qui vient d'etre ajouté, et du coup j'ai bien ma valeur d'ID automatique en mémoire.
PS : je ne souhaite pas m'embeter avec des ouvertures/fermetures de transaction, c'est surement utile dans certains cas mais pas pour moi.
PS2 : Gilles, encore merci pour ta solution mais je ne prendrai finalement pas le temps de la tester puisque j'en ai trouvé une autre.
A bientôt Loko
Emmanuel LECOESTER
Désolé de te décevoir mais ton PS sera tout de même mis en oeuvre... dans un SGBD tel que Oracle TOUT est transaction...
"Loko" a écrit dans le message de news:
Bonjour tout le monde.
Je viens d'avoir une solution très simple : au lieu de faire FichierVersEcran() c'est HLit(MaTable) qu'il faut faire juste après le HAjoute. HLit relit l'enregistrement en se basant sur le rowid, donc l'enregistrement courant qui vient d'etre ajouté, et du coup j'ai bien ma valeur d'ID automatique en mémoire.
PS : je ne souhaite pas m'embeter avec des ouvertures/fermetures de transaction, c'est surement utile dans certains cas mais pas pour moi.
PS2 : Gilles, encore merci pour ta solution mais je ne prendrai finalement pas le temps de la tester puisque j'en ai trouvé une autre.
A bientôt Loko
Désolé de te décevoir mais ton PS sera tout de même mis en oeuvre... dans un
SGBD tel que Oracle TOUT est transaction...
"Loko" <arnaudgeslin@gmail.com> a écrit dans le message de news:
ea4e2dc7-b28e-4189-a05b-7d78eb446f01@s8g2000prg.googlegroups.com...
Bonjour tout le monde.
Je viens d'avoir une solution très simple : au lieu de faire
FichierVersEcran() c'est HLit(MaTable) qu'il faut faire juste après le
HAjoute.
HLit relit l'enregistrement en se basant sur le rowid, donc
l'enregistrement courant qui vient d'etre ajouté, et du coup j'ai bien
ma valeur d'ID automatique en mémoire.
PS : je ne souhaite pas m'embeter avec des ouvertures/fermetures de
transaction, c'est surement utile dans certains cas mais pas pour moi.
PS2 : Gilles, encore merci pour ta solution mais je ne prendrai
finalement pas le temps de la tester puisque j'en ai trouvé une autre.
Désolé de te décevoir mais ton PS sera tout de même mis en oeuvre... dans un SGBD tel que Oracle TOUT est transaction...
"Loko" a écrit dans le message de news:
Bonjour tout le monde.
Je viens d'avoir une solution très simple : au lieu de faire FichierVersEcran() c'est HLit(MaTable) qu'il faut faire juste après le HAjoute. HLit relit l'enregistrement en se basant sur le rowid, donc l'enregistrement courant qui vient d'etre ajouté, et du coup j'ai bien ma valeur d'ID automatique en mémoire.
PS : je ne souhaite pas m'embeter avec des ouvertures/fermetures de transaction, c'est surement utile dans certains cas mais pas pour moi.
PS2 : Gilles, encore merci pour ta solution mais je ne prendrai finalement pas le temps de la tester puisque j'en ai trouvé une autre.
A bientôt Loko
Loko
On 27 mar, 20:51, "Emmanuel LECOESTER" wrote:
Désolé de te décevoir mais ton PS sera tout de même mis en oeuvre. .. dans un SGBD tel que Oracle TOUT est transaction...
Oui mais c'est géré automatiquement et ce que je voulais dire c'est que je ne voulais pas m'embêter à gérer cela moi-même par programmation.
L.
On 27 mar, 20:51, "Emmanuel LECOESTER" <eleco...@netcourrier.com>
wrote:
Désolé de te décevoir mais ton PS sera tout de même mis en oeuvre. .. dans un
SGBD tel que Oracle TOUT est transaction...
Oui mais c'est géré automatiquement et ce que je voulais dire c'est
que je ne voulais pas m'embêter à gérer cela moi-même par
programmation.
