Subject | Re: [IBO] IBO speed vs BDE? |
---|---|
Author | Paul Schmidt |
Post date | 2001-04-18T20:31:53Z |
Lucas:
On 18 Apr 2001, at 17:49, Lucas Franzen wrote:
> Paul Schmidt schrieb:
> [snip]
>
> > IBO also has a much lower pain-in-the-donkey factor. The BDE needs
> > to have the ODBC driver installed, then BDE, then you need to monkey
> > with the registry to configure both. Where as IBO only needs the
> > runtime package included with your software's installation program,
> > which is installing a bunch of Delphi runtime packages anyway.
>
> nice summary, if not a flame vs. the BDE :-).
No intention of flaming the BDE, it's the way such things are, no
matter what, a general all purpose tries-to-be-everything-to-everyone
tool, will never be as efficient as a tool designed to do a specific
job.
> But you don't need ODBC for the BDE. For Interbase it's just SQLLinks.
> But you're right that it's almost impossible to do a proper install of
> these automatically.
That's one of the things, my preference is to simply email or FTP the
application to the client, and tell him/her to run the attached .exe
to install it. The last thing I want is to have to clients SA cranky
at me, because he forgot one of the 17 setup steps needed to do the
install.
> And for the app: you don't even have to use runtimes packages, if you
> compile them into your app (IBO makes increases the size about 800kB I
> think) you don't have to worry about bpl-Versions any longer
> (something I do prefer, so I won't have to twiddle around with errors
> caused by outdated packages).
With the development cycle on IBO fairly short these days, I don't
mind the packages, because if an IBO related bug shows up, I can
simply send the fixed package, without having to rebuild the .exe
> Just deliver your exe, that's it. If it's getting too big, there are
> some good packing programs out there.
Usually the problem with a big .exe is the size of the footprint,
especially when the client has a nice collection of classic Pentiums
with 32MB of memory.
Paul
Paul Schmidt,
Tricat Technologies
Email: paul@...
Website: www.tricattechnologies.com