> I have to convert a Delphi-based application that uses Paradox to a C/S
> database; I've chosen Firebird.
>
> To do this, I need to convert the Paradox DB pretty much as-is to

get the

> code working with the new database. Later, I'll want to redesign the
> database to take out some of the more objectionable aspects.

This is not unusual. To get the code working as-is with Firebird will
not take long, however you should be aware that designs built around a
desktop paridigm do not necessarily scale well to client-server, and
designs built around locking database engines (such as Paradox) do not
necessarily scale well to MGA engines like Firebird. As someone who
has 'been there', I can categorically say that it was the best move we
made.

The first major point of difference is that of transactions. The BDE
more or less hides transactions from the end user. Firebird is unable
to process a command without transaction. Thus, any layer that
emulates a desktop database model (like BDE) implicitly creates a new
transaction for each DML statement and commits it. Unfortunately it
can use CommitRetaining which depending on the usage of the database
can lead to a build up of record versions. Under a well designed
system, the old record versions would be flagged as garbage in a
reasonable time, and the garbage collection processes can then keep
the performance good.

A common question when migrating is 'how do I lock a record', and the
usual response is 'you don't need to in Firebird'. Because of this,
Firebird performs extremely well in concurrent use, there is no
worrying about escalating locks.

IBO has a guide for converting a BDE application to IBO, but this
should be treated more of a 'getting an existing Paradox application
to work with Firebird' than as the best way to write a CS database.

TTable-like components are exceptionally slow. You are free to use
such a component, but I do not think there are any such components
that you should see as having long term merit. Eventually, you will
want to write it properly, so think of it as a way to 'buy some time'
rather than a solution.

You will most likely need to rewrite logic that relies on counting
records (use Exists if that is what you mean), as this is a lot more
expensive in a MGA database, and you will want to rewrite logic that
unnecessarily blocks actions from happenning because some other action
is happenning, (well unnecessary in Firebird, would be necessary in
Paradox).

You will also need to replace the 'autocommit' operations by
explicitly starting and committing your transactions as per the ACID
model not on a per operation basis. (Using stored procedures and
triggers can help here as well).

Apart from that, enjoy the fact you do not need to install and
configure a BDE client, you don't get corruption every time it loses
power and enjoy the significant performance boost where joins are
involved, as well as the thousands of other benefits.

Adam

> I've been
> looking at DeZign from Datanamic, which seems to be able to do some nice
> stuff with round-tripping between ERDs and the database itself, but

while

> it's not cheap, it's less than Microsoft's Visio Architect. Is there a
> better option (i.e., something less expensive that does the same sort of
> thing).
>
> I'm also going to need some Delphi components to replace the BDE

stuff (yes,

> I know you're not supposed to use anything like TTable, but this is

a very

> small database and I'm very short of time). Does anyone have any
> recommendations for a component set that will emulate TTable, but

which I

> can then use later as well, when I fix all of that sort of thing?
>
> There are around 1000 files that comprise this application, which was
> originally written for DOS with Delphi 1. Over the years it's

accumulated

> many things, e.g., not only does it use TTable, but also TwwTable. I've
> looked at IBObjects, which has a GReplace utility that will fix up

refs to

> TTable to TIBOTable. This is configurable and looks useable, but

are there

> other choices? (I'd hate to find that there was a better way after

starting

> down that road).
>
>
> Michael D. Spence
> Mockingbird Data Systems, Inc.
>
>
>
> [Non-text portions of this message have been removed]
>