J'ai écrit une procédure stockée qui doit être utilisée par de multiples
bases de donnée. Je l'ai donc écrite dans la base master.
Je tente ensuite de l'exécuter comme ceci :
USE MaBase
GO
EXEC MASTER..sp_maproc_export '10/05/2007', 'DL6'
et voici ce qu'il me retourne :
Serveur : Msg 208, Niveau 16, État 1, Procédure sp_maproc_export, Ligne
41
'DOC_REMISE' : nom d'objet incorrect.
Le code de ma ps, exécuté directement dans le contexte de [MaBase]
fonctionne correctement (la table [DOC_REMISE] est connue dans MaBase)
J'en déduis donc que la commande EXEC MASTER..sp_maproc_export s'exécute
dans le contexte de la base [MASTER].
Mon problème, c'est que je ne trouve pas de solution pour exécuter ma
procédure sur la bonne base.
J'ai essayé de passer en paramètre le nom de la bdd et d'utiliser USE,
mais le serveur refuse cette commande à l'intérieur d'une procédure
stockée.
J'ai aussi tenté une syntaxe genre SELECT * FROM [@bdd]..[DOC_REMISE]
masi sans plus de succès...
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
Fred BROUARD
Faîtes ce test :
CREATE PROCEDURE sp_test AS
SELECT DB_NAME()
SELECT * FROM INFORMATION_SCHEMA.TABLES GO
USE <mabase> GO
Exec sp_test GO
vous constaterez que la base qui lance la proc est bien la votre, mais que le code s'exécute en local dans master.
Pour faire en sorte que le code s'exécute sur votre base vous pouvez utiliser différentes techniques, dont le SQL dynamique.
A +
Eric Belhomme a écrit :
Bonjour,
J'ai écrit une procédure stockée qui doit être utilisée par de multiples bases de donnée. Je l'ai donc écrite dans la base master. Je tente ensuite de l'exécuter comme ceci :
USE MaBase GO EXEC MASTER..sp_maproc_export '10/05/2007', 'DL6'
et voici ce qu'il me retourne : Serveur : Msg 208, Niveau 16, État 1, Procédure sp_maproc_export, Ligne 41 'DOC_REMISE' : nom d'objet incorrect.
Le code de ma ps, exécuté directement dans le contexte de [MaBase] fonctionne correctement (la table [DOC_REMISE] est connue dans MaBase) J'en déduis donc que la commande EXEC MASTER..sp_maproc_export s'exécute dans le contexte de la base [MASTER].
Mon problème, c'est que je ne trouve pas de solution pour exécuter ma procédure sur la bonne base. J'ai essayé de passer en paramètre le nom de la bdd et d'utiliser USE, mais le serveur refuse cette commande à l'intérieur d'une procédure stockée. J'ai aussi tenté une syntaxe genre SELECT * FROM [@bdd]..[DOC_REMISE] masi sans plus de succès...
Merci pour votre aide :)
-- 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 ***********************
Faîtes ce test :
CREATE PROCEDURE sp_test
AS
SELECT DB_NAME()
SELECT * FROM INFORMATION_SCHEMA.TABLES
GO
USE <mabase>
GO
Exec sp_test
GO
vous constaterez que la base qui lance la proc est bien la votre, mais
que le code s'exécute en local dans master.
Pour faire en sorte que le code s'exécute sur votre base vous pouvez
utiliser différentes techniques, dont le SQL dynamique.
A +
Eric Belhomme a écrit :
Bonjour,
J'ai écrit une procédure stockée qui doit être utilisée par de multiples
bases de donnée. Je l'ai donc écrite dans la base master.
Je tente ensuite de l'exécuter comme ceci :
USE MaBase
GO
EXEC MASTER..sp_maproc_export '10/05/2007', 'DL6'
et voici ce qu'il me retourne :
Serveur : Msg 208, Niveau 16, État 1, Procédure sp_maproc_export, Ligne
41
'DOC_REMISE' : nom d'objet incorrect.
Le code de ma ps, exécuté directement dans le contexte de [MaBase]
fonctionne correctement (la table [DOC_REMISE] est connue dans MaBase)
J'en déduis donc que la commande EXEC MASTER..sp_maproc_export s'exécute
dans le contexte de la base [MASTER].
Mon problème, c'est que je ne trouve pas de solution pour exécuter ma
procédure sur la bonne base.
J'ai essayé de passer en paramètre le nom de la bdd et d'utiliser USE,
mais le serveur refuse cette commande à l'intérieur d'une procédure
stockée.
J'ai aussi tenté une syntaxe genre SELECT * FROM [@bdd]..[DOC_REMISE]
masi sans plus de succès...
Merci pour votre aide :)
--
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 ***********************
vous constaterez que la base qui lance la proc est bien la votre, mais que le code s'exécute en local dans master.
Pour faire en sorte que le code s'exécute sur votre base vous pouvez utiliser différentes techniques, dont le SQL dynamique.
A +
Eric Belhomme a écrit :
Bonjour,
J'ai écrit une procédure stockée qui doit être utilisée par de multiples bases de donnée. Je l'ai donc écrite dans la base master. Je tente ensuite de l'exécuter comme ceci :
USE MaBase GO EXEC MASTER..sp_maproc_export '10/05/2007', 'DL6'
et voici ce qu'il me retourne : Serveur : Msg 208, Niveau 16, État 1, Procédure sp_maproc_export, Ligne 41 'DOC_REMISE' : nom d'objet incorrect.
Le code de ma ps, exécuté directement dans le contexte de [MaBase] fonctionne correctement (la table [DOC_REMISE] est connue dans MaBase) J'en déduis donc que la commande EXEC MASTER..sp_maproc_export s'exécute dans le contexte de la base [MASTER].
Mon problème, c'est que je ne trouve pas de solution pour exécuter ma procédure sur la bonne base. J'ai essayé de passer en paramètre le nom de la bdd et d'utiliser USE, mais le serveur refuse cette commande à l'intérieur d'une procédure stockée. J'ai aussi tenté une syntaxe genre SELECT * FROM [@bdd]..[DOC_REMISE] masi sans plus de succès...
Merci pour votre aide :)
-- 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 ***********************
Eric Belhomme
Fred BROUARD wrote in news:eVDc80slHHA.3704 @TK2MSFTNGP02.phx.gbl:
vous constaterez que la base qui lance la proc est bien la votre, mais que le code s'ex‚cute en local dans master.
oui, c'etait bien ma conclusion
Pour faire en sorte que le code s'ex‚cute sur votre base vous pouvez utiliser diff‚rentes techniques, dont le SQL dynamique.
mais encore ? qu'est ce que vous appelez "sql dynamique" ?
une dernière précision : ma procédure utilise massivement les curseurs
-- Rico
Fred BROUARD <brouardf@club-internet.fr> wrote in news:eVDc80slHHA.3704
@TK2MSFTNGP02.phx.gbl:
vous constaterez que la base qui lance la proc est bien la votre, mais
que le code s'ex‚cute en local dans master.
oui, c'etait bien ma conclusion
Pour faire en sorte que le code s'ex‚cute sur votre base vous pouvez
utiliser diff‚rentes techniques, dont le SQL dynamique.
mais encore ? qu'est ce que vous appelez "sql dynamique" ?
une dernière précision : ma procédure utilise massivement les curseurs
Fred BROUARD wrote in news:eVDc80slHHA.3704 @TK2MSFTNGP02.phx.gbl:
vous constaterez que la base qui lance la proc est bien la votre, mais que le code s'ex‚cute en local dans master.
oui, c'etait bien ma conclusion
Pour faire en sorte que le code s'ex‚cute sur votre base vous pouvez utiliser diff‚rentes techniques, dont le SQL dynamique.
mais encore ? qu'est ce que vous appelez "sql dynamique" ?
une dernière précision : ma procédure utilise massivement les curseurs
-- Rico
Fred BROUARD
Eric Belhomme a écrit :
Fred BROUARD wrote in news:eVDc80slHHA.3704 @TK2MSFTNGP02.phx.gbl:
vous constaterez que la base qui lance la proc est bien la votre, mais que le code s'ex‚cute en local dans master.
oui, c'etait bien ma conclusion
Pour faire en sorte que le code s'ex‚cute sur votre base vous pouvez utiliser diff‚rentes techniques, dont le SQL dynamique.
mais encore ? qu'est ce que vous appelez "sql dynamique" ?
CREATE PROC P_LISTE_TABLE @NOM_BASE SYSNAME AS
DECLARE @SQL VARXCHAR(800)
SET @SQL = 'SELECT * FROM ' + @NOM_BASE + '.INFORMATION_SCHEMA.TABLES'
EXEC (@SQL)
GO
-- test :
EXEC P_LISTE_TABLE 'pubs'
une dernière précision : ma procédure utilise massivement les curseurs
ils sont évitable dans 80% des cas et mieux vaut les éviter car générateur de temps de long réponse et de vérouillages intenses. Bref, performances mauvaises.
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
A +
-- 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 ***********************
Eric Belhomme a écrit :
Fred BROUARD <brouardf@club-internet.fr> wrote in news:eVDc80slHHA.3704
@TK2MSFTNGP02.phx.gbl:
vous constaterez que la base qui lance la proc est bien la votre, mais
que le code s'ex‚cute en local dans master.
oui, c'etait bien ma conclusion
Pour faire en sorte que le code s'ex‚cute sur votre base vous pouvez
utiliser diff‚rentes techniques, dont le SQL dynamique.
mais encore ? qu'est ce que vous appelez "sql dynamique" ?
CREATE PROC P_LISTE_TABLE @NOM_BASE SYSNAME
AS
DECLARE @SQL VARXCHAR(800)
SET @SQL = 'SELECT * FROM ' + @NOM_BASE + '.INFORMATION_SCHEMA.TABLES'
EXEC (@SQL)
GO
-- test :
EXEC P_LISTE_TABLE 'pubs'
une dernière précision : ma procédure utilise massivement les curseurs
ils sont évitable dans 80% des cas et mieux vaut les éviter car
générateur de temps de long réponse et de vérouillages intenses.
Bref, performances mauvaises.
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
A +
--
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 ***********************
Fred BROUARD wrote in news:eVDc80slHHA.3704 @TK2MSFTNGP02.phx.gbl:
vous constaterez que la base qui lance la proc est bien la votre, mais que le code s'ex‚cute en local dans master.
oui, c'etait bien ma conclusion
Pour faire en sorte que le code s'ex‚cute sur votre base vous pouvez utiliser diff‚rentes techniques, dont le SQL dynamique.
mais encore ? qu'est ce que vous appelez "sql dynamique" ?
CREATE PROC P_LISTE_TABLE @NOM_BASE SYSNAME AS
DECLARE @SQL VARXCHAR(800)
SET @SQL = 'SELECT * FROM ' + @NOM_BASE + '.INFORMATION_SCHEMA.TABLES'
EXEC (@SQL)
GO
-- test :
EXEC P_LISTE_TABLE 'pubs'
une dernière précision : ma procédure utilise massivement les curseurs
ils sont évitable dans 80% des cas et mieux vaut les éviter car générateur de temps de long réponse et de vérouillages intenses. Bref, performances mauvaises.
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
A +
-- 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 ***********************
Eric Belhomme
Fred BROUARD wrote in news:evoGbhtlHHA.3496 @TK2MSFTNGP03.phx.gbl:
CREATE PROC P_LISTE_TABLE @NOM_BASE SYSNAME AS
DECLARE @SQL VARXCHAR(800)
SET @SQL = 'SELECT * FROM ' + @NOM_BASE + '.INFORMATION_SCHEMA.TABLES'
EXEC (@SQL)
GO
-- test :
EXEC P_LISTE_TABLE 'pubs'
une dernière précision : ma procédure utilise massivement les curseurs
ils sont évitable dans 80% des cas et mieux vaut les éviter car générateur de temps de long réponse et de vérouillages intenses. Bref, performances mauvaises.
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
je l'ai déjà lu ;) et il est très instructif (comme votre site, et votre bouquin, qui est ma référence dès que je cherche à pondre une requête à peu près potable), mais dans le cas qui m'occupe, la procédure est déjà écrite, et il s'agit de l'adapter pour qu'elle tourne ailleurs, et je n'ai ni le temps, ni le courage de la réécrire ! Il doit tout de même bien exister un moyen _simple_ d'exécuter un cusror select sur une autre base que la base active ?
-- Rico
Fred BROUARD <brouardf@club-internet.fr> wrote in news:evoGbhtlHHA.3496
@TK2MSFTNGP03.phx.gbl:
CREATE PROC P_LISTE_TABLE @NOM_BASE SYSNAME
AS
DECLARE @SQL VARXCHAR(800)
SET @SQL = 'SELECT * FROM ' + @NOM_BASE + '.INFORMATION_SCHEMA.TABLES'
EXEC (@SQL)
GO
-- test :
EXEC P_LISTE_TABLE 'pubs'
une dernière précision : ma procédure utilise massivement les curseurs
ils sont évitable dans 80% des cas et mieux vaut les éviter car
générateur de temps de long réponse et de vérouillages intenses.
Bref, performances mauvaises.
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
je l'ai déjà lu ;) et il est très instructif (comme votre site, et votre
bouquin, qui est ma référence dès que je cherche à pondre une requête à peu
près potable), mais dans le cas qui m'occupe, la procédure est déjà écrite,
et il s'agit de l'adapter pour qu'elle tourne ailleurs, et je n'ai ni le
temps, ni le courage de la réécrire !
Il doit tout de même bien exister un moyen _simple_ d'exécuter un cusror
select sur une autre base que la base active ?
Fred BROUARD wrote in news:evoGbhtlHHA.3496 @TK2MSFTNGP03.phx.gbl:
CREATE PROC P_LISTE_TABLE @NOM_BASE SYSNAME AS
DECLARE @SQL VARXCHAR(800)
SET @SQL = 'SELECT * FROM ' + @NOM_BASE + '.INFORMATION_SCHEMA.TABLES'
EXEC (@SQL)
GO
-- test :
EXEC P_LISTE_TABLE 'pubs'
une dernière précision : ma procédure utilise massivement les curseurs
ils sont évitable dans 80% des cas et mieux vaut les éviter car générateur de temps de long réponse et de vérouillages intenses. Bref, performances mauvaises.
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
je l'ai déjà lu ;) et il est très instructif (comme votre site, et votre bouquin, qui est ma référence dès que je cherche à pondre une requête à peu près potable), mais dans le cas qui m'occupe, la procédure est déjà écrite, et il s'agit de l'adapter pour qu'elle tourne ailleurs, et je n'ai ni le temps, ni le courage de la réécrire ! Il doit tout de même bien exister un moyen _simple_ d'exécuter un cusror select sur une autre base que la base active ?
