Question about sp_addscriptexec

Hi,
I'm running SQL Server 2000 EE SP3 on Windows Server 2003.
I have multiple named pull subscribers to a Transactional replication model.
I have written a script that adds and drops fields from several tables using
sp_repladdcolumn and sp_repldropcolumn. I also have some commands in my
script that are removing tables from the replication model. I also have some
commands that are adding new tables to the replication model.
After the commands that are adding and removing the fields and tables, I am
issuing a sp_refreshsubscriptions.
I am then starting the snapshot agent so that the subscribers will get the
new tables that I have added.
I then issue an sp_addscriptexec to run a script on the subscriber.
My question is why does this script that I am executing via the
sp_addscriptexec run on the subscriber before the snapshot ever gets applied
to the subscriber? I need to have the script run after the snapshot has been
created and delivered to the subscriber.
Thanks in advance,
Stephen
Probably because the sp_addscriptexec is added to the distribution database
before the snapshot is generated and the sync commands make it there, You
should perhaps use the post snapshot command for this.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Stephen Schissler" <StephenSchissler@.discussions.microsoft.com> wrote in
message news:9CD0B3BB-6EE6-46DF-8CDE-C8B860890EE1@.microsoft.com...
> Hi,
> I'm running SQL Server 2000 EE SP3 on Windows Server 2003.
> I have multiple named pull subscribers to a Transactional replication
model.
> I have written a script that adds and drops fields from several tables
using
> sp_repladdcolumn and sp_repldropcolumn. I also have some commands in my
> script that are removing tables from the replication model. I also have
some
> commands that are adding new tables to the replication model.
> After the commands that are adding and removing the fields and tables, I
am
> issuing a sp_refreshsubscriptions.
> I am then starting the snapshot agent so that the subscribers will get the
> new tables that I have added.
> I then issue an sp_addscriptexec to run a script on the subscriber.
> My question is why does this script that I am executing via the
> sp_addscriptexec run on the subscriber before the snapshot ever gets
applied
> to the subscriber? I need to have the script run after the snapshot has
been
> created and delivered to the subscriber.
> Thanks in advance,
> Stephen
|||I already have a post snapshot command tied to my replication publication.
Since I am already replicating to the subscriber and just adding new tables
and fields, it seems as though the post snapshot command that was orginally
tied to the publication does not get run. I'm saying this as I already have
a post snapshot script applied to my publication and it is not getting run
when I regen the snapshot to create the definitions of the new tables.
So, I do not think that adding the additional script as a post script will
get run either, but in any case, I do not want to tie this script to the
publication definition as I do not want this script to be run whenever a
snapshot has been applied.
Thanks again,
Stephen
"Hilary Cotter" wrote:

> Probably because the sp_addscriptexec is added to the distribution database
> before the snapshot is generated and the sync commands make it there, You
> should perhaps use the post snapshot command for this.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Stephen Schissler" <StephenSchissler@.discussions.microsoft.com> wrote in
> message news:9CD0B3BB-6EE6-46DF-8CDE-C8B860890EE1@.microsoft.com...
> model.
> using
> some
> am
> applied
> been
>
>
|||You might want to set your distribution job to run scheduled as opposed to
continuous, stop the log reader agent, and then have the sp_addscriptexec
command run as your final job step. Stop and start your distribution agent.
After the distribution agent has stopped, remove this last step, start up
your log reader agent.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Stephen Schissler" <StephenSchissler@.discussions.microsoft.com> wrote in
message news:E7C9D59C-D82B-412E-9B5B-55DA93574C79@.microsoft.com...
> I already have a post snapshot command tied to my replication publication.
> Since I am already replicating to the subscriber and just adding new
tables
> and fields, it seems as though the post snapshot command that was
orginally
> tied to the publication does not get run. I'm saying this as I already
have[vbcol=seagreen]
> a post snapshot script applied to my publication and it is not getting run
> when I regen the snapshot to create the definitions of the new tables.
> So, I do not think that adding the additional script as a post script will
> get run either, but in any case, I do not want to tie this script to the
> publication definition as I do not want this script to be run whenever a
> snapshot has been applied.
> Thanks again,
> Stephen
> "Hilary Cotter" wrote:
database[vbcol=seagreen]
You[vbcol=seagreen]
in[vbcol=seagreen]
my[vbcol=seagreen]
have[vbcol=seagreen]
I[vbcol=seagreen]
the[vbcol=seagreen]
has[vbcol=seagreen]

Question about snapshot replication and monitoring of msrepl_transactions in the dist.db

OK.
We have this 1 publisher db that is pushing out to two separate
subscribers (one is transactional the other is snapshot). In the
distribution db the publisher_database_id is going to be the same. We
monitor this transaction count by publisher id with the following (
Select count(1) from dbo.MSrepl_transactions where
publisher_database_id = 17). Now that we have added snapshot
replication to one subscriber and transactional to another we have
noticed that this transaction count is not correct. It always says that
there are like 100+ in there waiting, but this is not true. The
transactional publications are always up to date with 0 latency.
It was my understanding that snapshot replication literally just makes a
bcp and push's it over at whatever time you tell it to push. However,
it looks like these extra transactions sitting in my distribution
database have everything to do with the snapshot replication and not the
transactional replication. Does snapshot replication work differently
then i thought? Does snapshot replication actually post transactions to
the distribution db?
Thanks
-comb
what shows up in sp_browsereplcmds. I suspect what you will see there are
the commands which are used for the sync - i.e. to build the tables and
other objects on the subscriber, and the bcp the data there. IIRC the
distribution clean up agent does not clean these up until you are past the
retention period.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"combfilter" <asdf@.adsf.com> wrote in message
news:MPG.1e4953894a6972969896eb@.news.newsreader.co m...
> OK.
> We have this 1 publisher db that is pushing out to two separate
> subscribers (one is transactional the other is snapshot). In the
> distribution db the publisher_database_id is going to be the same. We
> monitor this transaction count by publisher id with the following (
> Select count(1) from dbo.MSrepl_transactions where
> publisher_database_id = 17). Now that we have added snapshot
> replication to one subscriber and transactional to another we have
> noticed that this transaction count is not correct. It always says that
> there are like 100+ in there waiting, but this is not true. The
> transactional publications are always up to date with 0 latency.
> It was my understanding that snapshot replication literally just makes a
> bcp and push's it over at whatever time you tell it to push. However,
> it looks like these extra transactions sitting in my distribution
> database have everything to do with the snapshot replication and not the
> transactional replication. Does snapshot replication work differently
> then i thought? Does snapshot replication actually post transactions to
> the distribution db?
> Thanks
> -comb
|||In article <Oq2WvQxJGHA.3064@.TK2MSFTNGP10.phx.gbl>,
hilary.cotter@.gmail.com says...
> what shows up in sp_browsereplcmds. I suspect what you will see there are
> the commands which are used for the sync - i.e. to build the tables and
> other objects on the subscriber, and the bcp the data there. IIRC the
> distribution clean up agent does not clean these up until you are past the
> retention period.
>
why would the bcp data be in the distribution db? wouldn't it just push
that across the net to the subscriber straight up as a .bcp file? why
would a snapshot need to put anything in the distribution db other then
"hey you need to push this .bcp across".
ok so what you are saying is that snapshot replication DOES actually
post transactions to the distribution db? I thought it just generated
the .bcp, idx and whatever that 3rd file is and pushed those across the
net with just a few instructions on where to put them.?
sp_browsereplcmds times out for me. We have a lot of subscribers on
this box. Is there anyway I can use that sp and just look at a certain
db id?
thanks.

question about job names

When I create a 'simple' transactional push replication 3 jobs are created.
As far as I know from studing books online I can either let SQL Server generate the jobs, and SQL Server determine the jobname (which is different with every time I let generate them), or I can create the jobs manually and use that jobs when I create publication and subscription.
What I like is that SQL Server generate the jobs with a name I define. Why is this not supported? Or do I miss something ?

Regards
Wolfgang KunkWhat is the reason you need a custom job name?|||

This is supported. You can't do this by clicking through the replication wizard. You can do this by executing the stored procedures to create the publication, articles, and subscriptions. I've done this many times.

Why would you want to?

1. Naming conventions

2. Providing better names than what you get by default

3. Someone has handed you a database full of garbage - i.e. table names with spaces, /, -, $, %, and all manner of other special characters that you want to strip out so that the engine doesn't freak out when it tries to create this stuff.

|||

Yes, this makes sense for article names.

But custom names for the agent jobs in MSDB is not supported. The names of these msdb jobs have nothing to do with the names of objects inside of a database. Please let me know if there's a business reason for needing to customize the actual MSDB job name for the agents, we can certainly file a bug/DCR on it.

|||

Well, I have several running in production that are not using the default job names. I routinely change these from the defaults. In fact, it has been several years since I deployed replication in a production environment and kept the default names. None of them ever conform to any of our naming conventions. The ones that always gave me troubles were all of the clean up jobs that I had to go back in and manually rename. Finally wrote a script to automate all of that stuff so now when I setup replication, it also renames all of the clean up jobs as well.

It is a royal pain when any changes have to be made, because SQL Server wants to either revert them back or in most cases will create another job and force fit the jobs names back again. I've always found it to be unreasonable that I can specify the name of absolutely everything across the replication engine, except the clean up jobs. It just has never been high on my priority list to ask for the change since there were a lot more important things to develop within the engine.

|||An example:
I like to implement an alert which stops the distribution agent.
I stop the job with "exec dbo.sp_stop_job <jobname>"
When I now change or recreate the replication the jobname changed automaticly and I need to change every other alert or job which references the jobname of the distribution agent!
That is a high administrative expenditure and it is error-prone.

If I can provide jobnames there is no need to change other jobs or alerts referencing that job!

Wolfgang|||Thanks for your feedback, I'll file a bug and see if we can get something for a future Yukon service pack, if not for next release. We do have some public procs that do as you want, but unfortunately they're not documented, and therefore not supported. I hope to have that changed in the future.|||

In SQL2005, we offer the following system procedures for starting\stopping replication agents:

sp_start|stoppublication_snapshot (at publisher)

sp_start|stop[merge]pushsubscription_agent (at publisher)

sp_start|stop[merge]pullsubscription_agent (at subscriber)

You can also pre-define a job with whatever name you choose and then *attach* a replication agent to it through the *@.job_name parameters of the replication system procedures but we have security reasons for not allowing users to specify any job names they want for replication jobs that we generate. Note that we will not clean up any jobs that you create before attaching a replication agent to it.

Will the new procedures be sufficient for your purposes?

-Raymond

|||Ok, Raymond spilled the beans. These are the procs I'm looking to get doc'd for public use. Right now they're unsupported, so I recommend not using them as they can change between now and the time they go public.|||OK, as soon as the procs are supported they will solve the example.
But it is only an example. In general I don't want to change references to jobs at all.
And I cannot see that providing a job name could be a security issue.

Wolfgang|||

You can use your own job names as long as you create the job beforehand and perform the cleanup afterwards. This was original usage scenario that the @.*job_name parameters were designed to address. Unfortunately, the meaning of those parameters got subverted into "let me choose whatever names I want for the jobs generated by replication because I want to start my jobs through T-SQL without 1) querying the job_id which is stored in replication system tables and 2) writing a program that uses the ActiveX controls". I can agree that this is a worthy scenario to support but unfortunately mixing the two had caused a vulnerability in our code where a mere db_owner of a publisher or subscriber database can choose to drop any jobs on the server (say distribution cleanup). It was very difficult for us to dig ourselves out of this hole while knowing folks like yourself will be upset so we create the procs in SQL2005 to control the agent jobs in a more secured manner. But then again, this seems to be a battle that we can't seem to win.

-Raymond

|||I still cannot see were the problem is. From my point of view it doesn't matter whether the jobname is generated automatically or given by a user. Internally you use the assigned job_id.

Wolfgang|||

I can mail you the exploit code where a mere db_owner of a publisher database can drop the distribution cleanup job on a < SQL2000 sp3 server although I doubt that will convince you.

-Raymond

|||

Kunk wrote:

I still cannot see were the problem is. From my point of view it doesn't matter whether the jobname is generated automatically or given by a user. Internally you use the assigned job_id.
Wolfgang

I have noticed, that when job name is assigned automatically for merge pull subscription, deleting that subscription causes deleting of appropriate job, but when I create subscription using script with custom job name, SQL Server leaves that job after deleting subscription.

I didn't find the reason...

|||Raymond stated exactly this behaviour in one of his former notes:

"You can also pre-define a job with whatever name you choose and then *attach* a replication agent to it through the *@.job_name

parameters of the replication system procedures but we have security

reasons for not allowing users to specify any job names they want for

replication jobs that we generate. Note that we will not clean up any

jobs that you create before attaching a replication agent to it."

As I don't now how the replication system works internally, it is hard to say why it works as it works. I only can say that the handling of replication jobs is not very comfortable. But that is only my personal opinion.

Wolfgang

question about job names

When I create a 'simple' transactional push replication 3 jobs are created.
As far as I know from studing books online I can either let SQL Server generate the jobs, and SQL Server determine the jobname (which is different with every time I let generate them), or I can create the jobs manually and use that jobs when I create publication and subscription.
What I like is that SQL Server generate the jobs with a name I define. Why is this not supported? Or do I miss something ?

Regards
Wolfgang Kunk

What is the reason you need a custom job name?|||

This is supported. You can't do this by clicking through the replication wizard. You can do this by executing the stored procedures to create the publication, articles, and subscriptions. I've done this many times.

Why would you want to?

1. Naming conventions

2. Providing better names than what you get by default

3. Someone has handed you a database full of garbage - i.e. table names with spaces, /, -, $, %, and all manner of other special characters that you want to strip out so that the engine doesn't freak out when it tries to create this stuff.

|||

Yes, this makes sense for article names.

But custom names for the agent jobs in MSDB is not supported. The names of these msdb jobs have nothing to do with the names of objects inside of a database. Please let me know if there's a business reason for needing to customize the actual MSDB job name for the agents, we can certainly file a bug/DCR on it.

|||

Well, I have several running in production that are not using the default job names. I routinely change these from the defaults. In fact, it has been several years since I deployed replication in a production environment and kept the default names. None of them ever conform to any of our naming conventions. The ones that always gave me troubles were all of the clean up jobs that I had to go back in and manually rename. Finally wrote a script to automate all of that stuff so now when I setup replication, it also renames all of the clean up jobs as well.

It is a royal pain when any changes have to be made, because SQL Server wants to either revert them back or in most cases will create another job and force fit the jobs names back again. I've always found it to be unreasonable that I can specify the name of absolutely everything across the replication engine, except the clean up jobs. It just has never been high on my priority list to ask for the change since there were a lot more important things to develop within the engine.

|||An example:
I like to implement an alert which stops the distribution agent.
I stop the job with "exec dbo.sp_stop_job <jobname>"
When I now change or recreate the replication the jobname changed automaticly and I need to change every other alert or job which references the jobname of the distribution agent!
That is a high administrative expenditure and it is error-prone.

If I can provide jobnames there is no need to change other jobs or alerts referencing that job!

Wolfgang

|||Thanks for your feedback, I'll file a bug and see if we can get something for a future Yukon service pack, if not for next release. We do have some public procs that do as you want, but unfortunately they're not documented, and therefore not supported. I hope to have that changed in the future.|||

In SQL2005, we offer the following system procedures for starting\stopping replication agents:

sp_start|stoppublication_snapshot (at publisher)

sp_start|stop[merge]pushsubscription_agent (at publisher)

sp_start|stop[merge]pullsubscription_agent (at subscriber)

You can also pre-define a job with whatever name you choose and then *attach* a replication agent to it through the *@.job_name parameters of the replication system procedures but we have security reasons for not allowing users to specify any job names they want for replication jobs that we generate. Note that we will not clean up any jobs that you create before attaching a replication agent to it.

Will the new procedures be sufficient for your purposes?

-Raymond

|||Ok, Raymond spilled the beans. These are the procs I'm looking to get doc'd for public use. Right now they're unsupported, so I recommend not using them as they can change between now and the time they go public.|||OK, as soon as the procs are supported they will solve the example.
But it is only an example. In general I don't want to change references to jobs at all.
And I cannot see that providing a job name could be a security issue.

Wolfgang

|||

You can use your own job names as long as you create the job beforehand and perform the cleanup afterwards. This was original usage scenario that the @.*job_name parameters were designed to address. Unfortunately, the meaning of those parameters got subverted into "let me choose whatever names I want for the jobs generated by replication because I want to start my jobs through T-SQL without 1) querying the job_id which is stored in replication system tables and 2) writing a program that uses the ActiveX controls". I can agree that this is a worthy scenario to support but unfortunately mixing the two had caused a vulnerability in our code where a mere db_owner of a publisher or subscriber database can choose to drop any jobs on the server (say distribution cleanup). It was very difficult for us to dig ourselves out of this hole while knowing folks like yourself will be upset so we create the procs in SQL2005 to control the agent jobs in a more secured manner. But then again, this seems to be a battle that we can't seem to win.

-Raymond

|||I still cannot see were the problem is. From my point of view it doesn't matter whether the jobname is generated automatically or given by a user. Internally you use the assigned job_id.

Wolfgang

|||

I can mail you the exploit code where a mere db_owner of a publisher database can drop the distribution cleanup job on a < SQL2000 sp3 server although I doubt that will convince you.

-Raymond

|||

Kunk wrote:

I still cannot see were the problem is. From my point of view it doesn't matter whether the jobname is generated automatically or given by a user. Internally you use the assigned job_id.
Wolfgang

I have noticed, that when job name is assigned automatically for merge pull subscription, deleting that subscription causes deleting of appropriate job, but when I create subscription using script with custom job name, SQL Server leaves that job after deleting subscription.

I didn't find the reason...

|||Raymond stated exactly this behaviour in one of his former notes:

"You can also pre-define a job with whatever name you choose and then *attach* a replication agent to it through the *@.job_name parameters of the replication system procedures but we have security reasons for not allowing users to specify any job names they want for replication jobs that we generate.Note that we will not clean up any jobs that you create before attaching a replication agent to it."

As I don't now how the replication system works internally, it is hard to say why it works as it works. I only can say that the handling of replication jobs is not very comfortable. But that is only my personal opinion.

Wolfgang
sql

question about job names

When I create a 'simple' transactional push replication 3 jobs are created.
As far as I know from studing books online I can either let SQL Server generate the jobs, and SQL Server determine the jobname (which is different with every time I let generate them), or I can create the jobs manually and use that jobs when I create publication and subscription.
What I like is that SQL Server generate the jobs with a name I define. Why is this not supported? Or do I miss something ?

Regards
Wolfgang KunkWhat is the reason you need a custom job name?|||

This is supported. You can't do this by clicking through the replication wizard. You can do this by executing the stored procedures to create the publication, articles, and subscriptions. I've done this many times.

Why would you want to?

1. Naming conventions

2. Providing better names than what you get by default

3. Someone has handed you a database full of garbage - i.e. table names with spaces, /, -, $, %, and all manner of other special characters that you want to strip out so that the engine doesn't freak out when it tries to create this stuff.

|||

Yes, this makes sense for article names.

But custom names for the agent jobs in MSDB is not supported. The names of these msdb jobs have nothing to do with the names of objects inside of a database. Please let me know if there's a business reason for needing to customize the actual MSDB job name for the agents, we can certainly file a bug/DCR on it.

|||

Well, I have several running in production that are not using the default job names. I routinely change these from the defaults. In fact, it has been several years since I deployed replication in a production environment and kept the default names. None of them ever conform to any of our naming conventions. The ones that always gave me troubles were all of the clean up jobs that I had to go back in and manually rename. Finally wrote a script to automate all of that stuff so now when I setup replication, it also renames all of the clean up jobs as well.

It is a royal pain when any changes have to be made, because SQL Server wants to either revert them back or in most cases will create another job and force fit the jobs names back again. I've always found it to be unreasonable that I can specify the name of absolutely everything across the replication engine, except the clean up jobs. It just has never been high on my priority list to ask for the change since there were a lot more important things to develop within the engine.

|||An example:
I like to implement an alert which stops the distribution agent.
I stop the job with "exec dbo.sp_stop_job <jobname>"
When I now change or recreate the replication the jobname changed automaticly and I need to change every other alert or job which references the jobname of the distribution agent!
That is a high administrative expenditure and it is error-prone.

If I can provide jobnames there is no need to change other jobs or alerts referencing that job!

Wolfgang|||Thanks for your feedback, I'll file a bug and see if we can get something for a future Yukon service pack, if not for next release. We do have some public procs that do as you want, but unfortunately they're not documented, and therefore not supported. I hope to have that changed in the future.|||

In SQL2005, we offer the following system procedures for starting\stopping replication agents:

sp_start|stoppublication_snapshot (at publisher)

sp_start|stop[merge]pushsubscription_agent (at publisher)

sp_start|stop[merge]pullsubscription_agent (at subscriber)

You can also pre-define a job with whatever name you choose and then *attach* a replication agent to it through the *@.job_name parameters of the replication system procedures but we have security reasons for not allowing users to specify any job names they want for replication jobs that we generate. Note that we will not clean up any jobs that you create before attaching a replication agent to it.

Will the new procedures be sufficient for your purposes?

-Raymond

|||Ok, Raymond spilled the beans. These are the procs I'm looking to get doc'd for public use. Right now they're unsupported, so I recommend not using them as they can change between now and the time they go public.|||OK, as soon as the procs are supported they will solve the example.
But it is only an example. In general I don't want to change references to jobs at all.
And I cannot see that providing a job name could be a security issue.

Wolfgang|||

You can use your own job names as long as you create the job beforehand and perform the cleanup afterwards. This was original usage scenario that the @.*job_name parameters were designed to address. Unfortunately, the meaning of those parameters got subverted into "let me choose whatever names I want for the jobs generated by replication because I want to start my jobs through T-SQL without 1) querying the job_id which is stored in replication system tables and 2) writing a program that uses the ActiveX controls". I can agree that this is a worthy scenario to support but unfortunately mixing the two had caused a vulnerability in our code where a mere db_owner of a publisher or subscriber database can choose to drop any jobs on the server (say distribution cleanup). It was very difficult for us to dig ourselves out of this hole while knowing folks like yourself will be upset so we create the procs in SQL2005 to control the agent jobs in a more secured manner. But then again, this seems to be a battle that we can't seem to win.

-Raymond

|||I still cannot see were the problem is. From my point of view it doesn't matter whether the jobname is generated automatically or given by a user. Internally you use the assigned job_id.

Wolfgang|||

I can mail you the exploit code where a mere db_owner of a publisher database can drop the distribution cleanup job on a < SQL2000 sp3 server although I doubt that will convince you.

-Raymond

|||

Kunk wrote:

I still cannot see were the problem is. From my point of view it doesn't matter whether the jobname is generated automatically or given by a user. Internally you use the assigned job_id.
Wolfgang

I have noticed, that when job name is assigned automatically for merge pull subscription, deleting that subscription causes deleting of appropriate job, but when I create subscription using script with custom job name, SQL Server leaves that job after deleting subscription.

I didn't find the reason...

|||Raymond stated exactly this behaviour in one of his former notes:

"You can also pre-define a job with whatever name you choose and then *attach* a replication agent to it through the *@.job_name

parameters of the replication system procedures but we have security

reasons for not allowing users to specify any job names they want for

replication jobs that we generate. Note that we will not clean up any

jobs that you create before attaching a replication agent to it."

As I don't now how the replication system works internally, it is hard to say why it works as it works. I only can say that the handling of replication jobs is not very comfortable. But that is only my personal opinion.

Wolfgang

Question : Transactional Replication Rollback ?

We have a sql2k db as a Distributor, with a few servers geographically
scattered acting as subscribers (backup). I'm setting up transaction
replication, however, is there a way to rollback in the event of
dataloss on the Distributor ?
Eg : 'delete tblProducts' run on the distributor. Wouldn't this
effectively delete tblProducts on every subscriber ? Is there anyway
to rollback in such an event.
Thanks,
Amit Chandel
Amit,
presumably when you say Distributor, you mean Publisher/Distributor?
If you run the TSQL "Delete * from Table1" on the publisher this will be
propagated via the logreader and distribution agents to the subscriber.
Turning off these agents before the command gets to the subscriber will
prevent the delete. Once it has occurred at the subscriber, you can not roll
it back. One posibility is you could back up the transaction log and do a
point-in-time restore. If the command is potentially 'dodgy' then you could
also wrap it in a transaction with normal error trapping and ROLLBACK
statements. If you give the transaction a name, it is possible to do a
restore as mentioned above, but not to a point in time, rather to just
before the named transaction was run.
HTH,
Paul Ibison