If your CommitAction is set to caClose then when you call Commit all of the
datasets should Close. IBO automatically goes into search mode if it was
previously in a search mode when an open dataset is closed.

Is all you have to do is put in the call to Commit and it is done.

If I try to do what you are suggesting I do, how do you handle cases where
you might have more than one dataset in an edit state? Once one posts it
would force all others to post. I don't want to try and manage that kind of
complexity at the generic level.

Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: <mmenaz@...>
To: <IBObjects@yahoogroups.com>
Sent: Thursday, October 18, 2001 7:18 AM
Subject: Re: [IBO] AutoCommit and Commit instead of CommitRetaining?


> --- In IBObjects@y..., "Jason Wharton" <jwharton@i...> wrote:
> > If you have IBO allowing a check to the OAT then it will do a hard
> commit as
> > appropriate automatically.
> > If you want the dataset to close after the transaction is completed
> then
> > call Close in the AfterPost event of the dataset.
> > If you want me to do a hard Commit instead of a soft Commit when
> carrying
> > out the AutoCommit mode, I don't think that would be a useful
> feature
> > considering all of the other capabilities to manage transaction
> handles.
> >
> > Perhaps I have missed you point somehow?
> >
> Jason, in the past I've often thought about IBO being "incomplete" or
> "far from real world", just to discover then, having learned more
> about it, how handy and powerful it is.
> Just yesterday, I've filled the Connection FieldCharCase with "upper"
> for all my database domains to have ALL MY FORMS behave with the
> correct case for each field. This is not only time saving, but it's a
> huge help in the event that I have to change something in the future!
> So I want to explain to you what I want, asking you to put me in the
> right direction.
> Now I'm building forms for entering "basic data", like for customer
> table, employers, etc.
> I want each form to be displayed with the query state in dssSearch, so
> I can first check if the customer is already in the database or
> directly add it if I'm sure it's not. The search is useful even if
> I've to modify existent data.
> After each post, I would like to don't consume server resources or
> keeping transactions active, since there is no reason to have a
> transaction active for a long time.
> OAT seems something that works "in the background", trying to do it's
> best for keeping interbase to work at it's best, but seems to me that
> the following things would help much more in a situation like the
> above, sure very common.
> a) having the query CommitAction set to the actually not existent
> "caSearch", so the dataset is automatically put in dssSearch state
> after each commit.
> b) since the CommitAction is not fired when the Autocommit is set, and
> since the CommitRetaining is not appropriate in this situation, I
> would like to have AutoCommit set to "hard" commit instead of
> CommitRetaining (the property should be: none, Commit,
> CommitRetaining)
> Am I missing something?
> Thanks for your work and technical support
> Marco Menardi