SQL Anywhere Mobile - SQL error 604 when HotSyncing; database doubles in size?

Author

SQL error 604 when HotSyncing; database doubles in size?

paulor@bearriver.com

2005-07-18, 8:24 pm

Hi,

I'm running into a problem and am wondering if anyone else
has seen this (and if so, what the best way to address it
might be).

My app is a Palm app using the static C++ API, Mobilink
9.0.2.3131. The app is using the expanded memory mode with
A5 jumptables. The data is stored in Palm databases, instead
of an external storage card.

Users with less than 8 Meg of data can HotSync repeatedly
without getting an error. The amount of memory used on the
handheld levels out at approximately 16 Meg. After the first
HotSync, the memory used is ~8 Meg; after the second and
subsequent times, roughly 16Meg. The app does not 'see' any
additional data, so I am assuming that the ul database must
be expanding to accomodate an image of the data both before
and after synchronization, so that it can roll back in case
of failure.

Defragmenting the database after each HotSync has the effect
of stabilizing it at ~16 Meg. I would have thought that it
would bring the database's size back down to 8 Meg, but
apparently not.

One user has ~15 Meg of data to begin with. Attempting to
HotSync results in a SQL error 604 'dbspace full' error.
According to the documentation, a dbspace on the Palm can be
up to 128 Meg.

My questions are:
(a) why is the dbspace full when the database is expected to
only be ~32 Meg?
(b) Is defragmentation supposed to reduce the size of the
database to what the data alone requires?
(c) Are there any options I can tweak to allow larger
databases?

Thanks in advance,
Paulo Raffaelli

Greg Fenton

2005-07-19, 3:24 am

paulor@bearriver.com wrote:
>
> (a) why is the dbspace full when the database is expected to
> only be ~32 Meg?

I cannot say, hopefully someone on the UL engineering team can answer.
Is there the possibility that you have reached another maximum (e.g. 65k
rows in a single table? Palm filesystem is full?)

> (b) Is defragmentation supposed to reduce the size of the
> database to what the data alone requires?

Defragmentation does not affect the size of the database file. Once a
db file grows, it never shrinks. The only way to shrink it is to unload
and reload the database.

Are you downloading 8MB of data with each synchronization?
Are you using timestamp-based synchronization (i.e. only download
changes since the last synchronization) ?

greg.fenton
--
Greg Fenton
Consultant, Solution Services, iAnywhere Solutions
--------
Visit the iAnywhere Solutions Developer Community
Whitepapers, TechDocs, Downloads
http://www.ianywhere.com/developer/

Paulo Raffaelli

2005-07-27, 8:24 pm

> paulor@bearriver.com wrote:
>
> I cannot say, hopefully someone on the UL engineering team
> can answer. Is there the possibility that you have
> reached another maximum (e.g. 65k rows in a single table?
> Palm filesystem is full?)
>

No, and no. Both of these options have been considered -
neither is the case.

>
> Defragmentation does not affect the size of the database
> file. Once a db file grows, it never shrinks. The only
> way to shrink it is to unload and reload the database.
>

That would match what I'm seeing, all right.

>
> Are you downloading 8MB of data with each synchronization?
> Are you using timestamp-based synchronization (i.e. only
> download changes since the last synchronization) ?
>

The data is being synchronized in the most straightforward
way possible:
(1) upload everything on the remote - the desktop data
handles the merge logic (conflict resolution)
(2) delete everything on the remote;
(3) download everything from the desktop to the remote.

I'm exploring how to synchronize in a more incremental
manner, but haven't had much time to devote to it yet.

>
> greg.fenton
> --
> Greg Fenton
> Consultant, Solution Services, iAnywhere Solutions
> --------
> Visit the iAnywhere Solutions Developer Community
> Whitepapers, TechDocs, Downloads
> http://www.ianywhere.com/developer/

Sponsored Links