Discussion :

[|DUCATI| DesMo]

Bonjour à tous,

petit problème dans l'utilisation des curseurs, en fait je cherche à créer un curseur indépendant de la base de données (là même requête est à jouer sur différentes DB ayant la même structure.

Ce que je cherche à faire serait du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
DECLARE @MyDB VARCHAR(255)
SET @MyDB = 'MyDataBase'
DECLARE MyCursor CURSOR
FOR
     SELECT * 
     FROM @MyDB.Mytable

Une idée SVP?

[|DUCATI| DesMo]

Pour l'instant je contourne en faisant référence à la DB avec un USE paramétré :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
CREATE PROCEDURE [dbo].[UseDB] 
	-- Add the parameters for the stored procedure here
	@MyDB sysname
AS
BEGIN
	DECLARE @SQL VARCHAR(255);
	SET @SQL = 'USE ' + @MyDB;
	EXEC (@SQL);
END

Puis je declare le curseur sans faire reference à la DB, juste à la table.

[pacmann]

Salut !

Je dirais que ta solution de contournement met le doigt sur le point sensible : l'exécution dynamique avec des noms d'objets de base de données passés en variable.

Si tu es sous SQL Server, tu dois faire toute la déclaration de ton curseur dynamiquement. J'ai vu cet exemple sur le net :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
SELECT @sql = 'DECLARE my_cur INSENSITIVE CURSOR FOR ' +
              'SELECT col1, col2, col3 FROM ' + @table
EXEC sp_executesql @sql

[elsuket]

Bonjour,

Le script SQL doit être dans la chaîne @SQL, parce que le contexte d'exécution dans ce cas est distinct de celui de la procédure stockée ...

@++

[SQLpro]

Vous pouvez aussi inverser la vapeur en commençant par un USE dynamique. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE PROCEDURE listeTable @DB sysname
AS
 
DECLARE @SQL NVARCHAR(max)
SET @SQL = 'USE ' + @DB+';'
SET @SQL = @SQL + 'SELECT * FROM sys.database_files'
 
EXEC (@SQL)
 
GO

A +

[pacmann]

Bonjour,

Le script SQL doit être dans la chaîne @SQL, parce que le contexte d'exécution dans ce cas est distinct de celui de la procédure stockée ...

@++

Ouais, justement ils parlaient sur le site ou j'ai pompé l'exemple :

You may be used to using the LOCAL keyword with your cursors. However, it is important to understand that you must use a global cursor, as a local cursor will disappear when the dynamic SQL exits. (Because, as you know by now, the dynamic SQL is its own scope.) Once you have declared the cursor in this way, you can use the cursor in a normal fashion. You must be extra careful with error-handling though, so that you don't exit the procedure without deallocating the cursor.

Comme je connais rien à SQL Server, j'ai supposé que l'exemple correspondait à un global cursor...

Bon mais maintenant qu'on en est là, je vous donne aussi la fin du paragraphe (que je ne cherche pas à comprendre, comme je ne suis pas sur SQL Server) :

There is however a way to use locally-scoped cursors with dynamic SQL. Anthony Faull pointed out to me that you can achieve this with cursor variables, as in this example:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
DECLARE @my_cur CURSOR
EXEC sp_executesql
     N'SET @my_cur = CURSOR STATIC FOR
       SELECT name FROM dbo.sysobjects;
       OPEN @my_cur',
     N'@my_cur cursor OUTPUT', @my_cur OUTPUT
FETCH NEXT FROM @my_cur

You refer to a cursor variable, just like named cursors, but there is an @ in front, and, as you see from the example, you can pass them as a parameters. (I have to confess I have never seen any use for cursor variables until Anthony Faull was kind to send me this example.)

http://www.sommarskog.se/dynamic_sql.html