Dans le cadre de l'utilisation de l'accès natif SQL server, nous avons
décelé une faute très contraignante.
Si un trigger faisant "un ou plusieurs INSERT dans une autre table" existe
dans le serveur SQL (donc pas en WinDev !) et que l'on fait un ajout via
les commandes HF, un mauvais identifiant est renvoyé pour la clé unique
ajoutée.
Comment le reproduire ?
Sous SQL, définir un trigger qui va pour chaque enregistrement ajouté dans
la table "ALPHONSE" faire un ou plusieurs "insert" via un Trigger de SQL
Server dans une table "LEONTINNE". Si l'ajout initial depuis WinDev s'est
fait par une commande Hajoute("Alphonse"), la clé unique reçue en Windev
sera celle de "LEONTINNE" ! Les conséquences sont évidemment
catastrophiques.
Si quelqu'un peut me confirmer le problème... Et si en plus, il a trouvé une
solution...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Adrien
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il n'y a qu'un seul id pour toute les tables.
par exemple tu ajoute un client, son id est 1, tu créé une facture id = 2 puis tu recrée un client id = 3, etc...
A+ Adrien.
"B. Neve" a écrit dans le message de news:41429e5b$0$3886$
Bonjour,
Dans le cadre de l'utilisation de l'accès natif SQL server, nous avons décelé une faute très contraignante.
Si un trigger faisant "un ou plusieurs INSERT dans une autre table" existe dans le serveur SQL (donc pas en WinDev !) et que l'on fait un ajout via les commandes HF, un mauvais identifiant est renvoyé pour la clé unique ajoutée.
Comment le reproduire ?
Sous SQL, définir un trigger qui va pour chaque enregistrement ajouté dans la table "ALPHONSE" faire un ou plusieurs "insert" via un Trigger de SQL Server dans une table "LEONTINNE". Si l'ajout initial depuis WinDev s'est fait par une commande Hajoute("Alphonse"), la clé unique reçue en Windev sera celle de "LEONTINNE" ! Les conséquences sont évidemment catastrophiques.
Si quelqu'un peut me confirmer le problème... Et si en plus, il a trouvé
une
solution...
Benoit Neve
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il n'y
a qu'un seul id pour toute les tables.
par exemple tu ajoute un client, son id est 1, tu créé une facture id = 2
puis tu recrée un client id = 3, etc...
A+
Adrien.
"B. Neve" <bne@dagico.com> a écrit dans le message de
news:41429e5b$0$3886$ba620e4c@news.skynet.be...
Bonjour,
Dans le cadre de l'utilisation de l'accès natif SQL server, nous avons
décelé une faute très contraignante.
Si un trigger faisant "un ou plusieurs INSERT dans une autre table" existe
dans le serveur SQL (donc pas en WinDev !) et que l'on fait un ajout via
les commandes HF, un mauvais identifiant est renvoyé pour la clé unique
ajoutée.
Comment le reproduire ?
Sous SQL, définir un trigger qui va pour chaque enregistrement ajouté dans
la table "ALPHONSE" faire un ou plusieurs "insert" via un Trigger de SQL
Server dans une table "LEONTINNE". Si l'ajout initial depuis WinDev s'est
fait par une commande Hajoute("Alphonse"), la clé unique reçue en Windev
sera celle de "LEONTINNE" ! Les conséquences sont évidemment
catastrophiques.
Si quelqu'un peut me confirmer le problème... Et si en plus, il a trouvé
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il n'y a qu'un seul id pour toute les tables.
par exemple tu ajoute un client, son id est 1, tu créé une facture id = 2 puis tu recrée un client id = 3, etc...
A+ Adrien.
"B. Neve" a écrit dans le message de news:41429e5b$0$3886$
Bonjour,
Dans le cadre de l'utilisation de l'accès natif SQL server, nous avons décelé une faute très contraignante.
Si un trigger faisant "un ou plusieurs INSERT dans une autre table" existe dans le serveur SQL (donc pas en WinDev !) et que l'on fait un ajout via les commandes HF, un mauvais identifiant est renvoyé pour la clé unique ajoutée.
Comment le reproduire ?
Sous SQL, définir un trigger qui va pour chaque enregistrement ajouté dans la table "ALPHONSE" faire un ou plusieurs "insert" via un Trigger de SQL Server dans une table "LEONTINNE". Si l'ajout initial depuis WinDev s'est fait par une commande Hajoute("Alphonse"), la clé unique reçue en Windev sera celle de "LEONTINNE" ! Les conséquences sont évidemment catastrophiques.
Si quelqu'un peut me confirmer le problème... Et si en plus, il a trouvé
une
solution...
Benoit Neve
Roumegou Eric
Adrien avait énoncé :
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il n'y a qu'un seul id pour toute les tables.
Ils ont fait la mème chose qu'avec l'accès Oracle alors ? (une seule séquence) Ce n'était pourtant pas dur de gèrer des séquences avec le nom de la table, ou autre donnée significative et unique. Dans ce cas, l'idée n'est-elle pas de faire gérer cela par un trigger au niveau du SGBD ?
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
Adrien avait énoncé :
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il n'y
a qu'un seul id pour toute les tables.
Ils ont fait la mème chose qu'avec l'accès Oracle alors ? (une seule
séquence)
Ce n'était pourtant pas dur de gèrer des séquences avec le nom de la
table, ou autre donnée significative et unique.
Dans ce cas, l'idée n'est-elle pas de faire gérer cela par un trigger
au niveau du SGBD ?
--
Eric Roumégou
http://cerbermail.com/?TSoulBerPA
(cliquez sur le lien ci-dessus pour me contacter en privé)
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il n'y a qu'un seul id pour toute les tables.
Ils ont fait la mème chose qu'avec l'accès Oracle alors ? (une seule séquence) Ce n'était pourtant pas dur de gèrer des séquences avec le nom de la table, ou autre donnée significative et unique. Dans ce cas, l'idée n'est-elle pas de faire gérer cela par un trigger au niveau du SGBD ?
-- Eric Roumégou http://cerbermail.com/?TSoulBerPA (cliquez sur le lien ci-dessus pour me contacter en privé)
B. Neve
"Adrien" a écrit dans le message de news:4144bcdb$0$32647$
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il
n'y
a qu'un seul id pour toute les tables.
par exemple tu ajoute un client, son id est 1, tu créé une facture id = 2 puis tu recrée un client id = 3, etc...
Bonjour,
Je n'utilise pas les ID de Windev, tout est géré par le serveur. En WD, j'ai des clés uniques mais c'est tout. Lorsque j'ajoute un enregistrement, c'est SQL Server qui lui donne un ID et WD le récupère je pense avec une lecture de @@IDENTITY au lieu de SCOPE_IDENTITY(). Le résultat est qu'en cas de trigger,... c'est l'ID octroyé dans ce dernier que je reçois au lieu de recevoir l'ID de l'insert qui a déclenché ce trigger.
Voilà après analyse la cause probable de la faute.
Benoit Neve
"Adrien" <adrien.titou@ifrance.com> a écrit dans le message de
news:4144bcdb$0$32647$636a15ce@news.free.fr...
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il
n'y
a qu'un seul id pour toute les tables.
par exemple tu ajoute un client, son id est 1, tu créé une facture id = 2
puis tu recrée un client id = 3, etc...
Bonjour,
Je n'utilise pas les ID de Windev, tout est géré par le serveur. En WD, j'ai
des clés uniques mais c'est tout. Lorsque j'ajoute un enregistrement, c'est
SQL Server qui lui donne un ID et WD le récupère je pense avec une lecture
de @@IDENTITY au lieu de SCOPE_IDENTITY(). Le résultat est qu'en cas de
trigger,... c'est l'ID octroyé dans ce dernier que je reçois au lieu de
recevoir l'ID de l'insert qui a déclenché ce trigger.
Voilà après analyse la cause probable de la faute.
"Adrien" a écrit dans le message de news:4144bcdb$0$32647$
si tu utilise un idauto géré par windev pour tes tables, je crois qu'il
n'y
a qu'un seul id pour toute les tables.
par exemple tu ajoute un client, son id est 1, tu créé une facture id = 2 puis tu recrée un client id = 3, etc...
Bonjour,
Je n'utilise pas les ID de Windev, tout est géré par le serveur. En WD, j'ai des clés uniques mais c'est tout. Lorsque j'ajoute un enregistrement, c'est SQL Server qui lui donne un ID et WD le récupère je pense avec une lecture de @@IDENTITY au lieu de SCOPE_IDENTITY(). Le résultat est qu'en cas de trigger,... c'est l'ID octroyé dans ce dernier que je reçois au lieu de recevoir l'ID de l'insert qui a déclenché ce trigger.
Voilà après analyse la cause probable de la faute.
