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, Il est impossible d'effectuer directement une requête en utilisant une variable. SELECT * FROM @nom_de_ma_table NE FONCTIONNERA PAS Il est nécessaire de passer par un contournement du type SELECT @CMD='SELECT * FROM '+@nom_de_ma_table +' WHERE ...' puis EXECUTE(@CMD) ou encore EXECUTE sp_execsql @CMD Les Books Online de SQL Server donnent plus d'informations sur les solutions possibles...
Bonjour,
Il est impossible d'effectuer directement une requête en utilisant une
variable.
SELECT * FROM @nom_de_ma_table NE FONCTIONNERA PAS
Il est nécessaire de passer par un contournement du type
SELECT @CMD='SELECT * FROM '+@nom_de_ma_table +' WHERE ...'
puis
EXECUTE(@CMD)
ou encore EXECUTE sp_execsql @CMD
Les Books Online de SQL Server donnent plus d'informations sur les solutions
possibles...
Bonjour, Il est impossible d'effectuer directement une requête en utilisant une variable. SELECT * FROM @nom_de_ma_table NE FONCTIONNERA PAS Il est nécessaire de passer par un contournement du type SELECT @CMD='SELECT * FROM '+@nom_de_ma_table +' WHERE ...' puis EXECUTE(@CMD) ou encore EXECUTE sp_execsql @CMD Les Books Online de SQL Server donnent plus d'informations sur les solutions possibles...
Patrice
Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui en supprime une partie des avantages...
-- Patrice
"LuckyMan" a écrit dans le message de news:
Bonjour,
Pb bête : j'initialise une variable dans une procédure avec un nom de
table
Set @MaTable = 'ParExemple'
Je veux ensuite travailler sur cette table. Quelle est la bonne syntaxe ?
( select MaColonne from ?????????????? )
Merci.
Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui en
supprime une partie des avantages...
--
Patrice
"LuckyMan" <nospam@nospam.org> a écrit dans le message de
news:eEwcXVWAGHA.4080@TK2MSFTNGP14.phx.gbl...
Bonjour,
Pb bête : j'initialise une variable dans une procédure avec un nom de
table
Set @MaTable = 'ParExemple'
Je veux ensuite travailler sur cette table. Quelle est la bonne syntaxe ?
Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui en supprime une partie des avantages...
-- Patrice
"LuckyMan" a écrit dans le message de news:
Bonjour,
Pb bête : j'initialise une variable dans une procédure avec un nom de
table
Set @MaTable = 'ParExemple'
Je veux ensuite travailler sur cette table. Quelle est la bonne syntaxe ?
( select MaColonne from ?????????????? )
Merci.
LuckyMan
Patrice wrote:
Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui en supprime une partie des avantages...
Merci à Tous,
Donc effectivement... En fait je fais cela pour accéder à des tables dans différentes bases de données et je ne vois pas comment faire autrement qu'en concatenant dans le nom serveur+base+ etc...
Patrice wrote:
Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui
en supprime une partie des avantages...
Merci à Tous,
Donc effectivement... En fait je fais cela pour accéder à des tables dans
différentes bases de données et je ne vois pas comment faire autrement qu'en
concatenant dans le nom serveur+base+ etc...
Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui en supprime une partie des avantages...
Merci à Tous,
Donc effectivement... En fait je fais cela pour accéder à des tables dans différentes bases de données et je ne vois pas comment faire autrement qu'en concatenant dans le nom serveur+base+ etc...
Patrice
Pourquoi plusieurs bases ? C'est la même application avec à chaque fois des données différentes ou des données d'une même application isolées chacune dans une base différente ?
En vrac : - avoir la même procédure stockée dans les différentes bases (par exemple si chaque base est censée être autonome). - utiliser des vues pour agréger des données en provenance de plusieurs bases - à terme avoir les tables dans une même base avec un préfixe par "module" applicatif etc...
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
-- Patrice
"LuckyMan" a écrit dans le message de news:ui$
Patrice wrote: > Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui > en supprime une partie des avantages... >
Merci à Tous,
Donc effectivement... En fait je fais cela pour accéder à des tables dans différentes bases de données et je ne vois pas comment faire autrement
qu'en
concatenant dans le nom serveur+base+ etc...
Pourquoi plusieurs bases ? C'est la même application avec à chaque fois des
données différentes ou des données d'une même application isolées chacune
dans une base différente ?
En vrac :
- avoir la même procédure stockée dans les différentes bases (par exemple si
chaque base est censée être autonome).
- utiliser des vues pour agréger des données en provenance de plusieurs
bases
- à terme avoir les tables dans une même base avec un préfixe par "module"
applicatif
etc...
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
--
Patrice
"LuckyMan" <nospam@nospam.org> a écrit dans le message de
news:ui$ZV6WAGHA.3496@TK2MSFTNGP11.phx.gbl...
Patrice wrote:
> Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui
> en supprime une partie des avantages...
>
Merci à Tous,
Donc effectivement... En fait je fais cela pour accéder à des tables dans
différentes bases de données et je ne vois pas comment faire autrement
Pourquoi plusieurs bases ? C'est la même application avec à chaque fois des données différentes ou des données d'une même application isolées chacune dans une base différente ?
En vrac : - avoir la même procédure stockée dans les différentes bases (par exemple si chaque base est censée être autonome). - utiliser des vues pour agréger des données en provenance de plusieurs bases - à terme avoir les tables dans une même base avec un préfixe par "module" applicatif etc...
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
-- Patrice
"LuckyMan" a écrit dans le message de news:ui$
Patrice wrote: > Il faut alors faire du SQL dynamique (cf EXECUTE dans la doc) ce qui > en supprime une partie des avantages... >
Merci à Tous,
Donc effectivement... En fait je fais cela pour accéder à des tables dans différentes bases de données et je ne vois pas comment faire autrement
qu'en
concatenant dans le nom serveur+base+ etc...
LuckyMan
Patrice wrote:
Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
En vrac : - avoir la même procédure stockée dans les différentes bases (par exemple si chaque base est censée être autonome). - utiliser des vues pour agréger des données en provenance de plusieurs bases - à terme avoir les tables dans une même base avec un préfixe par "module" applicatif etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur chaque base (200 env). , et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE @i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans @nvc_SQLrequest, me shunte de la boucle du curseur. ???!! et je ne vois même pas le print de mon traitement d'erreur...
énervant
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
Merci
Patrice wrote:
Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
En vrac :
- avoir la même procédure stockée dans les différentes bases (par
exemple si chaque base est censée être autonome).
- utiliser des vues pour agréger des données en provenance de
plusieurs bases
- à terme avoir les tables dans une même base avec un préfixe par
"module" applicatif
etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est
possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur
chaque base (200 env).
,
et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE
@i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans @nvc_SQLrequest,
me shunte de la boucle du curseur. ???!! et je ne vois même pas le print de
mon traitement d'erreur...
énervant
en fonction du cas de figure dans lequel tu te trouves...
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
En vrac : - avoir la même procédure stockée dans les différentes bases (par exemple si chaque base est censée être autonome). - utiliser des vues pour agréger des données en provenance de plusieurs bases - à terme avoir les tables dans une même base avec un préfixe par "module" applicatif etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur chaque base (200 env). , et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE @i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans @nvc_SQLrequest, me shunte de la boucle du curseur. ???!! et je ne vois même pas le print de mon traitement d'erreur...
énervant
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
Merci
Fred BROUARD
Pourquoi ne pas tout rassembler dans la même base ? Ce serait déjà plus performant...
A +
LuckyMan a écrit:
Patrice wrote:
Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
En vrac : - avoir la même procédure stockée dans les différentes bases (par exemple si chaque base est censée être autonome). - utiliser des vues pour agréger des données en provenance de plusieurs bases - à terme avoir les tables dans une même base avec un préfixe par "module" applicatif etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur chaque base (200 env). , et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE @i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans @nvc_SQLrequest, me shunte de la boucle du curseur. ???!! et je ne vois même pas le print de mon traitement d'erreur...
énervant
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
Merci
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Pourquoi ne pas tout rassembler dans la même base ? Ce serait déjà plus
performant...
A +
LuckyMan a écrit:
Patrice wrote:
Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
En vrac :
- avoir la même procédure stockée dans les différentes bases (par
exemple si chaque base est censée être autonome).
- utiliser des vues pour agréger des données en provenance de
plusieurs bases
- à terme avoir les tables dans une même base avec un préfixe par
"module" applicatif
etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est
possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur
chaque base (200 env).
,
et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE
@i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans @nvc_SQLrequest,
me shunte de la boucle du curseur. ???!! et je ne vois même pas le print de
mon traitement d'erreur...
énervant
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
Merci
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Pourquoi ne pas tout rassembler dans la même base ? Ce serait déjà plus performant...
A +
LuckyMan a écrit:
Patrice wrote:
Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
En vrac : - avoir la même procédure stockée dans les différentes bases (par exemple si chaque base est censée être autonome). - utiliser des vues pour agréger des données en provenance de plusieurs bases - à terme avoir les tables dans une même base avec un préfixe par "module" applicatif etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur chaque base (200 env). , et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE @i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans @nvc_SQLrequest, me shunte de la boucle du curseur. ???!! et je ne vois même pas le print de mon traitement d'erreur...
énervant
en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
Merci
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Patrice
Je pense que je ferais une vue si le nombre de bases est relativement stable...
Sinon à terme voir si il ne serait pas plus intéressant d'avoir une base unique (avec un code pour distinguer chaque "projet" pour que l'application soit simplement "multi-projets" au lieu d'avoir un "projet" par base).
--
"LuckyMan" a écrit dans le message de news:
Patrice wrote: > Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
> En vrac : > - avoir la même procédure stockée dans les différentes bases (par > exemple si chaque base est censée être autonome). > - utiliser des vues pour agréger des données en provenance de > plusieurs bases > - à terme avoir les tables dans une même base avec un préfixe par > "module" applicatif > etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur chaque base (200 env). , et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE @i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans
@nvc_SQLrequest,
me shunte de la boucle du curseur. ???!! et je ne vois même pas le print
de
mon traitement d'erreur...
énervant
> en fonction du cas de figure dans lequel tu te trouves... Bon courage.
Merci
Je pense que je ferais une vue si le nombre de bases est relativement
stable...
Sinon à terme voir si il ne serait pas plus intéressant d'avoir une base
unique (avec un code pour distinguer chaque "projet" pour que l'application
soit simplement "multi-projets" au lieu d'avoir un "projet" par base).
--
"LuckyMan" <nospam@nospam.org> a écrit dans le message de
news:eOxx3aZAGHA.3140@TK2MSFTNGP14.phx.gbl...
Patrice wrote:
> Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
> En vrac :
> - avoir la même procédure stockée dans les différentes bases (par
> exemple si chaque base est censée être autonome).
> - utiliser des vues pour agréger des données en provenance de
> plusieurs bases
> - à terme avoir les tables dans une même base avec un préfixe par
> "module" applicatif
> etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est
possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur
chaque base (200 env).
,
et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE
@i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans
@nvc_SQLrequest,
me shunte de la boucle du curseur. ???!! et je ne vois même pas le print
de
mon traitement d'erreur...
énervant
> en fonction du cas de figure dans lequel tu te trouves...
Bon courage.
Je pense que je ferais une vue si le nombre de bases est relativement stable...
Sinon à terme voir si il ne serait pas plus intéressant d'avoir une base unique (avec un code pour distinguer chaque "projet" pour que l'application soit simplement "multi-projets" au lieu d'avoir un "projet" par base).
--
"LuckyMan" a écrit dans le message de news:
Patrice wrote: > Pourquoi plusieurs bases ?
C'est la même application avec à chaque fois des données différentes
Je dois faire une "consolidation" des données.
> En vrac : > - avoir la même procédure stockée dans les différentes bases (par > exemple si chaque base est censée être autonome). > - utiliser des vues pour agréger des données en provenance de > plusieurs bases > - à terme avoir les tables dans une même base avec un préfixe par > "module" applicatif > etc...
Oui, plein d'idées , je vais même essayer une UDF pour voir (si c'est possible), d'un autre coté je ne voudrais pas faire une maj manuelle sur chaque base (200 env). , et c'est sur à terme le schéma va changer...
Pour le moment je balaye les bases via un cursor et passe par un EXECUTE @i_ReturnCode = sp_executesql @nvc_SQLrequest
puis je teste @i_ReturnCode et @@ERROR
Ca semble Ok, Le seul pb c'est que la moindre erreur ,dans
@nvc_SQLrequest,
me shunte de la boucle du curseur. ???!! et je ne vois même pas le print
de
mon traitement d'erreur...
énervant
> en fonction du cas de figure dans lequel tu te trouves... Bon courage.
