cursor select and variables

I have problems to place my variable into the select statement.

DECLARE @.DB_NAME varchar(64)
DECLARE MR_ReqPro_DB_cursor CURSOR FOR
select name from dbo.sysdatabases where name like '%MR_req%'
OPEN MR_ReqPro_DB_cursor
FETCH NEXT FROM MR_ReqPro_DB_cursor
INTO @.DB_NAME

WHILE @.@.FETCH_STATUS = 0
BEGIN
print @.DB_NAME; --works fine

Select NAME, FILEDIRECTORY FROM @.DB_NAME.MR_ReqPro.RQDOCUMENTS WHERE (FILEDIRECTORY LIKE '%\\%');

FETCH NEXT FROM MR_ReqPro_DB_cursor INTO @.DB_NAME
END
CLOSE MR_ReqPro_DB_cursor
DEALLOCATE MR_ReqPro_DB_cursor

GO

How could i use a variable like @.DB_Name in my select ?

the object against which you run a query cannot be a variable. You need use dynamic SQL by first constructing your SQL query as a string and then using the EXEC command or the sp_execute_sql system stored procedure. e.g.

declare @.sql VARCHAR(4000)

set @.sql = 'Select NAME, FILEDIRECTORY FROM ' + @.DB_NAME + '.MR_ReqPro.RQDOCUMENTS WHERE (FILEDIRECTORY LIKE ''%\\%'');'

EXEC (@.sql)

CURSOR QUESTION ??...

Can I use paremeters in Cursor within the SP as:
DECLARE c_Stbls CURSOR FOR
SELECT @.columnparemeter FROM @.tableparemeter
where both @.columnparemeter and @.tableparemeter are input paremeters from
the SP.
How do I acomplish this within a SP ?
Thanks,
TomdOn Tue, 4 Oct 2005 15:37:07 -0700, tom d wrote:

>Can I use paremeters in Cursor within the SP as:
>DECLARE c_Stbls CURSOR FOR
>SELECT @.columnparemeter FROM @.tableparemeter
>where both @.columnparemeter and @.tableparemeter are input paremeters from
>the SP.
>How do I acomplish this within a SP ?
Hi Tom,
Typically, you don't.
Both cursors and dynamic SQL are last resort solution, that you should
only consider when everything elsse fails. Here, you are basically
trying to use them both.
Could you explain what you're trying to achieve? I.e.: *why* do you have
to open a cursor for an unknown column in an unknown table?
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Why a cursor? Worse, why a *dynamic* cursor? These are the twin evils of
last resort so I'm convinced there ought to be a better way. If you're not
convinced then see the following article for some examples that might help
and some advice that might change your mind.
http://www.sommarskog.se/dynamic_sql.html
David Portas
SQL Server MVP
--
"tom d" <tomd@.discussions.microsoft.com> wrote in message
news:E8B003BC-D407-4D38-BA1A-A815506BC0E9@.microsoft.com...
> Can I use paremeters in Cursor within the SP as:
> DECLARE c_Stbls CURSOR FOR
> SELECT @.columnparemeter FROM @.tableparemeter
> where both @.columnparemeter and @.tableparemeter are input paremeters from
> the SP.
> How do I acomplish this within a SP ?
> Thanks,
> Tomd|||"Twin evils of last resort" Use them only if the relational potion your
quaff turns out to be water, and your sceptre has been drained of all set
based powers :)
And I agree with both David and Hugo, give us an idea of what you are trying
to do and we can help out a bit more.
--
----
Louis Davidson - http://spaces.msn.com/members/drsql/
SQL Server MVP
"Arguments are to be avoided: they are always vulgar and often convincing."
(Oscar Wilde)
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:T5Wdnbn8v-eemt7enZ2dnUVZ8qmdnZ2d@.giganews.com...
> Why a cursor? Worse, why a *dynamic* cursor? These are the twin evils of
> last resort so I'm convinced there ought to be a better way. If you're not
> convinced then see the following article for some examples that might help
> and some advice that might change your mind.
> http://www.sommarskog.se/dynamic_sql.html
> --
> David Portas
> SQL Server MVP
> --
> "tom d" <tomd@.discussions.microsoft.com> wrote in message
> news:E8B003BC-D407-4D38-BA1A-A815506BC0E9@.microsoft.com...
>|||Another Reason for why you should not use?
Belive Me, You will end up with lots of frustration when you want to use
dynamic cursors.
--
Regards
R.D
--Knowledge gets doubled when shared
"Louis Davidson" wrote:

> "Twin evils of last resort" Use them only if the relational potion your
> quaff turns out to be water, and your sceptre has been drained of all set
> based powers :)
> And I agree with both David and Hugo, give us an idea of what you are tryi
ng
> to do and we can help out a bit more.
> --
> ----
--
> Louis Davidson - http://spaces.msn.com/members/drsql/
> SQL Server MVP
> "Arguments are to be avoided: they are always vulgar and often convincing.
"
> (Oscar Wilde)
> "David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
> news:T5Wdnbn8v-eemt7enZ2dnUVZ8qmdnZ2d@.giganews.com...
>
>