At 11:09 AM 30/09/2003 +1000, you wrote:

>Right so this 'bde replacement' doesn't actually have a global session
>variable like the bde - it's private

To the application, yes.

> and the only way to access it is to create a TIBOComponent decendant and
> access it's IB_Session property.

You mean TIB_Component, I'm sure. You can go one of two ways: either drop
a tib_SessionProps on your form as first in the creation order; or use a
named TIB_Session. Either way, you can then refer to the IB_Session before
any other components are created. (TIB_SessionProps gives you access to
the default TIB_Session component, named DefaultSession, that is created
immediately upon creation of the first TIB_Component, if you haven't
already created an explicit IB_Session...)

>Um, can you say 'Cop out'?

Why? It is very similar to what the VCL does with the BDE components. You
don't get a global Session variable in the VCL, either, if you don't use
its data access classes. The VCL's Session variable behaves somewhat
differently in the BDE context because it has to be generic to all kinds of
connections (ODBC data sources, transactional and non-transactional RDBMS,
even plain text files). The IB_Session is more of a "cop-in", insofar as
it is completely dedicated to supporting IB/Fb client attachments. It
doesn't implement stuff that's not needed for IB/Fb connectivity.

>Let me give you an example of where I use session.
>I use it to get a reference to the database where I only know the database
>name. E.g.
>
> TMyObject = class
> published
> ...
> property DatabaseName: string read FDatabaseName write FDatabaseName;
> ...
> end;
>
> ...
>
> procedure TMyObject.Commit;
> var DB: TDatabase;
> begin
> DB := Session.FindDatabase(FDatabaseName);
> DB.Commit;
> end;
>
>So you are saying to do the above in IBO I would have to do this:
>
> procedure TMyObject.Commit;
>
> function GetGlobalSessionThatIBODoesntExpose: TIB_Session;
> begin
> with TIBOQuery.Create(nil) do
> try
> Result := IB_Session
> finally
> Free;
> end;
> end;
>
> var DB: TIBODatabase;
> begin
> DB :=
> TIBODatabase(GetGlobalSessionThatIBODoesntExpose.GetConnectionByName(FDatabaseName));
> DB.Commit;
> end;

If you really want to do things the hard way, sure, go right ahead. :-))

The issue for you is that your BDE app design is using methods related to
generic data interfaces, which is great for the BDE (which is nothing if
not generic) but, since you are moving to a dedicated data interface, it
requires a bit of a rethink of your approach to creating DAOs at
run-time. That's OK; but, for you, it means work to escape from the
DbTables design model, although it doesn't affect everyone this way.

>That's ok, I can handle that, but I still think that it's a cop out if the
>only way to access the **global** default ibo session is through the
>**property** of an ibocomponent when this is supposed to be a bde replacement.

It's a BDE replacement in the sense that it replaces the BDE's data
interface between Delphi (or Kylix) and InterBase/Firebird. It doesn't
replace, or purport to replace, what the BDE provides by way of a generic
client layer to any source of data.

Do study the help for TIB_Connection, TIB_Transaction and TIB_Session. One
of the BDE "givens" that IBO doesn't go along with is the one that
"transactions don't matter, so hide them if possible.". While the
TIBODatabase can be (and is, by default) like TDatabase (single connection
and one, single, invisible transaction), it's not usual for IBO developers
to stay with that model for long, once they get their heads around
transactions and multiple connections...If you want to keep working with
that flat-table, no-transaction, desktop model, you're probably better to
go with some more generic solution than IBO.

Helen