At 07:50 PM 24/06/2005 +0000, you wrote:

>At first, we just want to make the program work as it works with BDE.
>So do I have to add TIBODataBase and TIBOTransaction component or
>there is a way arround it?

Originally you wrote:

> > My company is in the planning phase of migrating from Paradox to
> > Firebird.
> > For most of the TTables in our program we do not create a TDataBase
> > commponent we just use the BDE link.
> > Do I have to add a new TIBODataBase and TIBOTransaction component to
> > every form that will have a TIBOTable on?
> > Is it oke to create a DataModule with a TIBODataBase and a
> > TIBOTransaction component on it and link every TIBOTable to one
> > TIBODataBase. (Possably a few hundred tables.)

>--- In IBObjects@yahoogroups.com, "Jason Wharton" <jwharton@i...> wrote:
>
> > It's fine to do that as far as IBO is concerned. However, it may or
>may not be what your application requires if you want to utilize the full
>benefits of transactions.
> >

I think there might be a misunderstanding here. When you said this:

> > For most of the TTables in our program we do not create a TDataBase
> > commponent we just use the BDE link.

.. I wonder if you were referring to the BDE's capability to link to a
Paradox file or Excel spreadsheet directly, without using a TDatabase
object? That approach "works" with Paradox since there is no "database" to
connect to. Opening a table involves opening a file, writing some external
lock records, accessing index records, etc., etc. Although this method of
working with Paradox is not recommended, you can do it, since opening file
objects is the way, physically, that the BDE (a.k.a Paradox engine)
accesses Paradox data.

If this is what you meant, then you shouldn't try to do it with
Firebird. Firebird tables are not files, they are pages of data that the
Firebird server engine controls through an inventory. That inventory
encompasses the whole database and is concerned with both connections and
transactions. (That description is so simplified as to be almost
meaningless in terms of understanding the engine, but I hope it's enough
for you to understand that Firebird applications communicate with the
database through a *connection*.

The route to a Firebird table is through a connection. One instance of
your application that wants to communicate with one database should do so
through one connection. Units of work *within* a connection are performed
inside a transaction. Even reading a table requires a transaction.

There's a world of interesting stuff to understand about transactions but,
for migration purposes, IBO rolls the connection and a transaction together
into the TIBODatabase. In your transitional stage, you can use this object
as both the connection for your application and a "no-brain" transaction
that IBO will take care of for you. Unless I'm mistaken, that is what
Jason was referring to.

Quoting you:

> > Is it oke to create a DataModule with a TIBODataBase and a
> > TIBOTransaction component on it and link every TIBOTable to one
> > TIBODataBase. (Possably a few hundred tables.)

Yes, that will work just fine for your transition. I'm very fond of the
datamodule approach myself, for a number of reasons. The principal one is
that it is a very effective way to keep the data access layer distinct from
the user interface. Sometimes it is desirable to have more than one DM,
since there are often architectural reasons to create and destroy a piece
of the data access layer on demand. As you get the full power of IBO under
your belt, you will find good uses for these kinds of capabilities.

For now, you are biting off a lot. The transition from data files
(Paradox) to database (Firebird) is a huge leap. If you're trying to do
that *and* move away from desktop to client/server at the same time, you
have a LOT of interdependent issues to meet and deal with.

So the initial transition will be just to get the mechanics of your old
file-based structures working in Firebird and IBO. Performance will be
terrible - that is a total "given", in an app with "a few hundred tables",
with keys driven by hieratrchical indexes and table accesses through
TIBOTables!

Once you have completed the search & replace conversion, create your DM
with one TIBODatabase and enough of your tables and datasources to open the
main form of the application in the way you are used to. "Hundreds of
tables" and their datasources would be a big eyeful in the IDE so,
initially, you will probably want to split the optional tables across a
number of DMs and link them back to the IBODatabase in the main DM. When
you later clean up the database and the architecture of your app, these
optional tables will become IBOQueries (or groups of them in a DM) that you
will create and destroy on demand....

When you create the main DM, go into the DPR file and move the create
statement for it to the top of the creation sequence. This is essential,
since the data-aware objects in the GUI units will AV at create time if the
data access layer has not been created yet.

An important tip: don't type database paths into DatabaseName
properties. Set up your one IBODatabase with the properties Server,
Protocol and Path; then use the IB_Connection property of the dataset
objects for linking to the database connection and transaction. IBO itself
will take care of constructing the hard code for the database path when it
is wanted.

The advantage for you is that you eliminate the possibility of the
TIBOTables creating their own connections to the database (the Paradox
model that you seem to have been using till now). This *is* a problem for
you with a transactional database engine, since each separate IBODatabase
object creates its own transaction; and, of course, one transaction is
unaware of what is happening inside another.

One could go on and on but that's not my intention here and now, so I'll
wrap this up. :-) Good luck!

Helen