> the conduit was proving to be a nightmare to develop and
> support (possibly because it required a third development
> environment (VC) that neither the Windows developer or the
> Palm developer were familiar with).
You can now write conduits in all the major Windows development
environments, s
I agree with Brian, a non-conduit solution usually looks kludged. There
is also the point that using the pdb method may fail to properly sync
the Palm and PC databases. Surely the users can change things on the
Palm between backing up a database and installing the new one?
Cheers,
Jim Cooper
__
I'm glad you're speaking for yourself. Our latest creation does not use
conduits directly. We read and write directly to PDB files. And its not a
hack (Palm published the PDB/PRC file format) or some thrown together
kludge. Infact, the app is more complex than any conduit I ever wrote. We
requ
Dave,
> Our latest creation does not use conduits directly. We read and
> write directly to PDB files.
Could you explain how you deal with the syncing issues (when the PDBs
get transferred etc)? Do you have performance issues/workarounds for
large databases?
> Infact, the app is more complex
>
> Could you explain how you deal with the syncing issues (when the PDBs
> get transferred etc)? Do you have performance issues/workarounds for
> large databases?
My data is small so I've never had to deal with any of the memory issues
(typically < 5K per PDB) But I do sometimes deal with dozens
Dave,
Thanks very much for the info.
Cheers,
Jim Cooper
_
Jim Cooper [EMAIL PROTECTED]
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Writing Palm conduits with Delphi
_
Learn how to program Pa
Chris,
> so the approach we use is
Thanks for the info.
I'm interested to know what other people do, so that I can advise our
users on other approaches.
Do you find backing up a database runs quicker than a one-way conduit,
BTW?
Cheers,
Jim Cooper
___
> Ah, I *do* remember that we got significant speed improvements
> by moving from lots of small records to large packed records.
> There seemed to be a reasonable overhead associated with the
> record creation itself, aside from the volume of data transferred. I
> can't remember if this was when w
> The format of the PDB files is documented but I believe reading/writing
> directly to them is not "supported" by Palm. i.e. The format could change
> at any time and your program would break. Whereas the conduit is a
> supported interface. This is an argument management will understand.
Offici
> it wouldn't seem feasible to myself to see the .pdb, .prc file format
> changing at anytime, but the internal representation on the device is
> something that Palm themselves may wish to handle (can we verify right
> now that the format is the same? maybe they already so some other
> things
> > The format of the PDB files is documented but I believe reading/writing
> > directly to them is not "supported" by Palm. i.e. The format could change
> > at any time and your program would break. Whereas the conduit is a
> > supported interface. This is an argument management will understand.
> The format of the PDB files is documented but I believe reading/writing
> directly to them is not "supported" by Palm. i.e. The format could change
> at any time and your program would break. Whereas the conduit is a
> supported interface. This is an argument management will understand.
Offic
> Ah, I *do* remember that we got significant speed improvements
> by moving from lots of small records to large packed records.
> There seemed to be a reasonable overhead associated with the
> record creation itself, aside from the volume of data transferred. I
> can't remember if this was when
"Jim Cooper" <[EMAIL PROTECTED]> wrote
> Chris,
> > so the approach we use is
>
> I'm interested to know what other people do, so that I can advise our
> users on other approaches.
>
> Do you find backing up a database runs quicker than a one-way conduit,
> BTW?
>
I don't think we ever did a spee
Chris,
> so the approach we use is
Thanks for the info.
I'm interested to know what other people do, so that I can advise our
users on other approaches.
Do you find backing up a database runs quicker than a one-way conduit,
BTW?
Cheers,
Jim Cooper
__
"Jim Cooper" <[EMAIL PROTECTED]> wrote
> Dave,
>
> > Our latest creation does not use conduits directly. We read and
> > write directly to PDB files.
>
> Could you explain how you deal with the syncing issues (when the PDBs
> get transferred etc)? Do you have performance issues/workarounds for
>
The format of the PDB files is documented but I believe reading/writing
directly to them is not "supported" by Palm. i.e. The format could change
at any time and your program would break. Whereas the conduit is a
supported interface. This is an argument management will understand.
Having said
Dave,
Thanks very much for the info.
Cheers,
Jim Cooper
_
Jim Cooper [EMAIL PROTECTED]
Tabdee Ltd http://www.tabdee.ltd.uk
TurboSync - Writing Palm conduits with Delphi
_
Learn how to program P
>
> Could you explain how you deal with the syncing issues (when the PDBs
> get transferred etc)? Do you have performance issues/workarounds for
> large databases?
My data is small so I've never had to deal with any of the memory issues
(typically < 5K per PDB) But I do sometimes deal with dozen
Dave,
> Our latest creation does not use conduits directly. We read and
> write directly to PDB files.
Could you explain how you deal with the syncing issues (when the PDBs
get transferred etc)? Do you have performance issues/workarounds for
large databases?
> Infact, the app is more comple
The primary purpose of a conduit is data synchronization. If your data goes
one-way (Palm to desktop) then I see nothing wrong in reading directly to
the PDB on the desktop. Anything else and a real conduit would be better.
I've messed around with generic conduits because I need to write one fo
I'm glad you're speaking for yourself. Our latest creation does not use
conduits directly. We read and write directly to PDB files. And its not a
hack (Palm published the PDB/PRC file format) or some thrown together
kludge. Infact, the app is more complex than any conduit I ever wrote. We
req
I agree with Brian, a non-conduit solution usually looks kludged. There
is also the point that using the pdb method may fail to properly sync
the Palm and PC databases. Surely the users can change things on the
Palm between backing up a database and installing the new one?
Cheers,
Jim Cooper
_
-BEGIN PGP SIGNED MESSAGE-
Chris Tutty wrote:
[...]
> Valid point, although in this case the Palm apps are support
> tools for larger Windows-based apps so the PDB reading and
> writing is integrated with that application.
>
> The 'keeps with the rest' point is my main concern. I don't
"Brian Mathis" <[EMAIL PROTECTED]> wrote
> Chris Tutty wrote:
> [...]
> > Does anyone have an opinion on problems that might arise with
> > not using a conduit or benefits that might be gained from using
> > the current conduit technology?
> >
> Basically, Palm could improve things just short of a
> the conduit was proving to be a nightmare to develop and
> support (possibly because it required a third development
> environment (VC) that neither the Windows developer or the
> Palm developer were familiar with).
You can now write conduits in all the major Windows development
environments,
-BEGIN PGP SIGNED MESSAGE-
Chris Tutty wrote:
[...]
> Does anyone have an opinion on problems that might arise with
> not using a conduit or benefits that might be gained from using
> the current conduit technology?
>
> Chris Tutty
I found, whilst learning conduits, that most of the pr
Greetings,
I'm working with an app that doesn't use a conduit to sync
data but instead reads and writes the PDB's directly from the
backup area. This decision was made some time ago when
the conduit was proving to be a nightmare to develop and
support (possibly because it required a third develo
28 matches
Mail list logo
