Hi Adam,

Thanks for the response, answers inline....

--- In firebird-support@yahoogroups.com, "Adam" <s3057043@...> wrote:
>
> The BDE has many problems and I am sure that anyone with access to
> google could discover them in seconds.

Yes, I did the search and to be honest I disagree (and always have)
with 99% of the complaints - especially those directed at paradox.
This is based upon 15 or so years of experience with the BDE and its
predecessor the Paradox Engine. Having said that I am in the minority
in that I use the BDE API directly and not via Delphi or C++ Builder.
In my opinion, it is these development environments which caused the
problems because I simply have never had the problems that those
developers have had.

> server' type databases but more aimed at the desktop database arena
> (eg Paradox). These databases work fine, well providing by fine you
> assume the machine never crashes and you don't have to go around
> looking for lck and net files, I still shudder. On a performance
> level, it can't even compete on the same page as the rest.

Well you see that is my problem. My implementation which currently
uses Paradox as its data store is blindingly fast and so I need to
replace it with something that at least matches in performance - thus
my experimentation with firebird.


> You should be aware that the BDE is no longer maintained. It suffers
> 'lowest common denominator' syndrome, inheriting the worst traits of
> each database and unable to provide the advantages of any of them.

Yes, I was aware of this. This is why I am running test BDE
applications against firebird and looking at the logs. And this is
where my confusion comes in, the BDE is issuing almost the same SQL
that I would. The most obvious problem is that it does a select * in
some cases where I can make improvements when writing my own SQL.


> The
> transactions almost want to be in autocommit mode, which of course
> goes against the whole idea of ACID (and I wont even get started
there).

And herein lies a crucial factor - I do not require transaction
processing (although it would be useful if a crash were to occur
during a bulk delete).

Let me explain... my application is designed as load on demand. When
a user goes to a particular screen only the data required for that
screen is retrieved from the data store - this is then cached
locally - the BDE cursor is then closed at this point. The data store
is only updated if the user clicks save and at that time we reopen a
BDE cursor and transfer the data from our cache to the BDE, save it
and then close the BDE cursor again.

Also, our philosophy from day one has been that the Users data is the
most important thing on the planet - even more important that data-
integrity. For that reason, the application is designed to save
whatever it can and if a crash were to occur during saving, then it
will cope with the resulting mess - for example in a Master-Child
link the child record could be missing because it never got saved. So
if a rollback were to occur then all of the Users input would be lost
instead of just part of it. This is no good for us and so we would
probably want to commit on a per table basis anyway.

However, there is so much more going on in the application to the
point that you can see I am using the words Data store rather than
Database because it best describes it function - storage. This will
not change in a Client Server environment for sometime and maybe
never if I cannot measure a significant performance benefit in
changing to a thinner client.


> My only regret from my BDE days is that I persisted so long with it.

I am approaching this with evolution in mind. Over time I will phase
out the BDE but as it stands I have a chicken and the egg situation -
so I have decided to change the data store first becuase it is
hopefully the easiest.


> I am not sure what you mean by it generating excellent SQL. I
> seriously hope you are not using a TTable approach (a bad idea even
> under Paradox).

At the moment we are experimenting and this includes using the
existing code, which does have some Cursors, and seeing exactly what
the BDE is doing. And this is where I came in, the logs are showing
that the BDE is doing a pretty good job. I might also point out that
the BDE logs have helped me immensely to understand how firebird is
currently structured especially regarding the system tables.

Anyway, fear not - production will not use table cursors at all.


> By the way, is there any reason you want to persist with Paradox

I have to because thats what is currently being used out there. I
cannot just abandon them but need to encourage them to upgrade by
offering them something better. Simply changing the data store is not
a good enough reason if it is not faster and right now there is
little difference.

> considering the Firebird license allows you to use / distribute /
> customise / do pretty much whatever you need to do? If you are going
> to the effort of supporting Firebird, then to me it seems pointless
to
> persist with a database engine that will cause more than its fair
> share of support calls.

Well I have a surprise for you, the application is 7 years old and I
have only ever had maybe 10 calls out of 1000's of users regarding
data corruption. Let me tell you its been a real surprise for me as
well because I also expected far more and had hoped to make
additional money from support agreements but it has simply not
happened - I have written the thing too well.

Leslie.