Windev 11, ID automatiques sous Oracle, séquences et trigger

Le
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éé 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 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.

Merci d'avance
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
patrice
Le #14528451
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" 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
Le #14524951
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"
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
Le #14524931
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
Loko
Le #14524921
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 ?
Loko
Le #14524911
> 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
Le #14524901
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 ...
Emmanuel LECOESTER
Le #14524891
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"
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
Le #14524861
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
Loko
Le #14524851
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.
patrice
Le #14524841
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" 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"
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 ...




Publicité
Poster une réponse
Anonyme