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.
C'est bizarre que l'acces natif puisse empecher un trigger de la db de s'exécuter y'aurait pas un test dans le trigger ? un truc du genre : FOR EACH ROW BEGIN if :new.TABLE_ID is null then SELECT TABLE_SEQ.NEXTVAL INTO :new.TABLE_ID from DUAL; end if; END;
dans ce cas ca serait tout betement le null qui serait pas positionné mais ptet autre chose (ou 0, car 0 est <> de null)
"Loko" a écrit dans le message de news: Bonjour
J'utilise Windev 11 avec Oracle 10g.
J'ai une table avec un champ clef primaire de type compteur, j'ai donc créé une séquence spéciale ce champ dans Oracle, ainsi qu'un trigger Before Insert qui remplit automatiquement le champ concerné avec le nextval de ma séquence.
Un test d'insert directement sous Oracle confirme le bon fonctionnement de l'ensemble.
Ensuite sous Windev, ca marche moyennement :
- en accès OLE DB le nouvel enregistrement est bien créé par un HAjoute et si je trace juste apres la valeur du champ concerné Windev retrouve bien la nextval créé par la base Oracle.
- par contre en accès natif cela ne fonctionne pas : le nouvel enregistrement est créé mais la valeur du champ reste à zéro.
- J'ai essayé en déclarant le champ en ID automatique dans l'analyse et j'ai également essayé en le déclarant comme un numérique standard (en clef unique, evidemment), dans les 2 cas ca fonctionne en OLE DB mais pas en accès natif.
Je voudrais donc savoir comment retrouver le numéro généré par Oracle 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.
Merci d'avance
C'est bizarre que l'acces natif puisse empecher un trigger de la db de
s'exécuter
y'aurait pas un test dans le trigger ?
un truc du genre :
FOR EACH ROW BEGIN
if :new.TABLE_ID is null then
SELECT TABLE_SEQ.NEXTVAL INTO :new.TABLE_ID from DUAL;
end if;
END;
dans ce cas ca serait tout betement le null qui serait pas positionné mais
ptet autre chose (ou 0, car 0 est <> de null)
"Loko" <arnaudgeslin@gmail.com> a écrit dans le message de
news:3cd0be05-c69e-45a9-b5a2-124524b465fa@2g2000hsn.googlegroups.com...
Bonjour
J'utilise Windev 11 avec Oracle 10g.
J'ai une table avec un champ clef primaire de type compteur, j'ai donc
créé une séquence spéciale ce champ dans Oracle, ainsi qu'un trigger
Before Insert qui remplit automatiquement le champ concerné avec le
nextval de ma séquence.
Un test d'insert directement sous Oracle confirme le bon
fonctionnement de l'ensemble.
Ensuite sous Windev, ca marche moyennement :
- en accès OLE DB le nouvel enregistrement est bien créé par un
HAjoute et si je trace juste apres la valeur du champ concerné Windev
retrouve bien la nextval créé par la base Oracle.
- par contre en accès natif cela ne fonctionne pas : le nouvel
enregistrement est créé mais la valeur du champ reste à zéro.
- J'ai essayé en déclarant le champ en ID automatique dans l'analyse
et j'ai également essayé en le déclarant comme un numérique standard
(en clef unique, evidemment), dans les 2 cas ca fonctionne en OLE DB
mais pas en accès natif.
Je voudrais donc savoir comment retrouver le numéro généré par Oracle
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.
C'est bizarre que l'acces natif puisse empecher un trigger de la db de s'exécuter y'aurait pas un test dans le trigger ? un truc du genre : FOR EACH ROW BEGIN if :new.TABLE_ID is null then SELECT TABLE_SEQ.NEXTVAL INTO :new.TABLE_ID from DUAL; end if; END;
dans ce cas ca serait tout betement le null qui serait pas positionné mais ptet autre chose (ou 0, car 0 est <> de null)
"Loko" a écrit dans le message de news: Bonjour
J'utilise Windev 11 avec Oracle 10g.
J'ai une table avec un champ clef primaire de type compteur, j'ai donc créé une séquence spéciale ce champ dans Oracle, ainsi qu'un trigger Before Insert qui remplit automatiquement le champ concerné avec le nextval de ma séquence.
Un test d'insert directement sous Oracle confirme le bon fonctionnement de l'ensemble.
Ensuite sous Windev, ca marche moyennement :
- en accès OLE DB le nouvel enregistrement est bien créé par un HAjoute et si je trace juste apres la valeur du champ concerné Windev retrouve bien la nextval créé par la base Oracle.
- par contre en accès natif cela ne fonctionne pas : le nouvel enregistrement est créé mais la valeur du champ reste à zéro.
- J'ai essayé en déclarant le champ en ID automatique dans l'analyse et j'ai également essayé en le déclarant comme un numérique standard (en clef unique, evidemment), dans les 2 cas ca fonctionne en OLE DB mais pas en accès natif.
Je voudrais donc savoir comment retrouver le numéro généré par Oracle 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.
Merci d'avance
Emmanuel LECOESTER
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 :)
"Loko" a écrit dans le message de news:
Bonjour
J'utilise Windev 11 avec Oracle 10g.
J'ai une table avec un champ clef primaire de type compteur, j'ai donc créé une séquence spéciale ce champ dans Oracle, ainsi qu'un trigger Before Insert qui remplit automatiquement le champ concerné avec le nextval de ma séquence.
Un test d'insert directement sous Oracle confirme le bon fonctionnement de l'ensemble.
Ensuite sous Windev, ca marche moyennement :
- en accès OLE DB le nouvel enregistrement est bien créé par un HAjoute et si je trace juste apres la valeur du champ concerné Windev retrouve bien la nextval créé par la base Oracle.
- par contre en accès natif cela ne fonctionne pas : le nouvel enregistrement est créé mais la valeur du champ reste à zéro.
- J'ai essayé en déclarant le champ en ID automatique dans l'analyse et j'ai également essayé en le déclarant comme un numérique standard (en clef unique, evidemment), dans les 2 cas ca fonctionne en OLE DB mais pas en accès natif.
Je voudrais donc savoir comment retrouver le numéro généré par Oracle 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.
Merci d'avance
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
:)
"Loko" <arnaudgeslin@gmail.com> a écrit dans le message de news:
3cd0be05-c69e-45a9-b5a2-124524b465fa@2g2000hsn.googlegroups.com...
Bonjour
J'utilise Windev 11 avec Oracle 10g.
J'ai une table avec un champ clef primaire de type compteur, j'ai donc
créé une séquence spéciale ce champ dans Oracle, ainsi qu'un trigger
Before Insert qui remplit automatiquement le champ concerné avec le
nextval de ma séquence.
Un test d'insert directement sous Oracle confirme le bon
fonctionnement de l'ensemble.
Ensuite sous Windev, ca marche moyennement :
- en accès OLE DB le nouvel enregistrement est bien créé par un
HAjoute et si je trace juste apres la valeur du champ concerné Windev
retrouve bien la nextval créé par la base Oracle.
- par contre en accès natif cela ne fonctionne pas : le nouvel
enregistrement est créé mais la valeur du champ reste à zéro.
- J'ai essayé en déclarant le champ en ID automatique dans l'analyse
et j'ai également essayé en le déclarant comme un numérique standard
(en clef unique, evidemment), dans les 2 cas ca fonctionne en OLE DB
mais pas en accès natif.
Je voudrais donc savoir comment retrouver le numéro généré par Oracle
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.
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 :)
"Loko" a écrit dans le message de news:
Bonjour
J'utilise Windev 11 avec Oracle 10g.
J'ai une table avec un champ clef primaire de type compteur, j'ai donc créé une séquence spéciale ce champ dans Oracle, ainsi qu'un trigger Before Insert qui remplit automatiquement le champ concerné avec le nextval de ma séquence.
Un test d'insert directement sous Oracle confirme le bon fonctionnement de l'ensemble.
Ensuite sous Windev, ca marche moyennement :
- en accès OLE DB le nouvel enregistrement est bien créé par un HAjoute et si je trace juste apres la valeur du champ concerné Windev retrouve bien la nextval créé par la base Oracle.
- par contre en accès natif cela ne fonctionne pas : le nouvel enregistrement est créé mais la valeur du champ reste à zéro.
- J'ai essayé en déclarant le champ en ID automatique dans l'analyse et j'ai également essayé en le déclarant comme un numérique standard (en clef unique, evidemment), dans les 2 cas ca fonctionne en OLE DB mais pas en accès natif.
Je voudrais donc savoir comment retrouver le numéro généré par Oracle 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.
Merci d'avance
Loko
Bonjour
C'est bizarre que l'acces natif puisse empecher un trigger de la db de s'exécuter
Non, ca n'empeche nullement le trigger de s'exécuter ... l'enregistrement est bien créé sous Oracle et le trigger a marché puisque le champ clef a bien pris le nextval de la sequence.
Le seul bleme, c'est que dans Windev apres le HAjoute() on ne connait pas la vraie valeur du champ clef
y'aurait pas un test dans le trigger ? un truc du genre : FOR EACH ROW BEGIN if :new.TABLE_ID is null then SELECT TABLE_SEQ.NEXTVAL INTO :new.TABLE_ID from DUAL; end if; END;
Non y'a pas de test, j'affectve systematiquement le nextval a mon champ sans condition
Bonjour
C'est bizarre que l'acces natif puisse empecher un trigger de la db de
s'exécuter
Non, ca n'empeche nullement le trigger de s'exécuter ...
l'enregistrement est bien créé sous Oracle et le trigger a marché
puisque le champ clef a bien pris le nextval de la sequence.
Le seul bleme, c'est que dans Windev apres le HAjoute() on ne connait
pas la vraie valeur du champ clef
y'aurait pas un test dans le trigger ?
un truc du genre :
FOR EACH ROW BEGIN
if :new.TABLE_ID is null then
SELECT TABLE_SEQ.NEXTVAL INTO :new.TABLE_ID from DUAL;
end if;
END;
Non y'a pas de test, j'affectve systematiquement le nextval a mon
champ sans condition
C'est bizarre que l'acces natif puisse empecher un trigger de la db de s'exécuter
Non, ca n'empeche nullement le trigger de s'exécuter ... l'enregistrement est bien créé sous Oracle et le trigger a marché puisque le champ clef a bien pris le nextval de la sequence.
Le seul bleme, c'est que dans Windev apres le HAjoute() on ne connait pas la vraie valeur du champ clef
y'aurait pas un test dans le trigger ? un truc du genre : FOR EACH ROW BEGIN if :new.TABLE_ID is null then SELECT TABLE_SEQ.NEXTVAL INTO :new.TABLE_ID from DUAL; end if; END;
Non y'a pas de test, j'affectve systematiquement le nextval a mon champ sans condition
Loko
Bonjour
D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un c oup dans la sequence et tu gères ton insert toi même avec ton id (deux var iable : id_courant, id_max, si id_courant = id_max alors reprendre les 100 sequences suivantes).
Ca me semble franchement biscornu. Surtout que ca marche tres bien sans cela avec l'accès OLE DB : si je teste la valeur de mon champ clef apres le Hajoute() et bien elle est correcte (= le nextval utilisé). Alors pourquoi pas en accès natif ?
Bonjour
D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un c oup
dans la sequence et tu gères ton insert toi même avec ton id (deux var iable
: id_courant, id_max, si id_courant = id_max alors reprendre les 100
sequences suivantes).
Ca me semble franchement biscornu. Surtout que ca marche tres bien
sans cela avec l'accès OLE DB : si je teste la valeur de mon champ
clef apres le Hajoute() et bien elle est correcte (= le nextval
utilisé). Alors pourquoi pas en accès natif ?
D'où la technique utilisé par plusieurs outil : tu prend 100 id d'un c oup dans la sequence et tu gères ton insert toi même avec ton id (deux var iable : id_courant, id_max, si id_courant = id_max alors reprendre les 100 sequences suivantes).
Ca me semble franchement biscornu. Surtout que ca marche tres bien sans cela avec l'accès OLE DB : si je teste la valeur de mon champ clef apres le Hajoute() et bien elle est correcte (= le nextval utilisé). Alors pourquoi pas en accès natif ?
Loko
> Ca ne posera aucun problème tant que tu es dans ta transaction logiquement. Tant que tu n'as pas ton commit, tu ne devrais rien voir d'autre que ce qu'il y avait au moment de ta transaction.
Désolé mais je n'ai pas compris votre réponse. Y'a pas de commit à faire, Windev les fait automatiquement dans le HAjoute().
Je me suis peut etre mal exprimé : quand je dis que la valeur du champ reste à zéro c'est dans Windev en accès natif, sous Oracle j'ai bien une valeur correcte apres le HAjoute().
De plus si je fais un HRAZ puis que je relis ma table je retrouve bien le nouvel enregistrement avec sa bonne valeur de clef ... mais je souhaite la connaitre sans avoir à faire cela.
> Ca ne posera aucun problème tant que tu es dans ta transaction
logiquement.
Tant que tu n'as pas ton commit, tu ne devrais rien voir d'autre que ce
qu'il y avait au moment de ta transaction.
Désolé mais je n'ai pas compris votre réponse. Y'a pas de commit à
faire, Windev les fait automatiquement dans le HAjoute().
Je me suis peut etre mal exprimé : quand je dis que la valeur du champ
reste à zéro c'est dans Windev en accès natif, sous Oracle j'ai bien
une valeur correcte apres le HAjoute().
De plus si je fais un HRAZ puis que je relis ma table je retrouve bien
le nouvel enregistrement avec sa bonne valeur de clef ... mais je
souhaite la connaitre sans avoir à faire cela.
> Ca ne posera aucun problème tant que tu es dans ta transaction logiquement. Tant que tu n'as pas ton commit, tu ne devrais rien voir d'autre que ce qu'il y avait au moment de ta transaction.
Désolé mais je n'ai pas compris votre réponse. Y'a pas de commit à faire, Windev les fait automatiquement dans le HAjoute().
Je me suis peut etre mal exprimé : quand je dis que la valeur du champ reste à zéro c'est dans Windev en accès natif, sous Oracle j'ai bien une valeur correcte apres le HAjoute().
De plus si je fais un HRAZ puis que je relis ma table je retrouve bien le nouvel enregistrement avec sa bonne valeur de clef ... mais je souhaite la connaitre sans avoir à faire cela.
Loko
On 20 mar, 19:53, "Emmanuel LECOESTER" wrote:
Concernant les auto_id sous Oracle la technique du trigger est interessant e 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 c oup dans la sequence et tu gères ton insert toi même avec ton id (deux var iable : 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 ...
On 20 mar, 19:53, "Emmanuel LECOESTER" <eleco...@netcourrier.com>
wrote:
Concernant les auto_id sous Oracle la technique du trigger est interessant e
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 c oup
dans la sequence et tu gères ton insert toi même avec ton id (deux var iable
: 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 ...
Concernant les auto_id sous Oracle la technique du trigger est interessant e 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 c oup dans la sequence et tu gères ton insert toi même avec ton id (deux var iable : 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
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 ...
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 ...
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 ...
Loko
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
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
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
Loko
Bonour Gilles
Hajoute fait un commit automatique??
Oui, dans mon code en tout cas. Avec OLEDB, si je fais HAjoute(MA_TABLE) Trace(MA_TABLE.CHAMP_ID)
Et bien le trace m'affiche bien la valeur attribuée par la séquence Oracle. Mais pas en accès natif.
Si vous faites un SQLTransaction de début, hajoute ne fait strictement rien, il faut le SQLTransaction de fin.
Et dans tout ce que vous faites entre les deux, vous êtes cloisonné, vous pouvez relire la table et votre dernier ID, ca ne posera pas de problème par rapport aux autres insertions tant que vous restez dans votre transaction.
J'ai toujours fait comme ça avec Oracle.
Exemple : SQLTransaction(sqlDébut,cCNX) <traitement> HAjoute(MaTable) HLitDernier(MaTable,ID) nID=MaTable.ID SQLTransaction(sqlFin,cCNX)
Merci beaucoup, je vais essayer cela et je vous tiens au courant.
Bonour Gilles
Hajoute fait un commit automatique??
Oui, dans mon code en tout cas. Avec OLEDB, si je fais
HAjoute(MA_TABLE)
Trace(MA_TABLE.CHAMP_ID)
Et bien le trace m'affiche bien la valeur attribuée par la séquence
Oracle. Mais pas en accès natif.
Si vous faites un SQLTransaction de début, hajoute ne fait strictement
rien, il faut le SQLTransaction de fin.
Et dans tout ce que vous faites entre les deux, vous êtes cloisonné,
vous pouvez relire la table et votre dernier ID, ca ne posera pas de
problème par rapport aux autres insertions tant que vous restez dans
votre transaction.
J'ai toujours fait comme ça avec Oracle.
Exemple :
SQLTransaction(sqlDébut,cCNX)
<traitement>
HAjoute(MaTable)
HLitDernier(MaTable,ID)
nID=MaTable.ID
SQLTransaction(sqlFin,cCNX)
Merci beaucoup, je vais essayer cela et je vous tiens au courant.
Oui, dans mon code en tout cas. Avec OLEDB, si je fais HAjoute(MA_TABLE) Trace(MA_TABLE.CHAMP_ID)
Et bien le trace m'affiche bien la valeur attribuée par la séquence Oracle. Mais pas en accès natif.
Si vous faites un SQLTransaction de début, hajoute ne fait strictement rien, il faut le SQLTransaction de fin.
Et dans tout ce que vous faites entre les deux, vous êtes cloisonné, vous pouvez relire la table et votre dernier ID, ca ne posera pas de problème par rapport aux autres insertions tant que vous restez dans votre transaction.
J'ai toujours fait comme ça avec Oracle.
Exemple : SQLTransaction(sqlDébut,cCNX) <traitement> HAjoute(MaTable) HLitDernier(MaTable,ID) nID=MaTable.ID SQLTransaction(sqlFin,cCNX)
Merci beaucoup, je vais essayer cela et je vous tiens au courant.
patrice
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 ...
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 ...
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 ...
