| Author |
Topic |
|
Ruskin
Starting Member
13 Posts |
 Posted - 2003-11-14 : 09:26:52
|
I have a Merge Replication on a DB with 11 articles in it. Every table is replicated just fine except one. No errors are reported, no retry is ever scheduled. From everything I've looked at, I wonder if there's something in the way the rows are added to the table.Is there any way, through bulk inserts, transactions, whatever, to insert rows into a replicated table and have those rows NOT replicate? There are no DISABLE TRIGGER clauses in the queries. This table is updated with a bulk insert and then a deduplication routine (DELETE FROM...) is run against it. There are always 900 or so more rows on the source table than there are on the destination table when its all "done"  thanks, |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-11-14 : 13:02:06
|
| I don't know why you are encountering the problem. But have you tried recreating replication on that server in case something is messed up? You can easily script out the DROP and CREATE commands using the General script option if you right click on the publication. Are any transactions replicated from that table? Try a simple insert to see if it gets replicated.Tara |
 |
|
|
Ruskin
Starting Member
13 Posts |
Posted - 2003-11-14 : 14:40:30
|
| I have deleted and rebuilt the publications and subscription a few times (I'm getting pretty good at it).The source table is updated by a DTS package with a transformation in it. The de-duplication step of the package was in a transaction, but I removed the BEGIN and COMMIT TRAN clauses of that query.The data comes from an as/400 database and initially gets copied to a staging table. From there we run a transformation on the staging table to the productions table (the production is the "source" table in the replication). Some of these transformations have VB Script properties because on the as/400 for instance, they have two fields for LastUpdateDate and LastUpdateTime which we are consolidating into a single DateTime field.I'm just wondering if this transformation with the VBScript is somehow under the hood turning off the INSERT, UPDATE, and DELETE triggers needed by Merge Replication? |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-11-14 : 14:51:53
|
| Run SQL Profiler to see what is actually occurring on the database server.Tara |
|
|
|
Ruskin
Starting Member
13 Posts |
Posted - 2003-11-14 : 14:56:11
|
| ok, I'll give that a shot. Right now, I've reinitialized the replication from the snapshot (going to take a while: hundreds of thousands of rows from Kansas City, MO to Miami, FL), which always gets things back in synch.once that's done, I'll run a trace on the problem DTS. |
|
|
|
Ruskin
Starting Member
13 Posts |
Posted - 2003-11-14 : 16:07:47
|
| I ran the trace, and the data is being inserted into the table with "INSERT BULK" statements. Does that not replicate? |
|
|
|
Ruskin
Starting Member
13 Posts |
Posted - 2003-11-14 : 16:15:36
|
| I'm going to try clearing the Use Fast Load option of the Transform Data Task according to the following MS article:http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q275/6/80.ASP&NoWebContent=1&NoWebContent=1 |
|
|
|
ranjisri
Starting Member
4 Posts |
Posted - 2004-02-25 : 10:07:00
|
| Thanks Ruskin. I had a very similar problem. I unchecked the fast load option on the Transform Data Task and merge replication seems to be running fine. |
|
|
|
Ruskin
Starting Member
13 Posts |
Posted - 2004-02-25 : 10:09:57
|
| Cool, ranjisri! This is why people should post their own solutions back to MBs if they find solutions to their own posted problem:) |
|
|
|
|
Merge Repl does not replicate one article