J'ai cr=E9=E9 quelques scripts permettant de corriger des=20
d=E9fauts de traitements dans une base SQL.
Ils fonctionnent tr=E8s bien, mais je voudrais les rendre=20
accessibles =E0 des gens qui ne connaissent pas l'analyseur=20
de requ=EAtes, notamment en cr=E9ant un pav=E9 "d=E9claration de=20
variables", dans lequel je voudrais passer le nom de la=20
BDD =E0 utiliser.
Le souci c'est que les instructions du type
select * from @dbname..MATABLE ne fonctionnent pas.
DECLARE @sql_exec VARCHAR(1000 ,@dbname VARCHAR(10 SET @dbname='dbname SET @sql_exec = 'select * from '+@dbname+'..MATABLE EXEC (@sql_exec
OokieDookie
Bonjour et merci.
Effectivement ça marche bien. Cependant j'ai des goût de luxe ;) En effet cela oblige à pas mal de modifs, pour stocker toutes ces requêtes dans des varchar. Il n'y a pas d'autre solution?
Merci encore.
Bonjour et merci.
Effectivement ça marche bien.
Cependant j'ai des goût de luxe ;)
En effet cela oblige à pas mal de modifs, pour stocker
toutes ces requêtes dans des varchar.
Il n'y a pas d'autre solution?
Effectivement ça marche bien. Cependant j'ai des goût de luxe ;) En effet cela oblige à pas mal de modifs, pour stocker toutes ces requêtes dans des varchar. Il n'y a pas d'autre solution?
Merci encore.
Michel Walsh
Salut,
Malheureusement pas, de base, puisque la table doit être connue pour que le plan d'exécution soit prévisible, sinon, cela implique une requête dynamique. Par contre, il est possible que les tables soient modifiables, en les agglutinant ensemble, pour n'en faire qu'une; illustration:
SELECT f1, f2, f3, "Table1" As qui FROM Table1 UNION ALL SELECT f1, f2, f3, "Table2" FROM Table2 ... SELECT f1, f2, f3, "TableN" FROM TableN
et alors, l'énoncé serait de la forme:
SELECT * FROM requêtePrécédante WHERE qui= @paramètre
En effet, dans ce cas, le paramètre remplace maintenant une VALEUR, non un nom de table, ce qui va dans le sens d'une requête SQL et des "règles de normalisation" ( je déteste cette expression, j'y préfère quelque chose comme "c'est quoi qu'on s'attend à ce que vous fournissiez à l'outil, et si vous présentez la patente différemment, dessus-dessous, l'ouvrage peut quand même être faite, mais attendez-vous à bloquer totalement la chaîne de montage, en cours de route"). MS SQL Server 2000 permet des vues indexées, dans ce cas, il est possible, sous condition, de se limiter à la vue (sans avoir à recréer physiquement les tables), ie, de faire la requête sur la vue (qui est la requête union all présentée ci-haut), mais je ne suggère pas. Si on aime les complications, on peut même s'amuser à faire une vue sur bases de données distribuées... mais personnellement, je ne m'avanturerais pas dans cette ruelle-là... pas tout seul, du moins.
Espérant être utile, Vanderghast, Access MVP
"OokieDookie" wrote in message news:dfa101c3efda$ed110350$ Bonjour et merci.
Effectivement ça marche bien. Cependant j'ai des goût de luxe ;) En effet cela oblige à pas mal de modifs, pour stocker toutes ces requêtes dans des varchar. Il n'y a pas d'autre solution?
Merci encore.
Salut,
Malheureusement pas, de base, puisque la table doit être connue pour
que le plan d'exécution soit prévisible, sinon, cela implique une requête
dynamique. Par contre, il est possible que les tables soient modifiables, en
les agglutinant ensemble, pour n'en faire qu'une; illustration:
SELECT f1, f2, f3, "Table1" As qui FROM Table1
UNION ALL
SELECT f1, f2, f3, "Table2" FROM Table2
...
SELECT f1, f2, f3, "TableN" FROM TableN
et alors, l'énoncé serait de la forme:
SELECT * FROM requêtePrécédante WHERE qui= @paramètre
En effet, dans ce cas, le paramètre remplace maintenant une VALEUR, non un
nom de table, ce qui va dans le sens d'une requête SQL et des "règles de
normalisation" ( je déteste cette expression, j'y préfère quelque chose
comme "c'est quoi qu'on s'attend à ce que vous fournissiez à l'outil, et si
vous présentez la patente différemment, dessus-dessous, l'ouvrage peut quand
même être faite, mais attendez-vous à bloquer totalement la chaîne de
montage, en cours de route"). MS SQL Server 2000 permet des vues indexées,
dans ce cas, il est possible, sous condition, de se limiter à la vue (sans
avoir à recréer physiquement les tables), ie, de faire la requête sur la vue
(qui est la requête union all présentée ci-haut), mais je ne suggère pas.
Si on aime les complications, on peut même s'amuser à faire une vue sur
bases de données distribuées... mais personnellement, je ne m'avanturerais
pas dans cette ruelle-là... pas tout seul, du moins.
Espérant être utile,
Vanderghast, Access MVP
"OokieDookie" <anonymous@discussions.microsoft.com> wrote in message
news:dfa101c3efda$ed110350$a601280a@phx.gbl...
Bonjour et merci.
Effectivement ça marche bien.
Cependant j'ai des goût de luxe ;)
En effet cela oblige à pas mal de modifs, pour stocker
toutes ces requêtes dans des varchar.
Il n'y a pas d'autre solution?
Malheureusement pas, de base, puisque la table doit être connue pour que le plan d'exécution soit prévisible, sinon, cela implique une requête dynamique. Par contre, il est possible que les tables soient modifiables, en les agglutinant ensemble, pour n'en faire qu'une; illustration:
SELECT f1, f2, f3, "Table1" As qui FROM Table1 UNION ALL SELECT f1, f2, f3, "Table2" FROM Table2 ... SELECT f1, f2, f3, "TableN" FROM TableN
et alors, l'énoncé serait de la forme:
SELECT * FROM requêtePrécédante WHERE qui= @paramètre
En effet, dans ce cas, le paramètre remplace maintenant une VALEUR, non un nom de table, ce qui va dans le sens d'une requête SQL et des "règles de normalisation" ( je déteste cette expression, j'y préfère quelque chose comme "c'est quoi qu'on s'attend à ce que vous fournissiez à l'outil, et si vous présentez la patente différemment, dessus-dessous, l'ouvrage peut quand même être faite, mais attendez-vous à bloquer totalement la chaîne de montage, en cours de route"). MS SQL Server 2000 permet des vues indexées, dans ce cas, il est possible, sous condition, de se limiter à la vue (sans avoir à recréer physiquement les tables), ie, de faire la requête sur la vue (qui est la requête union all présentée ci-haut), mais je ne suggère pas. Si on aime les complications, on peut même s'amuser à faire une vue sur bases de données distribuées... mais personnellement, je ne m'avanturerais pas dans cette ruelle-là... pas tout seul, du moins.
Espérant être utile, Vanderghast, Access MVP
"OokieDookie" wrote in message news:dfa101c3efda$ed110350$ Bonjour et merci.
Effectivement ça marche bien. Cependant j'ai des goût de luxe ;) En effet cela oblige à pas mal de modifs, pour stocker toutes ces requêtes dans des varchar. Il n'y a pas d'autre solution?
Merci encore.
el.c. - myLittleTools.net
> Le souci c'est que les instructions du type select * from @dbname..MATABLE ne fonctionnent pas.
peut etre en faisant EXEC ('USE ' + @dbname) SELECT * FROM MaTable
el.c.
-- // myLittleTools.net : leading provider of web-based applications. // myLittleAdmin WebHosting Edition is now available // http://www.mylittletools.net //
> Le souci c'est que les instructions du type
select * from @dbname..MATABLE ne fonctionnent pas.
peut etre en faisant
EXEC ('USE ' + @dbname)
SELECT * FROM MaTable
el.c.
--
// myLittleTools.net : leading provider of web-based applications.
// myLittleAdmin WebHosting Edition is now available
// http://www.mylittletools.net
// webmaster@mylittletools.net
> Le souci c'est que les instructions du type select * from @dbname..MATABLE ne fonctionnent pas.
peut etre en faisant EXEC ('USE ' + @dbname) SELECT * FROM MaTable
el.c.
-- // myLittleTools.net : leading provider of web-based applications. // myLittleAdmin WebHosting Edition is now available // http://www.mylittletools.net //
Jorge Lavado
Bonjour. Ceci ne marche pas puisque quand tu execute USE tu est dans une diferente "Session" du Select EXEC ('USE ' + @dbname) SELECT * FROM MaTable
Pour utilizer USE :
EXEC ('USE ' + @dbname +'SELECT * FROM MaTable')
Bonjour.
Ceci ne marche pas puisque quand tu execute USE tu est dans une diferente "Session" du Select
EXEC ('USE ' + @dbname)
SELECT * FROM MaTable
