Hi!

half a year ago I tried to migrate a Delphi 5 application from
BDE/Paradox to DBISAM (4.24, in file server mode). But because of
performance issues accessing the database on a network
(especially with some SQL queries and long opened tables) it was
not successful - it seems that the BDE does so much tricky
caching so it's sometimes a lot faster than DBISAM. In addition,
the architecture of my application is too bad - a *lot* of tables
(with heavy master-detail-links) which are all opened while
starting the appplication... There is a thread about my migration
problems here:
http://www.elevatesoft.com/scripts/newsgrp.dll?action=searchopenmsg&group=5&msg=55753

Now ElevateDB is coming. Is it worth to try a migration again? Is
ElevateDB faster than DBISAM?

Kind regards,
Georg

Given the same architecture, you aren't going to see a big speed
increase. The BDE may be faster (mostly because it is a caching memory
*hog*), but it is also much less reliable when pounding it with multiple
users in a network. With DBISAM my days of repairing Paradox tables are
over! I especially loved it when the Paradox rebuild utility would
renumber my autoinc primary keys!

Regards,

Jason Lee

Georg Ledermann wrote:
> Hi!
>
> half a year ago I tried to migrate a Delphi 5 application from
> BDE/Paradox to DBISAM (4.24, in file server mode). But because of
> performance issues accessing the database on a network (especially with
> some SQL queries and long opened tables) it was not successful - it
> seems that the BDE does so much tricky caching so it's sometimes a lot
> faster than DBISAM. In addition, the architecture of my application is
> too bad - a *lot* of tables (with heavy master-detail-links) which are
> all opened while starting the appplication... There is a thread about my
> migration problems here:
> http://www.elevatesoft.com/scripts/newsgrp.dll?action=searchopenmsg&group=5&msg=55753
>
>
> Now ElevateDB is coming. Is it worth to try a migration again? Is
> ElevateDB faster than DBISAM?
>
> Kind regards,
> Georg

> Given the same architecture, you aren't going to see a big
> speed increase. The BDE may be faster (mostly because it is a
> caching memory *hog*),

Sad....

> but it is also much less reliable when pounding it with
> multiple users in a network. With DBISAM my days of repairing
> Paradox tables are over! I especially loved it when the Paradox
> rebuild utility would renumber my autoinc primary keys!

Of course, Paradox tables are horrible unstable...

Hello Georg,

> Now ElevateDB is coming. Is it worth to try a migration again? Is
> ElevateDB faster than DBISAM?

I guess you should try since Statistics are removed from ElevateDB.

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

Not only do I think it is faster but also is easier to distribute and
maintaine without the BDE.  I

I would suggest going to an all SQL approach and load all into QG5/6.

If you are still using TTable (w/ master/detail) instead of TQuery, you will
most
likely never see any real speed increase.

It is my understanding that EDB provides better SQL support and this will
help
you at that level. At the table level, no real advantage as far as I know.

Regards,
Scott.

"Georg Ledermann" <ledermann@completho.de> wrote in message
news:A27E81AC-39B4-44BA-AA54-1CD119A316D6@news.elevatesoft.com...
> Hi!
>
> half a year ago I tried to migrate a Delphi 5 application from BDE/Paradox
> to DBISAM (4.24, in file server mode). But because of performance issues
> accessing the database on a network (especially with some SQL queries and
> long opened tables) it was not successful - it seems that the BDE does so
> much tricky caching so it's sometimes a lot faster than DBISAM. In
> addition, the architecture of my application is too bad - a *lot* of
> tables (with heavy master-detail-links) which are all opened while
> starting the appplication... There is a thread about my migration problems
> here:
> http://www.elevatesoft.com/scripts/newsgrp.dll?action=searchopenmsg&group=5&msg=55753
>
> Now ElevateDB is coming. Is it worth to try a migration again? Is
> ElevateDB faster than DBISAM?
>
> Kind regards,
> Georg

Georg,

<< Now ElevateDB is coming. Is it worth to try a migration again? Is
ElevateDB faster than DBISAM? >>

Your issue before was the number of master-detail links and the number of
lookup tables/calc fields.  There is really nothing we can do about the
network latency accumulation with these types of things because they are all
part of the standard TDataSet architecture.  The only thing that can help it
is to try and cache as much as possible locally by using the
LookupCache=True property setting.

As for the direct SQL access - the BDE caches a lot of data and uses a lot
of memory in doing so.  DBISAM and EDB use only a fraction of that for
caching data locally on the client.  However, you can bump up the memory
settings in both DBISAM and EDB to force them to use more memory for caching
data from tables.

Did you try to bump up the cache memory settings with DBISAM when you were
evaluating it before ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Thank you all for helping! I think, that I will try a new
migration after ElevateDB is available...

> Your issue before was the number of master-detail links and the
> number of lookup tables/calc fields.  There is really nothing
> we can do about the network latency accumulation with these
> types of things because they are all part of the standard
> TDataSet architecture.  The only thing that can help it is to
> try and cache as much as possible locally by using the
> LookupCache=True property setting.

Optimizing a large legacy application is very hard, at least with
THIS application of mine because there are so many side effects.
I've tried optimizing via LookupCache, but this caused many
problems (nothing to do with DBISAM, but in the application
itself), so I have stopped it.


> As for the direct SQL access - the BDE caches a lot of data and
> uses a lot of memory in doing so.  DBISAM and EDB use only a
> fraction of that for caching data locally on the client.
> However, you can bump up the memory settings in both DBISAM and
> EDB to force them to use more memory for caching data from
> tables.
> Did you try to bump up the cache memory settings with DBISAM
> when you were evaluating it before ?

Yes, I had used the following code before opening the database:

====
 with DBISAMEngine do
  begin
    MaxTableDataBufferSize := MaxTableDataBufferSize * 4;
    MaxTableDataBufferCount := MaxTableDataBufferCount * 4;
    MaxTableIndexBufferSize := MaxTableIndexBufferSize * 4;
    MaxTableIndexBufferCount := MaxTableIndexBufferCount * 4;
    MaxTableBlobBufferSize := MaxTableBlobBufferSize * 4;
    MaxTableBlobBufferCount := MaxTableBlobBufferCount * 4;
  end;
=====

Anyway, I will try the migration again after release of
ElevateDB...

Kind reagrds,
Georg

Jason Lee wrote:
> Given the same architecture, you aren't going to see a big speed
> increase. The BDE may be faster (mostly because it is a caching memory
> *hog*), but it is also much less reliable when pounding it with
> multiple users in a network. With DBISAM my days of repairing Paradox
> tables are over! I especially loved it when the Paradox rebuild
> utility would renumber my autoinc primary keys!

<nightmare flashback>

DBISAM is so extremely stable I can't fathom ever having had to deal
with the Russian roulette that Paradox embodied. Are there really STILL
people using that thing? They deserve bravery medals.

Dominic


And then there's something called the Darwin Awards ........

Roy Lambert