Je rédige un script afin de contrôler le nombre de lignes rapatriées par un
ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les bases,
l'autres pour les tables) et deux curseurs.
Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes
boucles while, j'ai le message d'erreur suivant, alors que la vérification de
la syntaxe passe bien :
Serveur : Msg 137, Niveau 15, État 1, Ligne 1
La variable '@NBLIGSCE' doit être déclarée.
WHILE ...
BEGIN
SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' +
@TABLE+ ')'
EXEC (@STR1)
...
Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le
contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela
s'applique-t-il également aux variables ? Comment contourner cette difficulté
?
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
BVesan
Bonjour, vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même... Une solution assez simple pour contourner le problème est de passer par une table de résultat
DECLARE @table_resultat TABLE(col1 int)
INSERT INTO @table_resultat EXECUTE (@STR1)
SELECT @NBLIGSCE = col1 FROM @table_resultat.
Benjamin
Bonjour,
vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à
moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même...
Une solution assez simple pour contourner le problème est de passer par une
table de résultat
Bonjour, vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même... Une solution assez simple pour contourner le problème est de passer par une table de résultat
DECLARE @table_resultat TABLE(col1 int)
INSERT INTO @table_resultat EXECUTE (@STR1)
SELECT @NBLIGSCE = col1 FROM @table_resultat.
Benjamin
Laurent Jordi
Salut,
Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant...
Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une fonction et je récupèrerais le résultat dans la variable...
@+
Laurent
"OokieDookie" a écrit dans le message de news:
Bonjour à tous,
Je rédige un script afin de contrôler le nombre de lignes rapatriées par un ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les bases, l'autres pour les tables) et deux curseurs.
Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes boucles while, j'ai le message d'erreur suivant, alors que la vérification de la syntaxe passe bien : Serveur : Msg 137, Niveau 15, État 1, Ligne 1 La variable '@NBLIGSCE' doit être déclarée.
WHILE ... BEGIN SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' + @TABLE+ ')' EXEC (@STR1)
...
Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela s'applique-t-il également aux variables ? Comment contourner cette difficulté ?
D'avance merci.
Salut,
Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être
utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant...
Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une
fonction et je récupèrerais le résultat dans la variable...
@+
Laurent
"OokieDookie" <sorrynospam@nowhere.com> a écrit dans le message de news:
423139B2-C95A-4522-A1DE-70E323EAA46E@microsoft.com...
Bonjour à tous,
Je rédige un script afin de contrôler le nombre de lignes rapatriées par
un
ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les
bases,
l'autres pour les tables) et deux curseurs.
Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes
boucles while, j'ai le message d'erreur suivant, alors que la vérification
de
la syntaxe passe bien :
Serveur : Msg 137, Niveau 15, État 1, Ligne 1
La variable '@NBLIGSCE' doit être déclarée.
WHILE ...
BEGIN
SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' +
@TABLE+ ')'
EXEC (@STR1)
...
Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le
contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela
s'applique-t-il également aux variables ? Comment contourner cette
difficulté
?
Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant...
Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une fonction et je récupèrerais le résultat dans la variable...
@+
Laurent
"OokieDookie" a écrit dans le message de news:
Bonjour à tous,
Je rédige un script afin de contrôler le nombre de lignes rapatriées par un ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les bases, l'autres pour les tables) et deux curseurs.
Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes boucles while, j'ai le message d'erreur suivant, alors que la vérification de la syntaxe passe bien : Serveur : Msg 137, Niveau 15, État 1, Ligne 1 La variable '@NBLIGSCE' doit être déclarée.
WHILE ... BEGIN SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' + @TABLE+ ')' EXEC (@STR1)
...
Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela s'applique-t-il également aux variables ? Comment contourner cette difficulté ?
D'avance merci.
OokieDookie
Merci de votre aide.
Désolé cependant, j'obtiens le message suivant : Impossible d'utiliser EXECUTE comme source lors de l'insertion dans une variable de table.
De plus, s'il faut passer par une table de résultat (idée par ailleurs très séduisante, il faudra que je gère trois colonnes (tablesql, nbligsce et nbligdesc), ce qui suppose donc l'utilisation de deux instructions EXEC lors de l'insertion de mes valeurs, ce qui apparemment n'est pas possible (ou alors j'ai raté quelque chose lors de l'implémentation de la table de résultat dans mon script).
Je n'aime pas beaucoup recourir à ce genre d'extrémités, mais si besoin je pourrais publier mon code (2 Ko, je ne sais pas si cela se fait sur ce newsgroup) ;)
Encore merci de votre aide
"BVesan" a écrit :
Bonjour, vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même... Une solution assez simple pour contourner le problème est de passer par une table de résultat
DECLARE @table_resultat TABLE(col1 int)
INSERT INTO @table_resultat EXECUTE (@STR1)
SELECT @NBLIGSCE = col1 FROM @table_resultat.
Benjamin
Merci de votre aide.
Désolé cependant, j'obtiens le message suivant :
Impossible d'utiliser EXECUTE comme source lors de l'insertion dans une
variable de table.
De plus, s'il faut passer par une table de résultat (idée par ailleurs très
séduisante, il faudra que je gère trois colonnes (tablesql, nbligsce et
nbligdesc), ce qui suppose donc l'utilisation de deux instructions EXEC lors
de l'insertion de mes valeurs, ce qui apparemment n'est pas possible (ou
alors j'ai raté quelque chose lors de l'implémentation de la table de
résultat dans mon script).
Je n'aime pas beaucoup recourir à ce genre d'extrémités, mais si besoin je
pourrais publier mon code (2 Ko, je ne sais pas si cela se fait sur ce
newsgroup) ;)
Encore merci de votre aide
"BVesan" a écrit :
Bonjour,
vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à
moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même...
Une solution assez simple pour contourner le problème est de passer par une
table de résultat
Désolé cependant, j'obtiens le message suivant : Impossible d'utiliser EXECUTE comme source lors de l'insertion dans une variable de table.
De plus, s'il faut passer par une table de résultat (idée par ailleurs très séduisante, il faudra que je gère trois colonnes (tablesql, nbligsce et nbligdesc), ce qui suppose donc l'utilisation de deux instructions EXEC lors de l'insertion de mes valeurs, ce qui apparemment n'est pas possible (ou alors j'ai raté quelque chose lors de l'implémentation de la table de résultat dans mon script).
Je n'aime pas beaucoup recourir à ce genre d'extrémités, mais si besoin je pourrais publier mon code (2 Ko, je ne sais pas si cela se fait sur ce newsgroup) ;)
Encore merci de votre aide
"BVesan" a écrit :
Bonjour, vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même... Une solution assez simple pour contourner le problème est de passer par une table de résultat
DECLARE @table_resultat TABLE(col1 int)
INSERT INTO @table_resultat EXECUTE (@STR1)
SELECT @NBLIGSCE = col1 FROM @table_resultat.
Benjamin
Laurent Jordi
Pourquoi ne pas utiliser les tables systèmes ? je suis certain que ces informations doivent être dispo quelque part... Il resterait juste à savoir où :)
@+
Genre select "Laurent Jordi" <laurent.jordi@(xxx)wanadoo.fr> a écrit dans le message de news:
Salut,
Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant...
Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une fonction et je récupèrerais le résultat dans la variable...
@+
Laurent
"OokieDookie" a écrit dans le message de news:
Bonjour à tous,
Je rédige un script afin de contrôler le nombre de lignes rapatriées par un ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les bases, l'autres pour les tables) et deux curseurs.
Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes boucles while, j'ai le message d'erreur suivant, alors que la vérification de la syntaxe passe bien : Serveur : Msg 137, Niveau 15, État 1, Ligne 1 La variable '@NBLIGSCE' doit être déclarée.
WHILE ... BEGIN SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' + @TABLE+ ')' EXEC (@STR1)
...
Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela s'applique-t-il également aux variables ? Comment contourner cette difficulté ?
D'avance merci.
Pourquoi ne pas utiliser les tables systèmes ? je suis certain que ces
informations doivent être dispo quelque part...
Il resterait juste à savoir où :)
@+
Genre select
"Laurent Jordi" <laurent.jordi@(xxx)wanadoo.fr> a écrit dans le message de
news: etUSQLIPGHA.2604@TK2MSFTNGP09.phx.gbl...
Salut,
Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être
utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant...
Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une
fonction et je récupèrerais le résultat dans la variable...
@+
Laurent
"OokieDookie" <sorrynospam@nowhere.com> a écrit dans le message de news:
423139B2-C95A-4522-A1DE-70E323EAA46E@microsoft.com...
Bonjour à tous,
Je rédige un script afin de contrôler le nombre de lignes rapatriées par
un
ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les
bases,
l'autres pour les tables) et deux curseurs.
Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes
boucles while, j'ai le message d'erreur suivant, alors que la
vérification de
la syntaxe passe bien :
Serveur : Msg 137, Niveau 15, État 1, Ligne 1
La variable '@NBLIGSCE' doit être déclarée.
WHILE ...
BEGIN
SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' +
@TABLE+ ')'
EXEC (@STR1)
...
Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le
contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela
s'applique-t-il également aux variables ? Comment contourner cette
difficulté
?
Pourquoi ne pas utiliser les tables systèmes ? je suis certain que ces informations doivent être dispo quelque part... Il resterait juste à savoir où :)
@+
Genre select "Laurent Jordi" <laurent.jordi@(xxx)wanadoo.fr> a écrit dans le message de news:
Salut,
Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant...
Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une fonction et je récupèrerais le résultat dans la variable...
@+
Laurent
"OokieDookie" a écrit dans le message de news:
Bonjour à tous,
Je rédige un script afin de contrôler le nombre de lignes rapatriées par un ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les bases, l'autres pour les tables) et deux curseurs.
Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes boucles while, j'ai le message d'erreur suivant, alors que la vérification de la syntaxe passe bien : Serveur : Msg 137, Niveau 15, État 1, Ligne 1 La variable '@NBLIGSCE' doit être déclarée.
WHILE ... BEGIN SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' + @TABLE+ ')' EXEC (@STR1)
...
Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela s'applique-t-il également aux variables ? Comment contourner cette difficulté ?
D'avance merci.
OokieDookie
Effectivement je suis entièrement d'accord. Disons simplement que j'essaie de me simplifier la vie dans un premier temps en prenant une liste de valeurs prédéfinies (établie à partir du systables d'une base exemple), je ne consolide qu'une partie des tables existantes et je ne peux les modifier (exploitation par un logiciel tiers).
"Laurent Jordi" a écrit :
Pourquoi ne pas utiliser les tables systèmes ? je suis certain que ces informations doivent être dispo quelque part... Il resterait juste à savoir où :)
@+
Genre select "Laurent Jordi" <laurent.jordi@(xxx)wanadoo.fr> a écrit dans le message de news: > Salut, > > Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être > utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant... > > Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une > fonction et je récupèrerais le résultat dans la variable... > > @+ > > Laurent > > > > "OokieDookie" a écrit dans le message de news: > >> Bonjour à tous, >> >> Je rédige un script afin de contrôler le nombre de lignes rapatriées par >> un >> ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les >> bases, >> l'autres pour les tables) et deux curseurs. >> >> Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes >> boucles while, j'ai le message d'erreur suivant, alors que la >> vérification de >> la syntaxe passe bien : >> Serveur : Msg 137, Niveau 15, État 1, Ligne 1 >> La variable '@NBLIGSCE' doit être déclarée. >> >> Pour faire bref, cela ressemble un peu à >> >> DECLARE @TABLE, @BDD, @NBLIGSCE, @NBLIGDESC, @STR1, @STR2.... >> >> DECLARE C CURSOR..... MESTABLES >> .. >> >> DECLARE D CURSOR.... MES BASES >> >> >> WHILE ... >> BEGIN >> SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' + >> @TABLE+ ')' >> EXEC (@STR1) >> >> ... >> >> >> Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le >> contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela >> s'applique-t-il également aux variables ? Comment contourner cette >> difficulté >> ? >> >> D'avance merci. >> > >
Effectivement je suis entièrement d'accord.
Disons simplement que j'essaie de me simplifier la vie dans un premier temps
en prenant une liste de valeurs prédéfinies (établie à partir du systables
d'une base exemple), je ne consolide qu'une partie des tables existantes et
je ne peux les modifier (exploitation par un logiciel tiers).
"Laurent Jordi" a écrit :
Pourquoi ne pas utiliser les tables systèmes ? je suis certain que ces
informations doivent être dispo quelque part...
Il resterait juste à savoir où :)
@+
Genre select
"Laurent Jordi" <laurent.jordi@(xxx)wanadoo.fr> a écrit dans le message de
news: etUSQLIPGHA.2604@TK2MSFTNGP09.phx.gbl...
> Salut,
>
> Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être
> utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant...
>
> Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une
> fonction et je récupèrerais le résultat dans la variable...
>
> @+
>
> Laurent
>
>
>
> "OokieDookie" <sorrynospam@nowhere.com> a écrit dans le message de news:
> 423139B2-C95A-4522-A1DE-70E323EAA46E@microsoft.com...
>> Bonjour à tous,
>>
>> Je rédige un script afin de contrôler le nombre de lignes rapatriées par
>> un
>> ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les
>> bases,
>> l'autres pour les tables) et deux curseurs.
>>
>> Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes
>> boucles while, j'ai le message d'erreur suivant, alors que la
>> vérification de
>> la syntaxe passe bien :
>> Serveur : Msg 137, Niveau 15, État 1, Ligne 1
>> La variable '@NBLIGSCE' doit être déclarée.
>>
>> Pour faire bref, cela ressemble un peu à
>>
>> DECLARE @TABLE, @BDD, @NBLIGSCE, @NBLIGDESC, @STR1, @STR2....
>>
>> DECLARE C CURSOR..... MESTABLES
>> ..
>>
>> DECLARE D CURSOR.... MES BASES
>>
>>
>> WHILE ...
>> BEGIN
>> SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' +
>> @TABLE+ ')'
>> EXEC (@STR1)
>>
>> ...
>>
>>
>> Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le
>> contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela
>> s'applique-t-il également aux variables ? Comment contourner cette
>> difficulté
>> ?
>>
>> D'avance merci.
>>
>
>
Effectivement je suis entièrement d'accord. Disons simplement que j'essaie de me simplifier la vie dans un premier temps en prenant une liste de valeurs prédéfinies (établie à partir du systables d'une base exemple), je ne consolide qu'une partie des tables existantes et je ne peux les modifier (exploitation par un logiciel tiers).
"Laurent Jordi" a écrit :
Pourquoi ne pas utiliser les tables systèmes ? je suis certain que ces informations doivent être dispo quelque part... Il resterait juste à savoir où :)
@+
Genre select "Laurent Jordi" <laurent.jordi@(xxx)wanadoo.fr> a écrit dans le message de news: > Salut, > > Pas sur d'avoir raison, mais les variable de ta proc ne peuvent pas être > utilisée dans EXEC qui s'exécute dans un espace mémoire indépendant... > > Si j'étais toi, je mettrais l'interrogation dynamique de la table dans une > fonction et je récupèrerais le résultat dans la variable... > > @+ > > Laurent > > > > "OokieDookie" a écrit dans le message de news: > >> Bonjour à tous, >> >> Je rédige un script afin de contrôler le nombre de lignes rapatriées par >> un >> ETL (effectué via DTS). Pour cela j'utilise deux tables (une pour les >> bases, >> l'autres pour les tables) et deux curseurs. >> >> Lorsque j'essaie d'affecter une valeur à une de mes variables dans mes >> boucles while, j'ai le message d'erreur suivant, alors que la >> vérification de >> la syntaxe passe bien : >> Serveur : Msg 137, Niveau 15, État 1, Ligne 1 >> La variable '@NBLIGSCE' doit être déclarée. >> >> Pour faire bref, cela ressemble un peu à >> >> DECLARE @TABLE, @BDD, @NBLIGSCE, @NBLIGDESC, @STR1, @STR2.... >> >> DECLARE C CURSOR..... MESTABLES >> .. >> >> DECLARE D CURSOR.... MES BASES >> >> >> WHILE ... >> BEGIN >> SET STR1 = 'SET @NBLIGSCE = (SELECT COUNT(*) FROM ' + @BDD + '.dbo.' + >> @TABLE+ ')' >> EXEC (@STR1) >> >> ... >> >> >> Et c'est à ce point que j'obtiens le message. La doc T-SQL dit que le >> contexte de BDD n'est valable que jusqu'à la fin d'EXECUTE. Cela >> s'applique-t-il également aux variables ? Comment contourner cette >> difficulté >> ? >> >> D'avance merci. >> > >
OokieDookie
Bonjour,
Effectivement, une fois la bonne syntaxe rédigée, ça marche bien ;) En fait au début j'essayais de déclarer la table dans mon EXECUTE, alors qu'il fallait qu'elle soit déclarée avant l'ouverture des curseurs.
Pour info j'ai même réussi à utiliser sysdatabases et INFORMATION_SCHEMA.tables, je suis comblé !
Merci encore pour votre aide. Ce forume est vraiment cool :) Bonne journée à tous
"OokieDookie" a écrit :
Merci de votre aide.
Désolé cependant, j'obtiens le message suivant : Impossible d'utiliser EXECUTE comme source lors de l'insertion dans une variable de table.
De plus, s'il faut passer par une table de résultat (idée par ailleurs très séduisante, il faudra que je gère trois colonnes (tablesql, nbligsce et nbligdesc), ce qui suppose donc l'utilisation de deux instructions EXEC lors de l'insertion de mes valeurs, ce qui apparemment n'est pas possible (ou alors j'ai raté quelque chose lors de l'implémentation de la table de résultat dans mon script).
Je n'aime pas beaucoup recourir à ce genre d'extrémités, mais si besoin je pourrais publier mon code (2 Ko, je ne sais pas si cela se fait sur ce newsgroup) ;)
Encore merci de votre aide
"BVesan" a écrit :
> Bonjour, > vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à > moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même... > Une solution assez simple pour contourner le problème est de passer par une > table de résultat > > > DECLARE @table_resultat TABLE(col1 int) > > INSERT INTO @table_resultat > EXECUTE (@STR1) > > SELECT @NBLIGSCE = col1 FROM @table_resultat. > > > > Benjamin
Bonjour,
Effectivement, une fois la bonne syntaxe rédigée, ça marche bien ;)
En fait au début j'essayais de déclarer la table dans mon EXECUTE, alors
qu'il fallait qu'elle soit déclarée avant l'ouverture des curseurs.
Pour info j'ai même réussi à utiliser sysdatabases et
INFORMATION_SCHEMA.tables, je suis comblé !
Merci encore pour votre aide. Ce forume est vraiment cool :)
Bonne journée à tous
"OokieDookie" a écrit :
Merci de votre aide.
Désolé cependant, j'obtiens le message suivant :
Impossible d'utiliser EXECUTE comme source lors de l'insertion dans une
variable de table.
De plus, s'il faut passer par une table de résultat (idée par ailleurs très
séduisante, il faudra que je gère trois colonnes (tablesql, nbligsce et
nbligdesc), ce qui suppose donc l'utilisation de deux instructions EXEC lors
de l'insertion de mes valeurs, ce qui apparemment n'est pas possible (ou
alors j'ai raté quelque chose lors de l'implémentation de la table de
résultat dans mon script).
Je n'aime pas beaucoup recourir à ce genre d'extrémités, mais si besoin je
pourrais publier mon code (2 Ko, je ne sais pas si cela se fait sur ce
newsgroup) ;)
Encore merci de votre aide
"BVesan" a écrit :
> Bonjour,
> vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à
> moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même...
> Une solution assez simple pour contourner le problème est de passer par une
> table de résultat
>
>
> DECLARE @table_resultat TABLE(col1 int)
>
> INSERT INTO @table_resultat
> EXECUTE (@STR1)
>
> SELECT @NBLIGSCE = col1 FROM @table_resultat.
>
>
>
> Benjamin
Effectivement, une fois la bonne syntaxe rédigée, ça marche bien ;) En fait au début j'essayais de déclarer la table dans mon EXECUTE, alors qu'il fallait qu'elle soit déclarée avant l'ouverture des curseurs.
Pour info j'ai même réussi à utiliser sysdatabases et INFORMATION_SCHEMA.tables, je suis comblé !
Merci encore pour votre aide. Ce forume est vraiment cool :) Bonne journée à tous
"OokieDookie" a écrit :
Merci de votre aide.
Désolé cependant, j'obtiens le message suivant : Impossible d'utiliser EXECUTE comme source lors de l'insertion dans une variable de table.
De plus, s'il faut passer par une table de résultat (idée par ailleurs très séduisante, il faudra que je gère trois colonnes (tablesql, nbligsce et nbligdesc), ce qui suppose donc l'utilisation de deux instructions EXEC lors de l'insertion de mes valeurs, ce qui apparemment n'est pas possible (ou alors j'ai raté quelque chose lors de l'implémentation de la table de résultat dans mon script).
Je n'aime pas beaucoup recourir à ce genre d'extrémités, mais si besoin je pourrais publier mon code (2 Ko, je ne sais pas si cela se fait sur ce newsgroup) ;)
Encore merci de votre aide
"BVesan" a écrit :
> Bonjour, > vous ne pouvez effectivement pas utiliser de variable dans votre EXECUTE à > moins que celle-ci ne soit aussi définie dans l'EXECUTE lui même... > Une solution assez simple pour contourner le problème est de passer par une > table de résultat > > > DECLARE @table_resultat TABLE(col1 int) > > INSERT INTO @table_resultat > EXECUTE (@STR1) > > SELECT @NBLIGSCE = col1 FROM @table_resultat. > > > > Benjamin
