Hi
We've got a problen in a customer with SQL Server 2000 SP3 and merge
replication with PocketPC
We have some triggers FOR UPDATE on the same field used to distribute in
replication settings, so I suspect sometimes our triggers didn't work, and
sometimes the first trigger that has been executed were the replication
trigger.
Can I use the sp_settriggerorder to set the order to execute, setting the
replication trihgger as last in execution?
Thanks
Yes you can, I normally make them execute first though.
Hilary Cotter
Director of Text Mining and Database Strategy
RelevantNOISE.Com - Dedicated to mining blogs for business intelligence.
This posting is my own and doesn't necessarily represent RelevantNoise's
positions, strategies or opinions.
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
"Ricardo Snchez" <Ricardo Snchez@.discussions.microsoft.com> wrote in
message news:2BA27F4E-0454-4DC0-9DC2-46CD14C7E368@.microsoft.com...
> Hi
> We've got a problen in a customer with SQL Server 2000 SP3 and merge
> replication with PocketPC
> We have some triggers FOR UPDATE on the same field used to distribute in
> replication settings, so I suspect sometimes our triggers didn't work, and
> sometimes the first trigger that has been executed were the replication
> trigger.
> Can I use the sp_settriggerorder to set the order to execute, setting the
> replication trihgger as last in execution?
> Thanks
sql
Showing posts with label order. Show all posts
Showing posts with label order. Show all posts
Monday, March 26, 2012
Merge replication very very slow
You could enable logging as per this article:
http://support.microsoft.com/?id=312292 in order to try
to get more info.
To troubleshoot connectivity issues:
(a) run a ping -t for a day and then look at the
statistics to see if a hicup occured.
(b) You could run this keep alive script which will tell
you exactly when you get a failure. Save this as
c:\keepalive.sql
WHILE 1<>2
BEGIN
SELECT GETDATE()
WAITFOR DELAY '00:00:01'
END
GO
Here is the batch file that Hilary posted up a while back
to run this script:
osql -S hilary2kp -E -i c:\keepalive.sql -n
date /t
time /t
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
I'm not convinced that this is a network error. I think it could be that the
merge agent is busy processing the articles and has not completed within the
inactivity threshold and the error has resolved as a general network error.
Logging will help you to determine exactly what the problem is, but you
should bump up the QueryTimeout values and the inactivity threshold levels
in hopes that the added time interval your merge agent has to work with will
allow it to successfully complete.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:1d1201c4d7b9$9a29f8a0$a501280a@.phx.gbl...
> You could enable logging as per this article:
> http://support.microsoft.com/?id=312292 in order to try
> to get more info.
> To troubleshoot connectivity issues:
> (a) run a ping -t for a day and then look at the
> statistics to see if a hicup occured.
> (b) You could run this keep alive script which will tell
> you exactly when you get a failure. Save this as
> c:\keepalive.sql
>
> WHILE 1<>2
> BEGIN
> SELECT GETDATE()
> WAITFOR DELAY '00:00:01'
> END
> GO
> Here is the batch file that Hilary posted up a while back
> to run this script:
> osql -S hilary2kp -E -i c:\keepalive.sql -n
> date /t
> time /t
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
http://support.microsoft.com/?id=312292 in order to try
to get more info.
To troubleshoot connectivity issues:
(a) run a ping -t for a day and then look at the
statistics to see if a hicup occured.
(b) You could run this keep alive script which will tell
you exactly when you get a failure. Save this as
c:\keepalive.sql
WHILE 1<>2
BEGIN
SELECT GETDATE()
WAITFOR DELAY '00:00:01'
END
GO
Here is the batch file that Hilary posted up a while back
to run this script:
osql -S hilary2kp -E -i c:\keepalive.sql -n
date /t
time /t
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
I'm not convinced that this is a network error. I think it could be that the
merge agent is busy processing the articles and has not completed within the
inactivity threshold and the error has resolved as a general network error.
Logging will help you to determine exactly what the problem is, but you
should bump up the QueryTimeout values and the inactivity threshold levels
in hopes that the added time interval your merge agent has to work with will
allow it to successfully complete.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:1d1201c4d7b9$9a29f8a0$a501280a@.phx.gbl...
> You could enable logging as per this article:
> http://support.microsoft.com/?id=312292 in order to try
> to get more info.
> To troubleshoot connectivity issues:
> (a) run a ping -t for a day and then look at the
> statistics to see if a hicup occured.
> (b) You could run this keep alive script which will tell
> you exactly when you get a failure. Save this as
> c:\keepalive.sql
>
> WHILE 1<>2
> BEGIN
> SELECT GETDATE()
> WAITFOR DELAY '00:00:01'
> END
> GO
> Here is the batch file that Hilary posted up a while back
> to run this script:
> osql -S hilary2kp -E -i c:\keepalive.sql -n
> date /t
> time /t
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
Merge Replication updating SP3 to SP4
Gurus,
I am planning to update SP3 to SP4 on a replicated server.
A- Please correct me if i wrong in order.
1- Apply SP4 on Publisher / Distributor (on single box)
2- All subscribers.
B- As per my knowledge there are no issues while applying SP4. Is there any
known issue while applying the sp4 has to be taken care of?
TIA
Regards
Javed Iqbal
Javed,
I agree with the order. I've had a search of this newsgroup (using Google
Groups) to check for sp4 and there are hardly any reported errors so far.
The main on e is
http://groups.google.com/group/micro...85 a5a37097d4
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
I am planning to update SP3 to SP4 on a replicated server.
A- Please correct me if i wrong in order.
1- Apply SP4 on Publisher / Distributor (on single box)
2- All subscribers.
B- As per my knowledge there are no issues while applying SP4. Is there any
known issue while applying the sp4 has to be taken care of?
TIA
Regards
Javed Iqbal
Javed,
I agree with the order. I've had a search of this newsgroup (using Google
Groups) to check for sp4 and there are hardly any reported errors so far.
The main on e is
http://groups.google.com/group/micro...85 a5a37097d4
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Wednesday, March 7, 2012
Merge Replication does not apply changes in original order!
Has anyone noticed that Merge Replication does not apply changes in original
order?
This causes foreign keys errors but I fixed that by making the foreign keys
'not for replication'.
It also causes unique index errors if I am manipulating the unique values in
an exact sequence - anyone have a solution to this one?
That's correct!
I'm not exactly sure what order it will apply the changes in however. But
what it does is gathers up the changes, figures out what to apply where, and
then applies it one by one. If there is a pk/fk/GodKnowsWhat violation in
the initial attempt, the modification goes into a queue and when the merge
agent has completed the initial pass, it will retry the failures another
time.
For the majority of the cases, this second (or third, forth, etc) retry will
succeed. Sometimes you need to bump up the generationsperbatch switches to
2000 for this to succeed.
Merge replication in SQL 2005 will apply changes which belong to related
tables together in the same batch boundary so you don't have to worry about
this anymore.
Also becareful that you don't enforce cascading updates and deletes for
replication as this can get you into trouble.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim Breffni" <Jim Breffni@.discussions.microsoft.com> wrote in message
news:F55EE9FB-7733-4EDD-8E2B-A439978D3924@.microsoft.com...
> Has anyone noticed that Merge Replication does not apply changes in
original
> order?
> This causes foreign keys errors but I fixed that by making the foreign
keys
> 'not for replication'.
> It also causes unique index errors if I am manipulating the unique values
in
> an exact sequence - anyone have a solution to this one?
|||Thanks Hilary - where do I set the checkSortOrder generationsperbatch switch?
Jim.
"Hilary Cotter" wrote:
> That's correct!
> I'm not exactly sure what order it will apply the changes in however. But
> what it does is gathers up the changes, figures out what to apply where, and
> then applies it one by one. If there is a pk/fk/GodKnowsWhat violation in
> the initial attempt, the modification goes into a queue and when the merge
> agent has completed the initial pass, it will retry the failures another
> time.
> For the majority of the cases, this second (or third, forth, etc) retry will
> succeed. Sometimes you need to bump up the generationsperbatch switches to
> 2000 for this to succeed.
> Merge replication in SQL 2005 will apply changes which belong to related
> tables together in the same batch boundary so you don't have to worry about
> this anymore.
> Also becareful that you don't enforce cascading updates and deletes for
> replication as this can get you into trouble.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "Jim Breffni" <Jim Breffni@.discussions.microsoft.com> wrote in message
> news:F55EE9FB-7733-4EDD-8E2B-A439978D3924@.microsoft.com...
> original
> keys
> in
>
>
|||you don't. What you do is make the generationsperbatch switches very large
in hopes that the pk fk modifications will occur in the same batch.
You should set
MaxDownloadChanges
MaxUploadChanges
UploadGenerationsPerBatch
DownloadGenerationsPerBatch
UploadReadChangesPerBatch
DownloadReadChangesPerBatch
UploadWriteChangesPerBatch
DownloadWriteChangesPerBatch
to 2000
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim Breffni" <JimBreffni@.discussions.microsoft.com> wrote in message
news:BD122CA6-5721-428B-8F1E-791E99CE1E72@.microsoft.com...
> Thanks Hilary - where do I set the checkSortOrder generationsperbatch
switch?[vbcol=seagreen]
>
> Jim.
>
> "Hilary Cotter" wrote:
But[vbcol=seagreen]
and[vbcol=seagreen]
in[vbcol=seagreen]
merge[vbcol=seagreen]
will[vbcol=seagreen]
to[vbcol=seagreen]
about[vbcol=seagreen]
values[vbcol=seagreen]
order?
This causes foreign keys errors but I fixed that by making the foreign keys
'not for replication'.
It also causes unique index errors if I am manipulating the unique values in
an exact sequence - anyone have a solution to this one?
That's correct!
I'm not exactly sure what order it will apply the changes in however. But
what it does is gathers up the changes, figures out what to apply where, and
then applies it one by one. If there is a pk/fk/GodKnowsWhat violation in
the initial attempt, the modification goes into a queue and when the merge
agent has completed the initial pass, it will retry the failures another
time.
For the majority of the cases, this second (or third, forth, etc) retry will
succeed. Sometimes you need to bump up the generationsperbatch switches to
2000 for this to succeed.
Merge replication in SQL 2005 will apply changes which belong to related
tables together in the same batch boundary so you don't have to worry about
this anymore.
Also becareful that you don't enforce cascading updates and deletes for
replication as this can get you into trouble.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim Breffni" <Jim Breffni@.discussions.microsoft.com> wrote in message
news:F55EE9FB-7733-4EDD-8E2B-A439978D3924@.microsoft.com...
> Has anyone noticed that Merge Replication does not apply changes in
original
> order?
> This causes foreign keys errors but I fixed that by making the foreign
keys
> 'not for replication'.
> It also causes unique index errors if I am manipulating the unique values
in
> an exact sequence - anyone have a solution to this one?
|||Thanks Hilary - where do I set the checkSortOrder generationsperbatch switch?
Jim.
"Hilary Cotter" wrote:
> That's correct!
> I'm not exactly sure what order it will apply the changes in however. But
> what it does is gathers up the changes, figures out what to apply where, and
> then applies it one by one. If there is a pk/fk/GodKnowsWhat violation in
> the initial attempt, the modification goes into a queue and when the merge
> agent has completed the initial pass, it will retry the failures another
> time.
> For the majority of the cases, this second (or third, forth, etc) retry will
> succeed. Sometimes you need to bump up the generationsperbatch switches to
> 2000 for this to succeed.
> Merge replication in SQL 2005 will apply changes which belong to related
> tables together in the same batch boundary so you don't have to worry about
> this anymore.
> Also becareful that you don't enforce cascading updates and deletes for
> replication as this can get you into trouble.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> "Jim Breffni" <Jim Breffni@.discussions.microsoft.com> wrote in message
> news:F55EE9FB-7733-4EDD-8E2B-A439978D3924@.microsoft.com...
> original
> keys
> in
>
>
|||you don't. What you do is make the generationsperbatch switches very large
in hopes that the pk fk modifications will occur in the same batch.
You should set
MaxDownloadChanges
MaxUploadChanges
UploadGenerationsPerBatch
DownloadGenerationsPerBatch
UploadReadChangesPerBatch
DownloadReadChangesPerBatch
UploadWriteChangesPerBatch
DownloadWriteChangesPerBatch
to 2000
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jim Breffni" <JimBreffni@.discussions.microsoft.com> wrote in message
news:BD122CA6-5721-428B-8F1E-791E99CE1E72@.microsoft.com...
> Thanks Hilary - where do I set the checkSortOrder generationsperbatch
switch?[vbcol=seagreen]
>
> Jim.
>
> "Hilary Cotter" wrote:
But[vbcol=seagreen]
and[vbcol=seagreen]
in[vbcol=seagreen]
merge[vbcol=seagreen]
will[vbcol=seagreen]
to[vbcol=seagreen]
about[vbcol=seagreen]
values[vbcol=seagreen]
Merge Replication deployment model
In order to deploy the replication implementation along with the software that has been created,how to package the correct set of necessary assemblies along with our client to ensure that the software can function correctly?
While trying to include the SQL Server assemblies that we are using from the SDK directory, we get some internal security token errors.
Please also suggest what would be the recommended deployment model for stand-alone clients which are replicating between a local and remote server where the local doesn't include an install of the SQL management tools? (It will have express.)
What are the assembiles you are getting error on?If your client is going to install SQL Express (with replication components) before your application will be installed, you will not have problems.
Also you could make SQL Express as a pre-requisite when you publish and that way the client will be able to install Express and then your application will not have any problems with dependencies.
Subscribe to:
Comments (Atom)