We have configured everything in client and server to have SYNC_STATS, SYNC_SUBS_STATS and SYNC_TRACE syncronized. The tables are created in the client (Derby) when first synced.
But the problem is that the isync API is leaving the trace of syncing in other tables named DSY_STATS, DSY_SUBS_STATS, DSY_TRACE which are created in the client at isync startup even if the subscription set is not available for the user.
Anyone knows what's happening?
Thanks in advance
This topic has been locked.
4 replies Latest Post - 2009-05-12T11:02:57Z by SystemAdmin
Pinned topic SYNC_STATS vs DSY_STATS
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2009-05-12T11:02:57Z at 2009-05-12T11:02:57Z by SystemAdmin
Re: SYNC_STATS vs DSY_STATS2009-02-01T08:39:01Z in response to SystemAdminYes, it's the disign.You can refer to http://publib.boulder.ibm.com/infocenter/db2e/v9r1/index.jsp.
In the approach, the client information is uploaded to the server in three phases:
1.Information collection: During synchronization, the sync engine writes the information to the Client Control Database1, which belongs to and is managed by the sync engine.The control tables are named DSY_STATS, DSY_SUBS_STATS, DSY_TRACE .
2.Information propagation: Then, based on the directives given by the server, the sync engine will propagate the information into a user database (Upload DB). The upload DB tables are named SYNC_STATS, SYNC_SUBS_STATS and SYNC_TRACE. The phase can be executed asynchronously from the information collection phase. If it happens at the end of a synchronization session, the complete client information regarding that session can be obtained. It can also be executed right after the synchronization of each subscription to obtain the up-to-the-subscription information.
3.Information upload: After the information is propagated to a user database, the user (application) can simply upload it just like regular user data.
DSYCLIENTSTAT_SET associate with the subscription DSYCLIENTSTAT
Re: SYNC_STATS vs DSY_STATS2009-05-08T09:13:02Z in response to SystemAdminHi again,
Thanks for the response.
I've checked http://publib.boulder.ibm.com/infocenter/db2e/v9r1/index.jsp but haven't found anything about DSY_STATS,... tables or three stage sync.
Anyway, we have on the device DB the tables DSY_STATS, DSY_SUBS_STATS, DSY_TRACE & MHDSY_STATS, MHDSY_SUBS_STATS, MHDSY_TRACE. These are created when first synced, even if DSYCLIENTSTAT_SET is not added to the group of users and isync.trace.* properties are off.
When we add DSYCLIENTSTAT_SET to the group and turning on isync.trace.* properties on the server, the tables SYNC_STATS, SYNC_SUBS_STATS, SYNC_TRACE & MHSYNC_STATS, MHSYNC_SUBS_STATS, MHSYNC_TRACE are created on the device DB.
But, sync info is collected into DSY_* & MHDSY_* tables but NEVER pushed into SYNC_* & MHSYNC_* so it's never uploaded to the server.
Following your post, I suppose the second phase is not taking place on the device for some reason. So my questions are:
¿What directives must be given to the server and how?
You said the phase can be executed on different times (before, after, asynchronously...) ¿What controls that behaviour?
Thanks in advance
Re: SYNC_STATS vs DSY_STATS2009-05-12T11:02:57Z in response to SystemAdminHi again,
Diving into derby.log we've found that the engine was trying to push data from DSY_STATS to SYNC_STATS through these SQL sentences:
select * from MHDSY_STATS;
insert into SYNC_STATS values (?,?,?,?,?,?,?);
The problem is that the DSYCLIENTSTAT subscription is defined to not subscribe the USER_ID field, so the insert sentence failed saying that the number of parameters is not correct.
The final effect is that stats are not pushed into SYNC_* neither uploaded to the server.
We've turned on the USER_ID field suscription on DSYCLIENTSTAT and things are working now.
I suppose creation of DSYCLIENTSTAT & "config\template\server\dsyclientstat.xml" file should be fixed in the product package (we use Lotus Expeditor v6.1.2).