Is there another way out?

Guys,
We have a transactional replication set up with a single publisher and
a single subscriber.
Recently, replication failed due to the following reason:
Data, erroneously, was deleted from subscriber. Then, to make the
publisher and subscriber synch, the same data was deleted from
publisher.
At that point, the publisher, as it should, attempted to delete the
data in the subscriber. But since the data is not there, the attempt
failed, and replication failed.
I tried to restart the agent, but replication kept failing. Since
nothing worked, I just deleted the subscription and recreated it. The
replication then started, but since it had to go through all the steps
again (i.e. Snapshot ...), it took us 2 hours to get the data back in
synch.
Luckily this happened in the testing environment. If it would be
production, we would be in trouble, as availability is our #1 concern.
Would anyone know of any other (i.e. more elegant) way I could've
solved this problem?
The only other idea I had was the following: It is possible that the
data which the publisher plans to delete is temporarily stored in some
file and if that file is located and deleted, and then the agent is
restarted, it could possibly work - but, I could not locate any such
files - and this is a completely hypothetical idea.
Any suggestions would be appreciated.
Thanks
have a look at the continue on data consistency error profile.
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
"sql_er" <sql_er@.yahoo.com> wrote in message
news:1165954222.427226.20530@.j44g2000cwa.googlegro ups.com...
> Guys,
> We have a transactional replication set up with a single publisher and
> a single subscriber.
> Recently, replication failed due to the following reason:
> Data, erroneously, was deleted from subscriber. Then, to make the
> publisher and subscriber synch, the same data was deleted from
> publisher.
> At that point, the publisher, as it should, attempted to delete the
> data in the subscriber. But since the data is not there, the attempt
> failed, and replication failed.
> I tried to restart the agent, but replication kept failing. Since
> nothing worked, I just deleted the subscription and recreated it. The
> replication then started, but since it had to go through all the steps
> again (i.e. Snapshot ...), it took us 2 hours to get the data back in
> synch.
> Luckily this happened in the testing environment. If it would be
> production, we would be in trouble, as availability is our #1 concern.
> Would anyone know of any other (i.e. more elegant) way I could've
> solved this problem?
> The only other idea I had was the following: It is possible that the
> data which the publisher plans to delete is temporarily stored in some
> file and if that file is located and deleted, and then the agent is
> restarted, it could possibly work - but, I could not locate any such
> files - and this is a completely hypothetical idea.
>
> Any suggestions would be appreciated.
>
> Thanks
>