At 09:59 PM 26/04/2004 -0400, you wrote:

>IBO4.3.A , IB 6.0.2.0 and Delphi 5,
>
>I am testing a converted Delphi 5 Paradox app (currently using the
>TIBOxxx components) and getting some strange behaviour which I am having
>trouble tracking down. The app is an Interactive Voice Response system
>which manages up to 8 telephone lines to make reservations at sports
>facilities. I am using Dialogic D4PCI telephone interface cards and third
>party software which is the API interface to the Dialogic drivers. This
>3rd party software is multi-thread. My application is not multi thread but
>is re-entrant with all database access forced to be single thread via a
>mutex. Not elegant, but it worked fine with the Paradox files on a file
>server. The converted app using TIBOxxx also forces access to the app gdb
>to be single thread also, with all queries having a short life span: open,
>do your thing and close within the confines of the mutex.

Here's the second error in the design. Interbase doesn't need this; and
if you try to do it, it's going to make more problems than it solves.

btw, the first error is using IB 6.0.2. It has an incredible number of
known bugs. Ditch it and either buy a certified InterBase version or
switch to Firebird.

>In the Paradox version I used a separate TSession for the Pardox database
>and tables. In the IB version I have employed a TIBOSession component

presumably you mean a TIB_Session component...

> and set the session property of the TIBODatabase and all table and query
> components to it.

You *must* make certain that the TIB_Session is the very first thing in the
whole creation order of *anything* data-related, including data-aware
components. The very first thing you must do is explicitly set this - you
can set the creation order by right-clicking on any data-access component.

>I assume this will isolate the database access from any VCL processing.

You've expressed this assumption before and chose not to respond when I
asked you what you meant. It still sounds as if you are making some
strange assumptions about how things work. All the VCL's TSession does is
to create a "bubble" around anything data-aware inside the application
object, which has some global properties. Effectively, it's just a piece
of virtual rope that data-aware objects hang off. It doesn't "isolate"
data-access stuff "from the VCL".

With desktop databases, you use multiple TSessions to put a rope around
each separate lock-thread's separate business with the physical files that
constitute a file-based database: it's the only way you can accomplish
task-isolation with these database systems. To quote the VCL help:

"Finally, database applications that must establish multiple, concurrent
connections to the same database, such as performing two queries against
the same data at once, are multi-threaded applications. Multi-threaded
applications must create and maintain one additional session component for
each simultaneous connection to a single database server."

IOW, that's how Delphi and the BDE manage "concurrency" for Paradox and
Access, and for the Paradox-like mismorph that is any *real* dbms when
crippled by the BDE into denying its transactionality.

IB/Fb have isolation built in - not as an option, but intrinsically to the
entire architecture. Each interaction with the dbms happens inside a
transaction. What happens in one transaction is isolated from what happens
in any other transaction. So your Delphi app only needs to take care of
what the external program wants: presumably, it accepts some parameters,
starts a transaction, does the deed and (if required) sends some kind of a
response back to the external program. If your app needs to handle
multiple external requests, no problem, it can keep track of them itself -
but PLEASE use a queuing system, not mutexes!!!

But the application itself only needs one connection to the database. The
beauty of the transaction model is that everything the external request
wants can be enclosed in a single transaction that has a life that is
atomic unto itself and exists independently of any other transaction.

You can, if you need to, create and destroy an entire session for each
external request. You need to do this typically for an ISAPI module, or
for threading complete tasks within your application. In that case, you
would create a method that would create a datamodule consisting of a
TIB_Session, a TIB_Connection and whatever statement objects you
needed; have the method do its stuff; then destroy the datamodule.

But I don't think you have a scenario where you need to isolate one *query
request* from another to the extent that they require separate, concurrent
connections to the database. It appears to me that transaction isolation
meets your needs here -- and without MUTEXES, goodness gracious me!!

>The app dynamically creates 'n' MDI child windows in an MDI parent form.
>Each child just contains a memo component which is used to display call
>progress information for each call.

No problem with this. Your call-by-call function can create all the
objects it needs for a task and destroy them when it's
finished. Presumably, the parent form is global; and you could, if you
needed to, regenerate any request on demand, for review.

>With the same app in different environments I get different results such as:
>
>XPPro(Pentium 4 class) , my app, Paradox files - works fine
>XPPro(Pentium 4), my app, IB and IBO - call progress display disappears
>and some tel lines freeze forcing a task manager intervention to shut down
>WIn2000, my app, IB and IBO - the same as XPPro
>NT4/SP6, my app, Paradox files - works fine
>NT4/SP6, my app, IB and IBO - seems to work OK .(still doing some stress
>tests but way better than XPPro or WIn2000)

I'd be surprised if NT4 were any safer than the others. I'd guess there's
a luck factor there somewhere. I bet you're constantly getting race
conditions with the current model...but who really knows if that's all
that's happening? Some of the problems will be down to the fact that you
are using that hoary old beta version of IB and its broken client. Then,
on XP, if you are constantly making and breaking connections and your
database has a ".gdb" suffix, then you have a cute feature of XP at play
there that will cause these hangs.

>I have gone through so many installs and uninstalls of software on
>different machines and still can't figure out where the problem might be.
>I am guessing that this is a session problem??. ANY guidance or tips would
>be hugely appreciated.

I suggest that "guessing" on the basis of the assumptions you're making is
going to be a fairly time-consuming and harrowing way to learn that IB and
Fb are not Paradox, after all. You have the most advanced transactional
RDBMS, bar none, right there at your fingertips. You do not need mutexes
to isolate queries.

It would be a most worthwhile thing for you to pick up the TI sheets about
transactions from the IBO website (the TechInfo page). I'm sure that, once
you understand transaction isolation, the answers will come to you in the
proverbial "blinding flash of light".

Helen