J'ai des traitements de données qui sont développés en T-Sql, dans des
procédures stockées,
Je les exécute à partir d'ADO.
Set conn = new adodb.connection
Conn.open connectionstring
Conn.execute("mySP @param1, @param2, [...]")
....
Par cette méthode, le script me rend la main qu'à la fin du traitement SQL.
Je souhaiterai les lancer de façon asynchrone. (processus autonome)
, à partir d'un client VB, XL, ASP, ou WSH...
L'idéal serait de suivre l'état d'avancement.
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
Sylvain Lafontaine
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui, travaille toujours de manière synchrone avec le SQL-Server car il ne peut pas briser une connection et rétablir ensuite celle-ci sans que les données/états associées à cette connection du côté du SQL-Server ne soient perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez pas faire ce que vous voulez avec le multithread de VB, alors vous ne pouvez pas le faire avec ADO.
S. L.
"JeeCee" wrote in message news:cdohrd$16tb$
Bonjour,
J'ai des traitements de données qui sont développés en T-Sql, dans des procédures stockées,
Je les exécute à partir d'ADO.
Set conn = new adodb.connection Conn.open connectionstring Conn.execute("mySP @param1, @param2, [...]") .... Par cette méthode, le script me rend la main qu'à la fin du traitement
SQL.
Je souhaiterai les lancer de façon asynchrone. (processus autonome) , à partir d'un client VB, XL, ASP, ou WSH... L'idéal serait de suivre l'état d'avancement.
Quel est la méthode ?
Merci de votre aide.
JeeCee
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne
supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui
peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui,
travaille toujours de manière synchrone avec le SQL-Server car il ne peut
pas briser une connection et rétablir ensuite celle-ci sans que les
données/états associées à cette connection du côté du SQL-Server ne soient
perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant
un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez
pas faire ce que vous voulez avec le multithread de VB, alors vous ne pouvez
pas le faire avec ADO.
S. L.
"JeeCee" <nospam@nospam.fr> wrote in message
news:cdohrd$16tb$1@biggoron.nerim.net...
Bonjour,
J'ai des traitements de données qui sont développés en T-Sql, dans des
procédures stockées,
Je les exécute à partir d'ADO.
Set conn = new adodb.connection
Conn.open connectionstring
Conn.execute("mySP @param1, @param2, [...]")
....
Par cette méthode, le script me rend la main qu'à la fin du traitement
SQL.
Je souhaiterai les lancer de façon asynchrone. (processus autonome)
, à partir d'un client VB, XL, ASP, ou WSH...
L'idéal serait de suivre l'état d'avancement.
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui, travaille toujours de manière synchrone avec le SQL-Server car il ne peut pas briser une connection et rétablir ensuite celle-ci sans que les données/états associées à cette connection du côté du SQL-Server ne soient perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez pas faire ce que vous voulez avec le multithread de VB, alors vous ne pouvez pas le faire avec ADO.
S. L.
"JeeCee" wrote in message news:cdohrd$16tb$
Bonjour,
J'ai des traitements de données qui sont développés en T-Sql, dans des procédures stockées,
Je les exécute à partir d'ADO.
Set conn = new adodb.connection Conn.open connectionstring Conn.execute("mySP @param1, @param2, [...]") .... Par cette méthode, le script me rend la main qu'à la fin du traitement
SQL.
Je souhaiterai les lancer de façon asynchrone. (processus autonome) , à partir d'un client VB, XL, ASP, ou WSH... L'idéal serait de suivre l'état d'avancement.
Quel est la méthode ?
Merci de votre aide.
JeeCee
JeeCee
Merci de votre réponse.
En passant sous DotNet (Asp.Net ou VB.Net) pensez-vous que je puisse y arriver ?
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui, travaille toujours de manière synchrone avec le SQL-Server car il ne peut pas briser une connection et rétablir ensuite celle-ci sans que les données/états associées à cette connection du côté du SQL-Server ne soient perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez pas faire ce que vous voulez avec le multithread de VB, alors vous ne
pouvez
pas le faire avec ADO.
S. L.
"JeeCee" wrote in message news:cdohrd$16tb$ > Bonjour, > > J'ai des traitements de données qui sont développés en T-Sql, dans des > procédures stockées, > > Je les exécute à partir d'ADO. > > Set conn = new adodb.connection > Conn.open connectionstring > Conn.execute("mySP @param1, @param2, [...]") > .... > Par cette méthode, le script me rend la main qu'à la fin du traitement SQL. > > Je souhaiterai les lancer de façon asynchrone. (processus autonome) > , à partir d'un client VB, XL, ASP, ou WSH... > L'idéal serait de suivre l'état d'avancement. > > Quel est la méthode ? > > Merci de votre aide. > > JeeCee > > > > > > > > > > >
Merci de votre réponse.
En passant sous DotNet (Asp.Net ou VB.Net)
pensez-vous que je puisse y arriver ?
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:eZNzgTAcEHA.1652@TK2MSFTNGP09.phx.gbl...
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne
supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui
peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui,
travaille toujours de manière synchrone avec le SQL-Server car il ne peut
pas briser une connection et rétablir ensuite celle-ci sans que les
données/états associées à cette connection du côté du SQL-Server ne soient
perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant
un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez
pas faire ce que vous voulez avec le multithread de VB, alors vous ne
pouvez
pas le faire avec ADO.
S. L.
"JeeCee" <nospam@nospam.fr> wrote in message
news:cdohrd$16tb$1@biggoron.nerim.net...
> Bonjour,
>
> J'ai des traitements de données qui sont développés en T-Sql, dans des
> procédures stockées,
>
> Je les exécute à partir d'ADO.
>
> Set conn = new adodb.connection
> Conn.open connectionstring
> Conn.execute("mySP @param1, @param2, [...]")
> ....
> Par cette méthode, le script me rend la main qu'à la fin du traitement
SQL.
>
> Je souhaiterai les lancer de façon asynchrone. (processus autonome)
> , à partir d'un client VB, XL, ASP, ou WSH...
> L'idéal serait de suivre l'état d'avancement.
>
> Quel est la méthode ?
>
> Merci de votre aide.
>
> JeeCee
>
>
>
>
>
>
>
>
>
>
>
En passant sous DotNet (Asp.Net ou VB.Net) pensez-vous que je puisse y arriver ?
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui, travaille toujours de manière synchrone avec le SQL-Server car il ne peut pas briser une connection et rétablir ensuite celle-ci sans que les données/états associées à cette connection du côté du SQL-Server ne soient perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez pas faire ce que vous voulez avec le multithread de VB, alors vous ne
pouvez
pas le faire avec ADO.
S. L.
"JeeCee" wrote in message news:cdohrd$16tb$ > Bonjour, > > J'ai des traitements de données qui sont développés en T-Sql, dans des > procédures stockées, > > Je les exécute à partir d'ADO. > > Set conn = new adodb.connection > Conn.open connectionstring > Conn.execute("mySP @param1, @param2, [...]") > .... > Par cette méthode, le script me rend la main qu'à la fin du traitement SQL. > > Je souhaiterai les lancer de façon asynchrone. (processus autonome) > , à partir d'un client VB, XL, ASP, ou WSH... > L'idéal serait de suivre l'état d'avancement. > > Quel est la méthode ? > > Merci de votre aide. > > JeeCee > > > > > > > > > > >
JeeCee
En fait, c'est possible.
J'ai fini par trouver de la documentation sur le site MSDN de Microsoft.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui, travaille toujours de manière synchrone avec le SQL-Server car il ne peut pas briser une connection et rétablir ensuite celle-ci sans que les données/états associées à cette connection du côté du SQL-Server ne soient perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez pas faire ce que vous voulez avec le multithread de VB, alors vous ne
pouvez
pas le faire avec ADO.
S. L.
"JeeCee" wrote in message news:cdohrd$16tb$ > Bonjour, > > J'ai des traitements de données qui sont développés en T-Sql, dans des > procédures stockées, > > Je les exécute à partir d'ADO. > > Set conn = new adodb.connection > Conn.open connectionstring > Conn.execute("mySP @param1, @param2, [...]") > .... > Par cette méthode, le script me rend la main qu'à la fin du traitement SQL. > > Je souhaiterai les lancer de façon asynchrone. (processus autonome) > , à partir d'un client VB, XL, ASP, ou WSH... > L'idéal serait de suivre l'état d'avancement. > > Quel est la méthode ? > > Merci de votre aide. > > JeeCee > > > > > > > > > > >
En fait, c'est possible.
J'ai fini par trouver de la documentation sur le site MSDN de Microsoft.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:eZNzgTAcEHA.1652@TK2MSFTNGP09.phx.gbl...
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne
supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui
peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui,
travaille toujours de manière synchrone avec le SQL-Server car il ne peut
pas briser une connection et rétablir ensuite celle-ci sans que les
données/états associées à cette connection du côté du SQL-Server ne soient
perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant
un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez
pas faire ce que vous voulez avec le multithread de VB, alors vous ne
pouvez
pas le faire avec ADO.
S. L.
"JeeCee" <nospam@nospam.fr> wrote in message
news:cdohrd$16tb$1@biggoron.nerim.net...
> Bonjour,
>
> J'ai des traitements de données qui sont développés en T-Sql, dans des
> procédures stockées,
>
> Je les exécute à partir d'ADO.
>
> Set conn = new adodb.connection
> Conn.open connectionstring
> Conn.execute("mySP @param1, @param2, [...]")
> ....
> Par cette méthode, le script me rend la main qu'à la fin du traitement
SQL.
>
> Je souhaiterai les lancer de façon asynchrone. (processus autonome)
> , à partir d'un client VB, XL, ASP, ou WSH...
> L'idéal serait de suivre l'état d'avancement.
>
> Quel est la méthode ?
>
> Merci de votre aide.
>
> JeeCee
>
>
>
>
>
>
>
>
>
>
>
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne supportent pas le multi-thread.
Quant à VB, notez bien que ce n'est que les threads du côté client qui peuvent travailler en mode asynchrone avec ADO. L'objet Connection, lui, travaille toujours de manière synchrone avec le SQL-Server car il ne peut pas briser une connection et rétablir ensuite celle-ci sans que les données/états associées à cette connection du côté du SQL-Server ne soient perdues.
Vous pouvez facilement émuler le comportement asynchrone sous VB en créant un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne pouvez pas faire ce que vous voulez avec le multithread de VB, alors vous ne
pouvez
pas le faire avec ADO.
S. L.
"JeeCee" wrote in message news:cdohrd$16tb$ > Bonjour, > > J'ai des traitements de données qui sont développés en T-Sql, dans des > procédures stockées, > > Je les exécute à partir d'ADO. > > Set conn = new adodb.connection > Conn.open connectionstring > Conn.execute("mySP @param1, @param2, [...]") > .... > Par cette méthode, le script me rend la main qu'à la fin du traitement SQL. > > Je souhaiterai les lancer de façon asynchrone. (processus autonome) > , à partir d'un client VB, XL, ASP, ou WSH... > L'idéal serait de suivre l'état d'avancement. > > Quel est la méthode ? > > Merci de votre aide. > > JeeCee > > > > > > > > > > >
Sylvain Lafontaine
Oh, je n'ai pas dit que c'était impossible mais que cela exigeait un environnement multi-thread: ADO vous libère de la tâche de devoir créer vous-même le thread secondaire requis; avec tous les avantages mais aussi tous les inconvénients associés. Si vous commettez une erreur, vous allez vous retrouver avec une application pratiquement impossible à débogguer; cela même avec le déboggeur.
Quant à l'ASP, cela ne supporte pas le multi-thread; c'en est donc exclu. Vous pouvez toujours essayer de créer un contrôle Active-X en VB avec du multi-thread à l'intérieur mais je ne vois pas en quoi cela pourrait être utile dans une page ASP.
Pour ce qui est de suivre l'état d'avancement d'une tâche, vous seriez probablement mieux de stocker un indice quelconque dans une table et d'en suivre la trace. Cependant, même dans ce cas, si vous lancer la job à partir d'une connection ADO, celle-ci doit être maintenue; sinon la job sera automatiquement interrompue par SQL-Server. Si vous voulez avoir une job ou un service qui roule de façon indépendante sur le SQL-Server, ceux-ci doivent être lancés directement sur le serveur - comme par exemple avec DTS et le Schéduleur - et non pas via une connection ADO.
S. L.
"JeeCee" wrote in message news:41003078$0$26043$
En fait, c'est possible.
J'ai fini par trouver de la documentation sur le site MSDN de Microsoft.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news: > Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne > supportent pas le multi-thread. > > Quant à VB, notez bien que ce n'est que les threads du côté client qui > peuvent travailler en mode asynchrone avec ADO. L'objet Connection,
lui,
> travaille toujours de manière synchrone avec le SQL-Server car il ne
peut
> pas briser une connection et rétablir ensuite celle-ci sans que les > données/états associées à cette connection du côté du SQL-Server ne
soient
> perdues. > > Vous pouvez facilement émuler le comportement asynchrone sous VB en
créant
> un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne
pouvez
> pas faire ce que vous voulez avec le multithread de VB, alors vous ne pouvez > pas le faire avec ADO. > > S. L. > > "JeeCee" wrote in message > news:cdohrd$16tb$ > > Bonjour, > > > > J'ai des traitements de données qui sont développés en T-Sql, dans des > > procédures stockées, > > > > Je les exécute à partir d'ADO. > > > > Set conn = new adodb.connection > > Conn.open connectionstring > > Conn.execute("mySP @param1, @param2, [...]") > > .... > > Par cette méthode, le script me rend la main qu'à la fin du traitement > SQL. > > > > Je souhaiterai les lancer de façon asynchrone. (processus autonome) > > , à partir d'un client VB, XL, ASP, ou WSH... > > L'idéal serait de suivre l'état d'avancement. > > > > Quel est la méthode ? > > > > Merci de votre aide. > > > > JeeCee > > > > > > > > > > > > > > > > > > > > > > > >
Oh, je n'ai pas dit que c'était impossible mais que cela exigeait un
environnement multi-thread: ADO vous libère de la tâche de devoir créer
vous-même le thread secondaire requis; avec tous les avantages mais aussi
tous les inconvénients associés. Si vous commettez une erreur, vous allez
vous retrouver avec une application pratiquement impossible à débogguer;
cela même avec le déboggeur.
Quant à l'ASP, cela ne supporte pas le multi-thread; c'en est donc exclu.
Vous pouvez toujours essayer de créer un contrôle Active-X en VB avec du
multi-thread à l'intérieur mais je ne vois pas en quoi cela pourrait être
utile dans une page ASP.
Pour ce qui est de suivre l'état d'avancement d'une tâche, vous seriez
probablement mieux de stocker un indice quelconque dans une table et d'en
suivre la trace. Cependant, même dans ce cas, si vous lancer la job à
partir d'une connection ADO, celle-ci doit être maintenue; sinon la job sera
automatiquement interrompue par SQL-Server. Si vous voulez avoir une job ou
un service qui roule de façon indépendante sur le SQL-Server, ceux-ci
doivent être lancés directement sur le serveur - comme par exemple avec DTS
et le Schéduleur - et non pas via une connection ADO.
S. L.
"JeeCee" <nospam@nospam> wrote in message
news:41003078$0$26043$626a14ce@news.free.fr...
En fait, c'est possible.
J'ai fini par trouver de la documentation sur le site MSDN de Microsoft.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:eZNzgTAcEHA.1652@TK2MSFTNGP09.phx.gbl...
> Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne
> supportent pas le multi-thread.
>
> Quant à VB, notez bien que ce n'est que les threads du côté client qui
> peuvent travailler en mode asynchrone avec ADO. L'objet Connection,
lui,
> travaille toujours de manière synchrone avec le SQL-Server car il ne
peut
> pas briser une connection et rétablir ensuite celle-ci sans que les
> données/états associées à cette connection du côté du SQL-Server ne
soient
> perdues.
>
> Vous pouvez facilement émuler le comportement asynchrone sous VB en
créant
> un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne
pouvez
> pas faire ce que vous voulez avec le multithread de VB, alors vous ne
pouvez
> pas le faire avec ADO.
>
> S. L.
>
> "JeeCee" <nospam@nospam.fr> wrote in message
> news:cdohrd$16tb$1@biggoron.nerim.net...
> > Bonjour,
> >
> > J'ai des traitements de données qui sont développés en T-Sql, dans des
> > procédures stockées,
> >
> > Je les exécute à partir d'ADO.
> >
> > Set conn = new adodb.connection
> > Conn.open connectionstring
> > Conn.execute("mySP @param1, @param2, [...]")
> > ....
> > Par cette méthode, le script me rend la main qu'à la fin du traitement
> SQL.
> >
> > Je souhaiterai les lancer de façon asynchrone. (processus autonome)
> > , à partir d'un client VB, XL, ASP, ou WSH...
> > L'idéal serait de suivre l'état d'avancement.
> >
> > Quel est la méthode ?
> >
> > Merci de votre aide.
> >
> > JeeCee
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
Oh, je n'ai pas dit que c'était impossible mais que cela exigeait un environnement multi-thread: ADO vous libère de la tâche de devoir créer vous-même le thread secondaire requis; avec tous les avantages mais aussi tous les inconvénients associés. Si vous commettez une erreur, vous allez vous retrouver avec une application pratiquement impossible à débogguer; cela même avec le déboggeur.
Quant à l'ASP, cela ne supporte pas le multi-thread; c'en est donc exclu. Vous pouvez toujours essayer de créer un contrôle Active-X en VB avec du multi-thread à l'intérieur mais je ne vois pas en quoi cela pourrait être utile dans une page ASP.
Pour ce qui est de suivre l'état d'avancement d'une tâche, vous seriez probablement mieux de stocker un indice quelconque dans une table et d'en suivre la trace. Cependant, même dans ce cas, si vous lancer la job à partir d'une connection ADO, celle-ci doit être maintenue; sinon la job sera automatiquement interrompue par SQL-Server. Si vous voulez avoir une job ou un service qui roule de façon indépendante sur le SQL-Server, ceux-ci doivent être lancés directement sur le serveur - comme par exemple avec DTS et le Schéduleur - et non pas via une connection ADO.
S. L.
"JeeCee" wrote in message news:41003078$0$26043$
En fait, c'est possible.
J'ai fini par trouver de la documentation sur le site MSDN de Microsoft.
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news: > Les scripts sous ASP et WSH sont toujours synchrones car ces hôtes ne > supportent pas le multi-thread. > > Quant à VB, notez bien que ce n'est que les threads du côté client qui > peuvent travailler en mode asynchrone avec ADO. L'objet Connection,
lui,
> travaille toujours de manière synchrone avec le SQL-Server car il ne
peut
> pas briser une connection et rétablir ensuite celle-ci sans que les > données/états associées à cette connection du côté du SQL-Server ne
soient
> perdues. > > Vous pouvez facilement émuler le comportement asynchrone sous VB en
créant
> un thread secondaire pour créer/manipuler l'objet ADO. Si vous ne
pouvez
> pas faire ce que vous voulez avec le multithread de VB, alors vous ne pouvez > pas le faire avec ADO. > > S. L. > > "JeeCee" wrote in message > news:cdohrd$16tb$ > > Bonjour, > > > > J'ai des traitements de données qui sont développés en T-Sql, dans des > > procédures stockées, > > > > Je les exécute à partir d'ADO. > > > > Set conn = new adodb.connection > > Conn.open connectionstring > > Conn.execute("mySP @param1, @param2, [...]") > > .... > > Par cette méthode, le script me rend la main qu'à la fin du traitement > SQL. > > > > Je souhaiterai les lancer de façon asynchrone. (processus autonome) > > , à partir d'un client VB, XL, ASP, ou WSH... > > L'idéal serait de suivre l'état d'avancement. > > > > Quel est la méthode ? > > > > Merci de votre aide. > > > > JeeCee > > > > > > > > > > > > > > > > > > > > > > > >
