Publication not sending records (from two pub items) down to Oracle Lite

Question

Hi there,
I have several publication items that are limited by queries. This query limits the data coming back to a time span of several days. When I run this limiting query in SQL Developer against the main database, the query brings back several rows.
There are two tables on the device, however, does not receive any rows upon first synchronization. I know that all of the publication items containing this limiting query have worked correctly in the past (on several devices over the last month).
Any ideas? Is there something that I can look for in the server logs to indicate why this publication did not transfer any records for only these two publication items? All of the other publications seemed to have worked correctly, and they are actually driven off the same limiting query as the problem publication.
Allen
Edited by: AllenS on Sep 24, 2008 11:27 AM

Answer 1

we have a similar issue with some of our data where jobs are allocated to users for a period of time, that may be set in advance.
The way the MGP compose process works does not go well with selecions by date range, as it only processes records that have altered since the last compose process, so you get the scenario
record created 1/1/08 with a 'send to client date' of 1/3/08
snapshot has the query select * from table where send to client date <= system date
compose runs on 1/1/08, processes the record as it has changed, but it does not meet the selection criteria, so is not sent
compose runs on 1/3/08, but as the record has not changed, it is not processed
there are a few options
1) batch job that does a dummy update of all records where send date=system date, this will force the mgp process to pick it up, but not too efficient
2) as above but the update is to the CVR$ table, incrementing the version number - achieves the same objective and saves updates to the real data
3) use MyCompose for the object, with a needCompose test either always true, or based on records for the date range existing
4) use a queue based publication item
NOTE if using 1 or 2, ALL matching records need the update, not just one for the table