>
> The list doesn't accept attachments. You can paste the DFM code of the
> small group of objects into an email. I don't need .pas code right now -
> the first thing to look at is how those properties have been set.
>

I found the problem - my data module was inhertied from TDataModule not
my normal TdmParent, which automatically assigns the IB_Connection of
the queries - it still accessed the database and did the job, but it screwed
over the transactions for some reason. - But that did fix the problem.

> > > Also, don't use TIB_Query for update SQL. It's too wasteful. Use
> > > TIB_Cursor or TIB_DSQL.
> >
> >Thanks for this hint - Now I have a few hours work to do to change a

couple

> >of hundred TIB_Query's to TIB_Cursors :-)
>
> I'm curious to know why you have "a couple of hundred" update objects in a
> single application.
>

The application has been under development for over 3 years now and is a
very large GP management system. Interbase has performed very well for us
except for 2 areas:

1) Using 2 connections to the database - one with a TIB_Connection and
one with a TDatabase gave random exceptions "Declared cursor already
exists". I needed the two connections until a fixed a bug in an old version
of TIBOQuery that prevented it being used to feed QuickReports. Going back
to 1 connection seems to have fixed this problem.

2) I still have problems with "Lost connection to database". I am
convinced it is caused by calls made to FreeUDF.lib math and string
functions. It causes AV's in GDS32.DLL and Guardian has to restart
interbase. I would love some feedback on this one although it may not be
the correct NG for this topic

One of the reasons I have a lot of update queries, is that previously when I
liked the idea of writing a lot of stored procedures to do complicated
tasks, I found that while my Delphi code became much simpler, the user
interface suffered through not being able to view progress, or interrupt the
action. I don't know if anyone has a solution to this.

>
> I always use TIB_DSQL for executing "Execute" statements, whether they are
> SPs or DSQL. You can pick up any return values you want via the Fields[]
> property after execution.
>
> That said, I might not have more than one or two separated DML operations
> in an enitire application. An example of where I might use one is where I
> have a lookup set in a KeySource/Lookup relationship and the user wants to
> add another lookup row. Rather than interfere with the lookup dataset,
> I'll use an ib_sql with input parameters for this purpose.
>
> For regular DML operations related to the current row of a dataset
> (TIB_Query or TIB_Cursor) I use the xxxSQL properties to do updates,
> deletes and inserts - and then only if RequestLive isn't applicable to the
> set. That's how IBO is designed to work for the 98% case. My attitude is
> "Why keep a dog and do the barking yourself?"
>

Thanks for this info. I never use data aware controls because I haven't
worked out how to have good transaction control when actions depend on the
user.

Every database action I do is wrapped in try..finally's all over theplace to
ensure queries are closed, transactions are committed/rolled back, and
memory management tight. How do you handle transaction control with request
live on and someone is just perusing a grid?

Thanks



Josh