This content has been marked as final. Show 3 replies
do you have data subsetting parameters defined against these publication items? if so are they correct for the users.
are there any database files on the client? if so the client may think that it is expecting a refresh and if the MGP has not composed any data then nothing will be sent.
check the instantiated flag in c$all_subscriptions for the user, if not set to Y then the publication or association of the user has failed.
check c$all_client_items to make sure thay have the full list of items
set the trace on the sync at the server end, and check if you are getting any errors.
do you have any queue based items, if so processing tends to abort if there is an error (eg: PK issues) in one of these and the following PIs are empty
In the days before you posted these possibilities I manged to solve the problem. I changed the select statement (in the workbench - removed som fields - tried sync and then changed back to the original select statement) after that all rows came out.... I have no idea why - but it worked.
Just for the record (if anybody else face the same problem) is my answers to your "possiblities" - but AFTER I got it to work again
- No subsetting paramters
- No database files on the client (I removed them before I did sync)
- The instantiated flag in c$all_substrictions is Y
- C$all_client_items has the full list of items
Thanks for your interest in my problem
changing the select, and then changing it back against suggests to me that there was some issue with the instantiation - often little or no errors raised, and often no apparent reason. I has a publication that would not instantiate, but then did when i added the PIs one at a time.
Change to the select statement causes a re-evaluation of the PI so resets the instantiated indicators. If there are any, cu, paste and same of a subsetting parameter will also work (sometimes)