bonjour,
je développe sous visual basic 6, sp6 et j'ai une question sur les
transactions:
j'ai écrit le code suivant:
On Error GoTo rb
BeginTrans
ExecuteSql "Delete from PARAMAPP where IDPARAM=167"
On Error Resume Next
ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL,
IDCARACT int NOT NULL) ON [PRIMARY]"
On Error GoTo rb
ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)"
CommitTrans
Exit Function
rb:
RollBack
Exit Function
les fonctions ne font rien d'autres que d'executer les méthodes begintrans
et execute de l'objet ADODB.connection qui a été instancié plutôt.
Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur de 167,
et la table UTILCARACT existe aussi.
mais ce qui me surprend c'est que le dernier insert qui devrait passer
échoue et Sql me renvoie une violation de clé.
et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter la
transaction et tout ce qui a été éxecuté entre l'ouverture de transaction et
ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon code !)
Je pensais que le CREATE TABLE encadré par un on error resume next ne
poserait pas de soucis mais si ! et à un niveau qui ne me permet pas de
savoir que ma transaction passe à la trappe !
merci de m'expliquer le mécanisme sous jacent qui explique tout et comment
me prémunir de l'echec d'une transaction.
Je sais que je peux tester l'existence de la table, mais sera-ce la même
chose avec un DROP FUNCTION sur une fonction qui n'existe pas.
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
Patrice
On Error Resume Next est une instruction VB et n'a rien à voir avec les transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe néanmoins). Du point de vue de SQL, l'erreur existe bien !!!
Je pense que le plus simple est de tester l'existence de la table. J'aurais aussi tendance à ne pas mélanger les insertions et le DDL et eslon le cas peut-être à créer la table en permanence et non pas en fonction des besoins...
Patrice
--
"Jean-Maurice" a écrit dans le message de news:41c865e9$0$32154$
bonjour, je développe sous visual basic 6, sp6 et j'ai une question sur les transactions: j'ai écrit le code suivant: On Error GoTo rb BeginTrans ExecuteSql "Delete from PARAMAPP where IDPARAM7" On Error Resume Next ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL, IDCARACT int NOT NULL) ON [PRIMARY]" On Error GoTo rb ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)" CommitTrans Exit Function rb: RollBack Exit Function
les fonctions ne font rien d'autres que d'executer les méthodes begintrans et execute de l'objet ADODB.connection qui a été instancié plutôt. Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur de
167,
et la table UTILCARACT existe aussi. mais ce qui me surprend c'est que le dernier insert qui devrait passer échoue et Sql me renvoie une violation de clé. et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter la transaction et tout ce qui a été éxecuté entre l'ouverture de transaction
et
ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon code !) Je pensais que le CREATE TABLE encadré par un on error resume next ne poserait pas de soucis mais si ! et à un niveau qui ne me permet pas de savoir que ma transaction passe à la trappe ! merci de m'expliquer le mécanisme sous jacent qui explique tout et comment me prémunir de l'echec d'une transaction. Je sais que je peux tester l'existence de la table, mais sera-ce la même chose avec un DROP FUNCTION sur une fonction qui n'existe pas.
merci de m'avoir lu
Jean-Maurice
On Error Resume Next est une instruction VB et n'a rien à voir avec les
transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe
néanmoins). Du point de vue de SQL, l'erreur existe bien !!!
Je pense que le plus simple est de tester l'existence de la table. J'aurais
aussi tendance à ne pas mélanger les insertions et le DDL et eslon le cas
peut-être à créer la table en permanence et non pas en fonction des
besoins...
Patrice
--
"Jean-Maurice" <jmclochard@wanadoo.fr> a écrit dans le message de
news:41c865e9$0$32154$8fcfb975@news.wanadoo.fr...
bonjour,
je développe sous visual basic 6, sp6 et j'ai une question sur les
transactions:
j'ai écrit le code suivant:
On Error GoTo rb
BeginTrans
ExecuteSql "Delete from PARAMAPP where IDPARAM7"
On Error Resume Next
ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL,
IDCARACT int NOT NULL) ON [PRIMARY]"
On Error GoTo rb
ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)"
CommitTrans
Exit Function
rb:
RollBack
Exit Function
les fonctions ne font rien d'autres que d'executer les méthodes begintrans
et execute de l'objet ADODB.connection qui a été instancié plutôt.
Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur de
167,
et la table UTILCARACT existe aussi.
mais ce qui me surprend c'est que le dernier insert qui devrait passer
échoue et Sql me renvoie une violation de clé.
et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter la
transaction et tout ce qui a été éxecuté entre l'ouverture de transaction
et
ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon code !)
Je pensais que le CREATE TABLE encadré par un on error resume next ne
poserait pas de soucis mais si ! et à un niveau qui ne me permet pas de
savoir que ma transaction passe à la trappe !
merci de m'expliquer le mécanisme sous jacent qui explique tout et comment
me prémunir de l'echec d'une transaction.
Je sais que je peux tester l'existence de la table, mais sera-ce la même
chose avec un DROP FUNCTION sur une fonction qui n'existe pas.
On Error Resume Next est une instruction VB et n'a rien à voir avec les transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe néanmoins). Du point de vue de SQL, l'erreur existe bien !!!
Je pense que le plus simple est de tester l'existence de la table. J'aurais aussi tendance à ne pas mélanger les insertions et le DDL et eslon le cas peut-être à créer la table en permanence et non pas en fonction des besoins...
Patrice
--
"Jean-Maurice" a écrit dans le message de news:41c865e9$0$32154$
bonjour, je développe sous visual basic 6, sp6 et j'ai une question sur les transactions: j'ai écrit le code suivant: On Error GoTo rb BeginTrans ExecuteSql "Delete from PARAMAPP where IDPARAM7" On Error Resume Next ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL, IDCARACT int NOT NULL) ON [PRIMARY]" On Error GoTo rb ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)" CommitTrans Exit Function rb: RollBack Exit Function
les fonctions ne font rien d'autres que d'executer les méthodes begintrans et execute de l'objet ADODB.connection qui a été instancié plutôt. Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur de
167,
et la table UTILCARACT existe aussi. mais ce qui me surprend c'est que le dernier insert qui devrait passer échoue et Sql me renvoie une violation de clé. et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter la transaction et tout ce qui a été éxecuté entre l'ouverture de transaction
et
ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon code !) Je pensais que le CREATE TABLE encadré par un on error resume next ne poserait pas de soucis mais si ! et à un niveau qui ne me permet pas de savoir que ma transaction passe à la trappe ! merci de m'expliquer le mécanisme sous jacent qui explique tout et comment me prémunir de l'echec d'une transaction. Je sais que je peux tester l'existence de la table, mais sera-ce la même chose avec un DROP FUNCTION sur une fonction qui n'existe pas.
merci de m'avoir lu
Jean-Maurice
Jean-Maurice
merci de ta réponse.
Je comprends bien que le On error resume next s'occupe de VB uniquement, mais ce que je ne comprends pas, c'est que le CREATE TABLE échouant, les précédentes modifications apportées à la base sont annulées. Ce n'est pas le cas quand à la place du CREATE TABLE je passe un ordre SQL du type INSERT INTO sur une table qui provoque une erreur de doublon. L'erreur est bien remontée du côté de VB, mais le premier DELETE est toujours pris en compte à ce moment-là, de sorte que le dernier INSERT passe aussi, cela justifie bien l'utilisation du On error resume next pour ne pas prendre en compte tel lot de commandes SQL. Quelle différence SQL fait-il donc entre ces 2 types d'erreurs: celle du CREATE TABLE et celle d'un INSERT ?
Jean-Maurice
"Patrice" a écrit dans le message de news:%23n%
On Error Resume Next est une instruction VB et n'a rien à voir avec les transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe néanmoins). Du point de vue de SQL, l'erreur existe bien !!!
Je pense que le plus simple est de tester l'existence de la table.
J'aurais
aussi tendance à ne pas mélanger les insertions et le DDL et eslon le cas peut-être à créer la table en permanence et non pas en fonction des besoins...
Patrice
--
"Jean-Maurice" a écrit dans le message de news:41c865e9$0$32154$ > bonjour, > je développe sous visual basic 6, sp6 et j'ai une question sur les > transactions: > j'ai écrit le code suivant: > On Error GoTo rb > BeginTrans > ExecuteSql "Delete from PARAMAPP where IDPARAM7" > On Error Resume Next > ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL, > IDCARACT int NOT NULL) ON [PRIMARY]" > On Error GoTo rb > ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)" > CommitTrans > Exit Function > rb: > RollBack > Exit Function > > les fonctions ne font rien d'autres que d'executer les méthodes
begintrans
> et execute de l'objet ADODB.connection qui a été instancié plutôt. > Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur de 167, > et la table UTILCARACT existe aussi. > mais ce qui me surprend c'est que le dernier insert qui devrait passer > échoue et Sql me renvoie une violation de clé. > et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter
la
> transaction et tout ce qui a été éxecuté entre l'ouverture de
transaction
et > ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon code
!)
> Je pensais que le CREATE TABLE encadré par un on error resume next ne > poserait pas de soucis mais si ! et à un niveau qui ne me permet pas de > savoir que ma transaction passe à la trappe ! > merci de m'expliquer le mécanisme sous jacent qui explique tout et
comment
> me prémunir de l'echec d'une transaction. > Je sais que je peux tester l'existence de la table, mais sera-ce la même > chose avec un DROP FUNCTION sur une fonction qui n'existe pas. > > merci de m'avoir lu > > Jean-Maurice > >
merci de ta réponse.
Je comprends bien que le On error resume next s'occupe de VB uniquement,
mais ce que je ne comprends pas, c'est que le CREATE TABLE échouant, les
précédentes modifications apportées à la base sont annulées.
Ce n'est pas le cas quand à la place du CREATE TABLE je passe un ordre SQL
du type INSERT INTO sur une table qui provoque une erreur de doublon.
L'erreur est bien remontée du côté de VB, mais le premier DELETE est
toujours pris en compte à ce moment-là, de sorte que le dernier INSERT passe
aussi, cela justifie bien l'utilisation du On error resume next pour ne pas
prendre en compte tel lot de commandes SQL.
Quelle différence SQL fait-il donc entre ces 2 types d'erreurs: celle du
CREATE TABLE et celle d'un INSERT ?
Jean-Maurice
"Patrice" <nobody@nowhere.com> a écrit dans le message de
news:%23n%23P1845EHA.1400@TK2MSFTNGP11.phx.gbl...
On Error Resume Next est une instruction VB et n'a rien à voir avec les
transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe
néanmoins). Du point de vue de SQL, l'erreur existe bien !!!
Je pense que le plus simple est de tester l'existence de la table.
J'aurais
aussi tendance à ne pas mélanger les insertions et le DDL et eslon le cas
peut-être à créer la table en permanence et non pas en fonction des
besoins...
Patrice
--
"Jean-Maurice" <jmclochard@wanadoo.fr> a écrit dans le message de
news:41c865e9$0$32154$8fcfb975@news.wanadoo.fr...
> bonjour,
> je développe sous visual basic 6, sp6 et j'ai une question sur les
> transactions:
> j'ai écrit le code suivant:
> On Error GoTo rb
> BeginTrans
> ExecuteSql "Delete from PARAMAPP where IDPARAM7"
> On Error Resume Next
> ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL,
> IDCARACT int NOT NULL) ON [PRIMARY]"
> On Error GoTo rb
> ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)"
> CommitTrans
> Exit Function
> rb:
> RollBack
> Exit Function
>
> les fonctions ne font rien d'autres que d'executer les méthodes
begintrans
> et execute de l'objet ADODB.connection qui a été instancié plutôt.
> Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur de
167,
> et la table UTILCARACT existe aussi.
> mais ce qui me surprend c'est que le dernier insert qui devrait passer
> échoue et Sql me renvoie une violation de clé.
> et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter
la
> transaction et tout ce qui a été éxecuté entre l'ouverture de
transaction
et
> ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon code
!)
> Je pensais que le CREATE TABLE encadré par un on error resume next ne
> poserait pas de soucis mais si ! et à un niveau qui ne me permet pas de
> savoir que ma transaction passe à la trappe !
> merci de m'expliquer le mécanisme sous jacent qui explique tout et
comment
> me prémunir de l'echec d'une transaction.
> Je sais que je peux tester l'existence de la table, mais sera-ce la même
> chose avec un DROP FUNCTION sur une fonction qui n'existe pas.
>
> merci de m'avoir lu
>
> Jean-Maurice
>
>
Je comprends bien que le On error resume next s'occupe de VB uniquement, mais ce que je ne comprends pas, c'est que le CREATE TABLE échouant, les précédentes modifications apportées à la base sont annulées. Ce n'est pas le cas quand à la place du CREATE TABLE je passe un ordre SQL du type INSERT INTO sur une table qui provoque une erreur de doublon. L'erreur est bien remontée du côté de VB, mais le premier DELETE est toujours pris en compte à ce moment-là, de sorte que le dernier INSERT passe aussi, cela justifie bien l'utilisation du On error resume next pour ne pas prendre en compte tel lot de commandes SQL. Quelle différence SQL fait-il donc entre ces 2 types d'erreurs: celle du CREATE TABLE et celle d'un INSERT ?
Jean-Maurice
"Patrice" a écrit dans le message de news:%23n%
On Error Resume Next est une instruction VB et n'a rien à voir avec les transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe néanmoins). Du point de vue de SQL, l'erreur existe bien !!!
Je pense que le plus simple est de tester l'existence de la table.
J'aurais
aussi tendance à ne pas mélanger les insertions et le DDL et eslon le cas peut-être à créer la table en permanence et non pas en fonction des besoins...
Patrice
--
"Jean-Maurice" a écrit dans le message de news:41c865e9$0$32154$ > bonjour, > je développe sous visual basic 6, sp6 et j'ai une question sur les > transactions: > j'ai écrit le code suivant: > On Error GoTo rb > BeginTrans > ExecuteSql "Delete from PARAMAPP where IDPARAM7" > On Error Resume Next > ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL, > IDCARACT int NOT NULL) ON [PRIMARY]" > On Error GoTo rb > ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)" > CommitTrans > Exit Function > rb: > RollBack > Exit Function > > les fonctions ne font rien d'autres que d'executer les méthodes
begintrans
> et execute de l'objet ADODB.connection qui a été instancié plutôt. > Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur de 167, > et la table UTILCARACT existe aussi. > mais ce qui me surprend c'est que le dernier insert qui devrait passer > échoue et Sql me renvoie une violation de clé. > et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter
la
> transaction et tout ce qui a été éxecuté entre l'ouverture de
transaction
et > ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon code
!)
> Je pensais que le CREATE TABLE encadré par un on error resume next ne > poserait pas de soucis mais si ! et à un niveau qui ne me permet pas de > savoir que ma transaction passe à la trappe ! > merci de m'expliquer le mécanisme sous jacent qui explique tout et
comment
> me prémunir de l'echec d'une transaction. > Je sais que je peux tester l'existence de la table, mais sera-ce la même > chose avec un DROP FUNCTION sur une fonction qui n'existe pas. > > merci de m'avoir lu > > Jean-Maurice > >
Jean-Maurice
ça y est, j'y suis: sur http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=sommaire je lis: "Saviez-vous qu'aucun ordre DDL ne peut être transactionné ?" je ne le savais pas.
"Jean-Maurice" a écrit dans le message de news:41c9408d$0$32119$
merci de ta réponse.
Je comprends bien que le On error resume next s'occupe de VB uniquement, mais ce que je ne comprends pas, c'est que le CREATE TABLE échouant, les précédentes modifications apportées à la base sont annulées. Ce n'est pas le cas quand à la place du CREATE TABLE je passe un ordre SQL du type INSERT INTO sur une table qui provoque une erreur de doublon. L'erreur est bien remontée du côté de VB, mais le premier DELETE est toujours pris en compte à ce moment-là, de sorte que le dernier INSERT
passe
aussi, cela justifie bien l'utilisation du On error resume next pour ne
pas
prendre en compte tel lot de commandes SQL. Quelle différence SQL fait-il donc entre ces 2 types d'erreurs: celle du CREATE TABLE et celle d'un INSERT ?
Jean-Maurice
"Patrice" a écrit dans le message de news:%23n% > On Error Resume Next est une instruction VB et n'a rien à voir avec les > transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe > néanmoins). Du point de vue de SQL, l'erreur existe bien !!! > > Je pense que le plus simple est de tester l'existence de la table. J'aurais > aussi tendance à ne pas mélanger les insertions et le DDL et eslon le
cas
> peut-être à créer la table en permanence et non pas en fonction des > besoins... > > Patrice > > -- > > "Jean-Maurice" a écrit dans le message de > news:41c865e9$0$32154$ > > bonjour, > > je développe sous visual basic 6, sp6 et j'ai une question sur les > > transactions: > > j'ai écrit le code suivant: > > On Error GoTo rb > > BeginTrans > > ExecuteSql "Delete from PARAMAPP where IDPARAM7" > > On Error Resume Next > > ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL, > > IDCARACT int NOT NULL) ON [PRIMARY]" > > On Error GoTo rb > > ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)" > > CommitTrans > > Exit Function > > rb: > > RollBack > > Exit Function > > > > les fonctions ne font rien d'autres que d'executer les méthodes begintrans > > et execute de l'objet ADODB.connection qui a été instancié plutôt. > > Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur
de
> 167, > > et la table UTILCARACT existe aussi. > > mais ce qui me surprend c'est que le dernier insert qui devrait passer > > échoue et Sql me renvoie une violation de clé. > > et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter la > > transaction et tout ce qui a été éxecuté entre l'ouverture de transaction > et > > ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon
code
!) > > Je pensais que le CREATE TABLE encadré par un on error resume next ne > > poserait pas de soucis mais si ! et à un niveau qui ne me permet pas
de
> > savoir que ma transaction passe à la trappe ! > > merci de m'expliquer le mécanisme sous jacent qui explique tout et comment > > me prémunir de l'echec d'une transaction. > > Je sais que je peux tester l'existence de la table, mais sera-ce la
même
> > chose avec un DROP FUNCTION sur une fonction qui n'existe pas. > > > > merci de m'avoir lu > > > > Jean-Maurice > > > > > >
ça y est, j'y suis:
sur http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=sommaire
je lis: "Saviez-vous qu'aucun ordre DDL ne peut être transactionné ?"
je ne le savais pas.
"Jean-Maurice" <jmclochard@wanadoo.fr> a écrit dans le message de
news:41c9408d$0$32119$8fcfb975@news.wanadoo.fr...
merci de ta réponse.
Je comprends bien que le On error resume next s'occupe de VB uniquement,
mais ce que je ne comprends pas, c'est que le CREATE TABLE échouant, les
précédentes modifications apportées à la base sont annulées.
Ce n'est pas le cas quand à la place du CREATE TABLE je passe un ordre SQL
du type INSERT INTO sur une table qui provoque une erreur de doublon.
L'erreur est bien remontée du côté de VB, mais le premier DELETE est
toujours pris en compte à ce moment-là, de sorte que le dernier INSERT
passe
aussi, cela justifie bien l'utilisation du On error resume next pour ne
pas
prendre en compte tel lot de commandes SQL.
Quelle différence SQL fait-il donc entre ces 2 types d'erreurs: celle du
CREATE TABLE et celle d'un INSERT ?
Jean-Maurice
"Patrice" <nobody@nowhere.com> a écrit dans le message de
news:%23n%23P1845EHA.1400@TK2MSFTNGP11.phx.gbl...
> On Error Resume Next est une instruction VB et n'a rien à voir avec les
> transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe
> néanmoins). Du point de vue de SQL, l'erreur existe bien !!!
>
> Je pense que le plus simple est de tester l'existence de la table.
J'aurais
> aussi tendance à ne pas mélanger les insertions et le DDL et eslon le
cas
> peut-être à créer la table en permanence et non pas en fonction des
> besoins...
>
> Patrice
>
> --
>
> "Jean-Maurice" <jmclochard@wanadoo.fr> a écrit dans le message de
> news:41c865e9$0$32154$8fcfb975@news.wanadoo.fr...
> > bonjour,
> > je développe sous visual basic 6, sp6 et j'ai une question sur les
> > transactions:
> > j'ai écrit le code suivant:
> > On Error GoTo rb
> > BeginTrans
> > ExecuteSql "Delete from PARAMAPP where IDPARAM7"
> > On Error Resume Next
> > ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL,
> > IDCARACT int NOT NULL) ON [PRIMARY]"
> > On Error GoTo rb
> > ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)"
> > CommitTrans
> > Exit Function
> > rb:
> > RollBack
> > Exit Function
> >
> > les fonctions ne font rien d'autres que d'executer les méthodes
begintrans
> > et execute de l'objet ADODB.connection qui a été instancié plutôt.
> > Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur
de
> 167,
> > et la table UTILCARACT existe aussi.
> > mais ce qui me surprend c'est que le dernier insert qui devrait passer
> > échoue et Sql me renvoie une violation de clé.
> > et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter
la
> > transaction et tout ce qui a été éxecuté entre l'ouverture de
transaction
> et
> > ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon
code
!)
> > Je pensais que le CREATE TABLE encadré par un on error resume next ne
> > poserait pas de soucis mais si ! et à un niveau qui ne me permet pas
de
> > savoir que ma transaction passe à la trappe !
> > merci de m'expliquer le mécanisme sous jacent qui explique tout et
comment
> > me prémunir de l'echec d'une transaction.
> > Je sais que je peux tester l'existence de la table, mais sera-ce la
même
> > chose avec un DROP FUNCTION sur une fonction qui n'existe pas.
> >
> > merci de m'avoir lu
> >
> > Jean-Maurice
> >
> >
>
>
ça y est, j'y suis: sur http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=sommaire je lis: "Saviez-vous qu'aucun ordre DDL ne peut être transactionné ?" je ne le savais pas.
"Jean-Maurice" a écrit dans le message de news:41c9408d$0$32119$
merci de ta réponse.
Je comprends bien que le On error resume next s'occupe de VB uniquement, mais ce que je ne comprends pas, c'est que le CREATE TABLE échouant, les précédentes modifications apportées à la base sont annulées. Ce n'est pas le cas quand à la place du CREATE TABLE je passe un ordre SQL du type INSERT INTO sur une table qui provoque une erreur de doublon. L'erreur est bien remontée du côté de VB, mais le premier DELETE est toujours pris en compte à ce moment-là, de sorte que le dernier INSERT
passe
aussi, cela justifie bien l'utilisation du On error resume next pour ne
pas
prendre en compte tel lot de commandes SQL. Quelle différence SQL fait-il donc entre ces 2 types d'erreurs: celle du CREATE TABLE et celle d'un INSERT ?
Jean-Maurice
"Patrice" a écrit dans le message de news:%23n% > On Error Resume Next est une instruction VB et n'a rien à voir avec les > transactions. Elle demande juste à VB d'ignorer l'erreur (qui existe > néanmoins). Du point de vue de SQL, l'erreur existe bien !!! > > Je pense que le plus simple est de tester l'existence de la table. J'aurais > aussi tendance à ne pas mélanger les insertions et le DDL et eslon le
cas
> peut-être à créer la table en permanence et non pas en fonction des > besoins... > > Patrice > > -- > > "Jean-Maurice" a écrit dans le message de > news:41c865e9$0$32154$ > > bonjour, > > je développe sous visual basic 6, sp6 et j'ai une question sur les > > transactions: > > j'ai écrit le code suivant: > > On Error GoTo rb > > BeginTrans > > ExecuteSql "Delete from PARAMAPP where IDPARAM7" > > On Error Resume Next > > ExecuteSql "CREATE TABLE dbo.UTILCARACT (IDUTIL int NOT NULL, > > IDCARACT int NOT NULL) ON [PRIMARY]" > > On Error GoTo rb > > ExecuteSql "Insert Into PARAMAPP (IDPARAM) values (167)" > > CommitTrans > > Exit Function > > rb: > > RollBack > > Exit Function > > > > les fonctions ne font rien d'autres que d'executer les méthodes begintrans > > et execute de l'objet ADODB.connection qui a été instancié plutôt. > > Au tout départ, j'ai un enregistrement dans PARAMAPP avec une valeur
de
> 167, > > et la table UTILCARACT existe aussi. > > mais ce qui me surprend c'est que le dernier insert qui devrait passer > > échoue et Sql me renvoie une violation de clé. > > et la raison est que l'ordre "CREATE TABLE" en échouant fait s'arréter la > > transaction et tout ce qui a été éxecuté entre l'ouverture de transaction > et > > ce CREATE TABLE est "rollbacké". (Je n'ai mis qu'une partie de mon
code
!) > > Je pensais que le CREATE TABLE encadré par un on error resume next ne > > poserait pas de soucis mais si ! et à un niveau qui ne me permet pas
de
> > savoir que ma transaction passe à la trappe ! > > merci de m'expliquer le mécanisme sous jacent qui explique tout et comment > > me prémunir de l'echec d'une transaction. > > Je sais que je peux tester l'existence de la table, mais sera-ce la
même
> > chose avec un DROP FUNCTION sur une fonction qui n'existe pas. > > > > merci de m'avoir lu > > > > Jean-Maurice > > > > > >
