Try the link again - I found that the site was down as well, but it is
working again.
I have a similar problem, I am using CASL for the programming and so far i
haven't found any compression programs that will work it. If you find one
could you let me know.
I have a utility that will update the CASL DB on the PC and the transfer the
updates to the palm. Very slow transfer, but fast on the palm(30,000 recs)
I was working with Codewarrior but that is way to much work for a simple
app. and CASL is cheep.
-----Original Message-----
From: Xen Cloete <[EMAIL PROTECTED]>
To: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]>
Date: Monday, January 03, 2000 2:43 PM
Subject: RE: HotSync speed
>Hi Constantine,
>
>Could I ask you to point directly to this software. I have trouble
>trying to find it...
>:-)
>
>Regards
>Xen
>
> -----Original Message-----
> From: Constantine Klyatskin
>[mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 30, 1999 5:09 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: HotSync speed
>
> Hi,
>
> please do consider my mail as an ad by I advise you to
>have a look at
> PDBcruncher available at http://klyatskin.da.ru
>
>
> With its aid I have HotSync session in less then minute
>while without it it
> tooks 2+ hours. It's true, not joke.
>
> There is a restriction for DB record lengths there
>(README.TXT) but if
> you'll like it I could fixed it for you personally. Or
>adopt it in any other
> way.
>
> Regards,
> Constantine Klyatskin
> ----------------------
> http://klyatskin.da.ru
>
>
> ===============
> Date: 28 Dec 1999 06:51:56 -0800
> From: "Howard C. Shaw III" <[EMAIL PROTECTED]>
> Subject: HotSync speed
>
> 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. We have a
>sophisticated fully
> server-side system for determining what records have
>changed, and do not
> need to examine the records on the handheld to determine
>this, but must
> obtain the record-id corresponding to a particular
>identifying DWord. Since
> the initial read of these DWords takes 4 minutes, we are
>being pushed over
> our limit almost before we begin. This is deeply
>puzzling, since, having
> examined what information is returned in the header, we
>have determined that
> the handheld should only need to transfer 13 bytes per
>record; four bytes
> from the record itself (which we are limiting using
>totalbytes on a >= 2.1
> API), and the header information (using
>SyncReadRecByIndex). For 11,600
> records this is 150,800 bytes. At 57,600 this should
>take around 20.9
> seconds. Instead, it takes 260 seconds. Thus this
>transfer is 91% overhead!
>
> 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.
>
> Howard C. Shaw III
> Programmer
> Tyrol Data Systems
> ================
>
>
>
>
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
>
>
