You could put your original 13 bytes in the new DB as well as the DB recid,
providing a link to the records in the original DB.
-----Original Message-----
From: Howard C. Shaw III [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 28, 1999 2:14 PM
To: [EMAIL PROTECTED]
Subject: Re: HotSync speed
----- Original Message -----
From: "Jason Dawes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, December 28, 1999 12:06 PM
Subject: Re: HotSync speed
> At 08:43 AM 12/28/99 -0600, you wrote:
> >We are developing a product which has the implicit requirement that a
single
> >hotsync take no longer than five minutes to complete.
> >
> >Currently, with a portion of our dataset consisting of 11,600 records, it
> >takes 4 minutes 20 seconds to retrieve the first four bytes and the
record
> >id from each record in this dataset.
> >
> >Why is the overhead so great? We are trying to get setup for 115 kbps
> >transfer, but don't see that this will provide much benefit to a transfer
> >that has this kind of overhead.
>
> It's not just reading the record id and the first 4 bytes, the server is
> reading the whole record from the device - the Palm is dead during sync,
it
> can't negotiate "partial" reads.
>
> Maybe you should think about constructing a database on device that
> contains the just the 13 bytes you're interested in from each record in
> real database and sync that instead of syncing the real one - this means
> more processing on the server, but thats what it's for, no?
>
That would unfortunately be useless. The whole point of the exercise is to
permit the server to recognize and update specific records using their id.
So we pull back the id, and the recid, and a search against the id gives us
the recid to update. Putting this information in a separate database would
change the recids, and render them useless.
