Re: OPO question - NOT a bug rreport ;-)

Rob -

This is just a guess. Try to open a standalone recordset on the client with "SELECT COUNT(*) . . ." as the query. Compare this with the GetRowCount() for the local copy, if you are using "Fetch Immediately" or GetRowCountAdvice() if you are using "Fetch Count First" for the RowFetchMode. Compare the two values.

This should work [although I haven't tested it] for the determination of the existence of a difference and the size, although the doc for the GetRowCountAdvice() method claims it returns approximately the number of rows. As far as adding the new rows, I guess you could fetch all the remote databases primary keys and then walk through the result set and delete all those that existed on the local table. This would give you a way to get the new rows, which you could then fetch from the remote database and add to a recordset attached to the local database.

A more efficent way might be to keep a table on the remote database that had all the primary keys on the local database, and then do an outer join to find the new rows. Copy the new rows to a tmep table and get them to the local database.

Pretty resource intensive, I would think. Why not a nightly download, if the user wants it? I hear there might be some replication services connected with Oracle Lite, which will be supported in verion 2.0.

Hope this helps.

• Rick Greenwald The Power Objects Pro _at_ inquiry.com