Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces
requêtes sont par exemple exécutées dans des reccordsets (update ou
delete) après chaque action on test les erreurs grâce à la commande on
error goto qui est incluse avant. Comment peut on être sur que la
deuxième requête sera exécutée que lorsque la première sera finie?
Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces requêtes sont par exemple exécutées dans des reccordsets (update ou delete) après chaque action on test les erreurs grâce à la commande on error goto qui est incluse avant. Comment peut on être sur que la deuxième requête sera exécutée que lorsque la première sera finie?
J'espère être comphréensible
Cdt
thierry
soir, pas obligatoirement une transaction. Faite votre première requète, testez l'objet error si pas de broles retourné alors vous continuez ??? Attention, les transactions, c'est mieux avec que sans ;-) @+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
thierry was thinking very hard :
Ah que je m'explique :)
Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces
requêtes sont par exemple exécutées dans des reccordsets (update ou
delete) après chaque action on test les erreurs grâce à la commande on
error goto qui est incluse avant. Comment peut on être sur que la
deuxième requête sera exécutée que lorsque la première sera finie?
J'espère être comphréensible
Cdt
thierry
soir,
pas obligatoirement une transaction. Faite votre première requète,
testez l'objet error si pas de broles retourné alors vous continuez ???
Attention, les transactions, c'est mieux avec que sans ;-)
@+Quaz
--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces requêtes sont par exemple exécutées dans des reccordsets (update ou delete) après chaque action on test les erreurs grâce à la commande on error goto qui est incluse avant. Comment peut on être sur que la deuxième requête sera exécutée que lorsque la première sera finie?
J'espère être comphréensible
Cdt
thierry
soir, pas obligatoirement une transaction. Faite votre première requète, testez l'objet error si pas de broles retourné alors vous continuez ??? Attention, les transactions, c'est mieux avec que sans ;-) @+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
thierry
In article , says...
thierry was thinking very hard : > > Ah que je m'explique :) > > Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces > requêtes sont par exemple exécutées dans des reccordsets (update ou > delete) après chaque action on test les erreurs grâce à la commande on > error goto qui est incluse avant. Comment peut on être sur que la > deuxième requête sera exécutée que lorsque la première sera finie? > > J'espère être comphréensible > > Cdt > > thierry
soir, pas obligatoirement une transaction. Faite votre première requète, testez l'objet error si pas de broles retourné alors vous continuez ??? Attention, les transactions, c'est mieux avec que sans ;-) @+Quaz
pourriez vous m'en dire plus sur les tra&nsactions?
Merci par avance
In article <mn.985f7d4b7c8d3161.18602@yahoo.fr>, wild_riki.@yahoo.fr
says...
thierry was thinking very hard :
>
> Ah que je m'explique :)
>
> Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces
> requêtes sont par exemple exécutées dans des reccordsets (update ou
> delete) après chaque action on test les erreurs grâce à la commande on
> error goto qui est incluse avant. Comment peut on être sur que la
> deuxième requête sera exécutée que lorsque la première sera finie?
>
> J'espère être comphréensible
>
> Cdt
>
> thierry
soir,
pas obligatoirement une transaction. Faite votre première requète,
testez l'objet error si pas de broles retourné alors vous continuez ???
Attention, les transactions, c'est mieux avec que sans ;-)
@+Quaz
pourriez vous m'en dire plus sur les tra&nsactions?
thierry was thinking very hard : > > Ah que je m'explique :) > > Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces > requêtes sont par exemple exécutées dans des reccordsets (update ou > delete) après chaque action on test les erreurs grâce à la commande on > error goto qui est incluse avant. Comment peut on être sur que la > deuxième requête sera exécutée que lorsque la première sera finie? > > J'espère être comphréensible > > Cdt > > thierry
soir, pas obligatoirement une transaction. Faite votre première requète, testez l'objet error si pas de broles retourné alors vous continuez ??? Attention, les transactions, c'est mieux avec que sans ;-) @+Quaz
pourriez vous m'en dire plus sur les tra&nsactions?
Merci par avance
YannX
Les transactions : un HELP de ce mot dans ACCESS aide bien ! Et là http://groups.google.com/groups?q=YannX+transaction&hl=fr&lr=&selm=OhK2KJ0wEHA.2804%40TK2MSFTNGP14.phx.gbl&rnum=1 Voire sans doute sur www;developpez.com / SQL @+
"thierry" a écrit dans le message de news:
In article , says... > thierry was thinking very hard : > > > > Ah que je m'explique :) > > > > Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces > > requêtes sont par exemple exécutées dans des reccordsets (update ou > > delete) après chaque action on test les erreurs grâce à la commande on > > error goto qui est incluse avant. Comment peut on être sur que la > > deuxième requête sera exécutée que lorsque la première sera finie? > > > > J'espère être comphréensible > > > > Cdt > > > > thierry > > soir, > pas obligatoirement une transaction. Faite votre première requète, > testez l'objet error si pas de broles retourné alors vous continuez ??? > Attention, les transactions, c'est mieux avec que sans ;-) > @+Quaz > >
pourriez vous m'en dire plus sur les tra&nsactions?
Merci par avance
Les transactions : un HELP de ce mot dans ACCESS aide bien !
Et là
http://groups.google.com/groups?q=YannX+transaction&hl=fr&lr=&selm=OhK2KJ0wEHA.2804%40TK2MSFTNGP14.phx.gbl&rnum=1
Voire sans doute sur www;developpez.com / SQL
@+
"thierry" <titi@laposte.net> a écrit dans le message de
news:GFr.1c07bfdbc995760c9896dd@News.dial.oleane.com...
In article <mn.985f7d4b7c8d3161.18602@yahoo.fr>, wild_riki.@yahoo.fr
says...
> thierry was thinking very hard :
> >
> > Ah que je m'explique :)
> >
> > Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces
> > requêtes sont par exemple exécutées dans des reccordsets (update ou
> > delete) après chaque action on test les erreurs grâce à la commande on
> > error goto qui est incluse avant. Comment peut on être sur que la
> > deuxième requête sera exécutée que lorsque la première sera finie?
> >
> > J'espère être comphréensible
> >
> > Cdt
> >
> > thierry
>
> soir,
> pas obligatoirement une transaction. Faite votre première requète,
> testez l'objet error si pas de broles retourné alors vous continuez ???
> Attention, les transactions, c'est mieux avec que sans ;-)
> @+Quaz
>
>
pourriez vous m'en dire plus sur les tra&nsactions?
Les transactions : un HELP de ce mot dans ACCESS aide bien ! Et là http://groups.google.com/groups?q=YannX+transaction&hl=fr&lr=&selm=OhK2KJ0wEHA.2804%40TK2MSFTNGP14.phx.gbl&rnum=1 Voire sans doute sur www;developpez.com / SQL @+
"thierry" a écrit dans le message de news:
In article , says... > thierry was thinking very hard : > > > > Ah que je m'explique :) > > > > Imaginons que nous ayons 2 requêtes SQL à exécuter de suite. Ces > > requêtes sont par exemple exécutées dans des reccordsets (update ou > > delete) après chaque action on test les erreurs grâce à la commande on > > error goto qui est incluse avant. Comment peut on être sur que la > > deuxième requête sera exécutée que lorsque la première sera finie? > > > > J'espère être comphréensible > > > > Cdt > > > > thierry > > soir, > pas obligatoirement une transaction. Faite votre première requète, > testez l'objet error si pas de broles retourné alors vous continuez ??? > Attention, les transactions, c'est mieux avec que sans ;-) > @+Quaz > >
pourriez vous m'en dire plus sur les tra&nsactions?
