[SS2K5] : Dynamically construct a FROM statement with current SCHEMA

Hi,

I've got a DB with some schemas.

There's same tables under these schemas as for example :

MySchema1.MyTable1

MySchema2.MyTable1

I wrote CRUD stored procedures for these tables.

I'd like to dynamically create the FROM statement inside the stored procedures by getting the schema name from the current context.

Kind of :

FROM SCHEMA_NAME().MyTable1

So I'll have one generic stored procedure for MyTable1.

This stored proc will be under the DB level and will not have to be replicate under all the schemas.

Is it possible ?

Thanks for any help.

BERTRANDR

Sure, sp_executesql is such a utility to run dynamic sql. Basically you construct a SQL string(NVARCHAR) with parameters first, then use sp_executesql to execute it. Look at Book Online for details.|||Why do you want to use a generic SP? Using dynamic SQL has lot of issues - complexity, performance (it depends on the case), security risks, permissions management, debugging pain, ownership chaining issues in your case etc. You should create a SP in each schema that handles the modifications for each table. This is much more robust, simpler to manage, debug, code etc.|||

Well my point is that I don t want to duplicate objects that have the same purposes and do exactly the same things for the same table but under differents schemas.

I thought it was the best thing to do .

But maybe am I wrong ..

[SS2K5] : Dynamically construct a FROM statement with current SCHEMA

Hi,

I've got a DB with some schemas.

There's same tables under these schemas as for example :

MySchema1.MyTable1

MySchema2.MyTable1

I wrote CRUD stored procedures for these tables.

I'd like to dynamically create the FROM statement inside the stored procedures by getting the schema name from the current context.

Kind of :

FROM SCHEMA_NAME().MyTable1

So I'll have one generic stored procedure for MyTable1.

This stored proc will be under the DB level and will not have to be replicate under all the schemas.

Is it possible ?

Thanks for any help.

BERTRANDR

Sure, sp_executesql is such a utility to run dynamic sql. Basically you construct a SQL string(NVARCHAR) with parameters first, then use sp_executesql to execute it. Look at Book Online for details.|||Why do you want to use a generic SP? Using dynamic SQL has lot of issues - complexity, performance (it depends on the case), security risks, permissions management, debugging pain, ownership chaining issues in your case etc. You should create a SP in each schema that handles the modifications for each table. This is much more robust, simpler to manage, debug, code etc.|||

Well my point is that I don t want to duplicate objects that have the same purposes and do exactly the same things for the same table but under differents schemas.

I thought it was the best thing to do .

But maybe am I wrong ..

@max_concurrent_merge

I have a merge publication (dynamically filtered). Subscriptions are
all anonymous (all run at the subscriber) and run continuously.
What effect does the publication option @.max_concurrent_merge have on
a replication topology such as this? Also known as the "Publication
Properties | Subscriptions tab | "Limit the number of concurrent merge
processes to the following" setting . . .
I noticed in a test environment when I set it to 1 my 2 anonymous
subscribers are still able to connect and reach "no data to be
merged". . . does setting this physically limit the number of "merge
activity" or the number of "merge agent connections" or something
else? I believe my testing shows it doens't limit the connections, but
maybe it does something w/ the "merge activity" under the hood?
Any help is greatly appreciated . . .
Matt
It limits the number of simultaneous merge agents that can run. The default
for this is 10, so if you have 20 subscribers running continuously, only 10
of them would be running simultaneously and the rest would be queued.
For 2 subscribers you should not have to worry about it.
Please refer to this link for a more indepth discussion of this.
http://www.microsoft.com/technet/pro.../mergperf.mspx
"Matt" <la_la_looey@.yahoo.com> wrote in message
news:a0313d3.0404210946.4e767ee9@.posting.google.co m...
> I have a merge publication (dynamically filtered). Subscriptions are
> all anonymous (all run at the subscriber) and run continuously.
> What effect does the publication option @.max_concurrent_merge have on
> a replication topology such as this? Also known as the "Publication
> Properties | Subscriptions tab | "Limit the number of concurrent merge
> processes to the following" setting . . .
> I noticed in a test environment when I set it to 1 my 2 anonymous
> subscribers are still able to connect and reach "no data to be
> merged". . . does setting this physically limit the number of "merge
> activity" or the number of "merge agent connections" or something
> else? I believe my testing shows it doens't limit the connections, but
> maybe it does something w/ the "merge activity" under the hood?
> Any help is greatly appreciated . . .
> Matt
|||2 subscribers was my test lab . . . I actually have over 100.
I believe after extended testing, I see this setting simply controls
the number of connections . . . so, if you have your agent set to run
continuously, other agents would "starve."
"Hilary Cotter" <hilaryk@.att.net> wrote in message news:<#HF4BTBKEHA.2556@.TK2MSFTNGP11.phx.gbl>...[vbcol=seagreen]
> It limits the number of simultaneous merge agents that can run. The default
> for this is 10, so if you have 20 subscribers running continuously, only 10
> of them would be running simultaneously and the rest would be queued.
> For 2 subscribers you should not have to worry about it.
> Please refer to this link for a more indepth discussion of this.
> http://www.microsoft.com/technet/pro.../mergperf.mspx
>
> "Matt" <la_la_looey@.yahoo.com> wrote in message
> news:a0313d3.0404210946.4e767ee9@.posting.google.co m...
|||not so, they are queued until the others finished. sort of like a round
robin. Check out the link for more info.
"Matt" <la_la_looey@.yahoo.com> wrote in message
news:a0313d3.0404220441.15777f5c@.posting.google.co m...
> 2 subscribers was my test lab . . . I actually have over 100.
> I believe after extended testing, I see this setting simply controls
> the number of connections . . . so, if you have your agent set to run
> continuously, other agents would "starve."
>
> "Hilary Cotter" <hilaryk@.att.net> wrote in message
news:<#HF4BTBKEHA.2556@.TK2MSFTNGP11.phx.gbl>...[vbcol=seagreen]
default[vbcol=seagreen]
10[vbcol=seagreen]
http://www.microsoft.com/technet/pro.../mergperf.mspx[vbcol=seagreen]