Subject | Re: Search mode question |
---|---|
Author | Steve Sinclair |
Post date | 2006-01-22T16:47:47Z |
--- In IBObjects@yahoogroups.com, "Jason Wharton" <jwharton@i...> wrote:
Thanks for the tip. The solution really was very obvious I don't know
why I didn't pick up on it ealrier. Not being that familiar with
ibobjects I had looked at the examples quite closely to get me started
and I had copied from the contacts transaction example the following:
procedure Tdm.qryAfterSearch(IB_Dataset: TIB_Dataset);
begin
// This makes it so that the user will not keep a transaction open
all day.
// This is VERY VERY important!
if trn.Started then
trn.Commit;
end;
Of course if the form is shown modally this is fine or if the form had
it's own transaction again no problem but of course if two forms have
queries sharing the same transaction then it's always going to put all
the open queries into the search state. I changed it to do a
commitretaining instead of a hard commit and it's working fine now.
I had to think a bit about what how much user intervention to permit
over the transaction. I figured I could do one of the following:
1) Just use autocommit
2) Force the user to commit or rollback before loading a new form
3) Use a timmer to complain every so often to the user that he can't
just leave transactions open.
4) Use a different transaction for each form
5) Just commitretaining if he loads a new form
I suppose you've had endless conversations about this but using commit
retaining seems to work for me for what I want this app to do :) I
thought i'd note it all down in case it helps someone else in the
future.
Steve
>modules with
> You are probably running into a problem typical of using data
> forms that you have multiple instances of. I don't think its alldatasets
> going into search mode but your controls are all pointing to the sameform
> dataset.
>
> My rule of thumb is if you are going to have multiple instances of a
> then keep the data access components on the form itself instead of on atheir data
> datamodule. There are many people who have little tricks to keep
> module instances coordinated with their form instances and I suspect youJason,
> either need to do that or get rid of them.
>
> Jason
>
Thanks for the tip. The solution really was very obvious I don't know
why I didn't pick up on it ealrier. Not being that familiar with
ibobjects I had looked at the examples quite closely to get me started
and I had copied from the contacts transaction example the following:
procedure Tdm.qryAfterSearch(IB_Dataset: TIB_Dataset);
begin
// This makes it so that the user will not keep a transaction open
all day.
// This is VERY VERY important!
if trn.Started then
trn.Commit;
end;
Of course if the form is shown modally this is fine or if the form had
it's own transaction again no problem but of course if two forms have
queries sharing the same transaction then it's always going to put all
the open queries into the search state. I changed it to do a
commitretaining instead of a hard commit and it's working fine now.
I had to think a bit about what how much user intervention to permit
over the transaction. I figured I could do one of the following:
1) Just use autocommit
2) Force the user to commit or rollback before loading a new form
3) Use a timmer to complain every so often to the user that he can't
just leave transactions open.
4) Use a different transaction for each form
5) Just commitretaining if he loads a new form
I suppose you've had endless conversations about this but using commit
retaining seems to work for me for what I want this app to do :) I
thought i'd note it all down in case it helps someone else in the
future.
Steve