|
Home > Archive > SQL Anywhere ultralite > March 2006 > How to limit database growth on sync.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to limit database growth on sync.
|
|
| Jim Morris 2006-03-16, 7:28 am |
| Using Adaptive Server Anywhere static C++, UltraLite Code
Generator Version 9.0.2.3131
on Palm 5.x platforms, T3, TX and Treo 650 via HotSync
Currently we are essentially using the snapshot methodology
to download table. The download_delete_curs
or is used to
truncate the tables then all the values are downloaded. As
has been discussed in other messages this results in an
approximate doubling of the database size.
We would like to avoid this doubling.
From ealier messages use of StopSynchronizationD
elete on the
client seems to help to some degree however this seems to
require that a change date or flag is used to condition the
deletes on the pre-HotSync event (Be nice if the Ultralite
flag were queryable). It also has the undesirable side
effect of leaving the database in a bad state on sync
failure.
We have tried to think outside the box and had some ideas.
1) Can a commit on the client be done after the delete stage
so as to allow reuse of the space, perhaps in the
end_download_deletes
event?
2) Will setting the checkpoint_store parameter in the client
reduce the database size after sync?
3) Can synchronization be spit into discrete upload-only,
delete and download syncs each with their own commits but
occuring in one HotSync?
Are there any other possible approaches to limiting the
doubling of space?
If we were to convert to incremental downloads I assume the
doubling effect is minimized, correct?
Thanks
| |
| Michael Thode 2006-03-16, 8:23 pm |
| 1) This isn't supported. It would be much more complicated to manage the
download if it was no longer atomic (eg. the trunctate could succeed but the
download would fail)
2) checkpoint_store, can reduce the amount the database file grows in some
cases with large downloads, but it won't shrink the database file. The
doubling effect your seeing won't be addressed by checkpoint_store. Also,
if you use this with hotsync it can slow things down considerably though due
to extra bandwidth between the desktop and the device.
3) You'd need multiple hotsyncs to do this.
Your idea about incremental downloads is correct. This will reduce the
amount of doubling.
I don't understand what you mean by
> however this seems to
> require that a change date or flag is used to condition the
> deletes on the pre-HotSync event
What earlier messages were you refering to?
If you use stop sync delete on the client before the sync this should do
what you want.
Mike
<Jim Morris> wrote in message news:44189f4f.7c90.1681692777@sybase.com...
> Using Adaptive Server Anywhere static C++, UltraLite Code
> Generator Version 9.0.2.3131
> on Palm 5.x platforms, T3, TX and Treo 650 via HotSync
>
> Currently we are essentially using the snapshot methodology
> to download table. The download_delete_curs
or is used to
> truncate the tables then all the values are downloaded. As
> has been discussed in other messages this results in an
> approximate doubling of the database size.
>
> We would like to avoid this doubling.
>
> From ealier messages use of StopSynchronizationD
elete on the
> client seems to help to some degree however this seems to
> require that a change date or flag is used to condition the
> deletes on the pre-HotSync event (Be nice if the Ultralite
> flag were queryable). It also has the undesirable side
> effect of leaving the database in a bad state on sync
> failure.
>
> We have tried to think outside the box and had some ideas.
> 1) Can a commit on the client be done after the delete stage
> so as to allow reuse of the space, perhaps in the
> end_download_deletes
event?
>
> 2) Will setting the checkpoint_store parameter in the client
> reduce the database size after sync?
>
> 3) Can synchronization be spit into discrete upload-only,
> delete and download syncs each with their own commits but
> occuring in one HotSync?
>
> Are there any other possible approaches to limiting the
> doubling of space?
>
> If we were to convert to incremental downloads I assume the
> doubling effect is minimized, correct?
>
> Thanks
|
|
|
|
|