>I saw your other post and tried (unsuccessfully) to reproduce
>it. Often I
>see these posts late at night and, when I can't reproduce it,
>I hope that someone who has seen the same thing will hop in
>and try to help.
>I suppose most people feel that way. Weird problems usually
>come from weird
>combinations of conditions and simple answers don't always
>appear like magic.

Helen,

I rewrote and reposted it for many reasons:

1) my english is understandable but isn't good, exactly.
2) I was afraid of not been clear or posting a dumb question.
3) since I discovered the cause of the slowness of my software it's
becoming a nightmare.

Sorry for all these points.

>This (sorry!! -- Author) is an error in the GSG. It
>should say "Even if the dataset has CommitAction caFetchAll.."

>This article is about filtering, though, and that observation
>is saying that IBO respects the filters when it updates
>the buffers. Your problem seems to come from an
>unfiltered dataset - is that so?

While I was analysing the paragraph I thought it could be an
ortograph error, but the differences between the words caFetchAll and
FetchAllRows gave me a little bit of hope.

>By default, the TIBOQuery has CommitAction set to caInvalidateCursor
>which, if your KeyLinks are correct, should fetch only the
>inserted rows after a
>commit. Have you accidentally changed this to caFetchAll?

No. caFetchAll is exactly what I don't want. They are all set to
caInvalidateCursor.
To make a test, in one of my tables, I changed it to caRefresh.

>Do you have correct KeyLinks in this dataset?

I not sure, but I'm using "fbDataSet.KeyLinksAutoDefine := TRUE;" in
the setup area of all my tables. Is that enought?

>Are you opening a huge dataset here? No WHERE clause?

Yes to the first one and No to the last one.

I discovered the problem because cancelling an insert in a 27k records
table took 15 seconds. But it happens even when I'm filtering it with
the primary key. But I'm doing it via TIBOQuery.SQL property

>Assuming your KeyLinks are correct, do you have FetchWholeRows set
>to True or False?

To True.

>When it's true, the dataset refetches all of the columns
>whenever it needs
>to update the buffer. This is quicker if the dataset is
>not huge. When it's false, it will first update the key
>buffer and try to refresh the dataset from rows it already
>has in the row buffer. If there are no keylinks, this won't
>help, because the key buffer is populated from the keylinks.

Thanks, I didn't know that.

>Note: with the default settings for TIBOQuery, posting inserts
>(even with AutoCommit true) doesn't cause a FetchAll. It will
>happen if/when you explicitly call Refresh on a TDataset.
>You don't have any control over what gets requeried.

Are you perhaps calling Refresh somewhere?

Here is the point where I **really** have to ask for your pardon.
Look that:

procedure TDM.DMAfterPost(DataSet: TDataSet);
begin
AddToPostedTables(DataSet);
DataSet.Refresh;
end;

procedure TDM.OpenFBDataSet(fbDataSet : TIBODataset; sTableName :
string; sOrder : string = ''; dsDataSource : TDataSource = NIL;
sSQL : string = ''; bUltimaAtualizacao : boolean = TRUE);
begin
...
fbDataSet.AfterPost := DMAfterPost;
...
end;

For some reason, we never look where the problem is. There are others
calls to Refresh that where already been disabled when I was trying
to save the problem, but no this one.

I've made that because we are working with a software that, somewhere
in the time, will be messing with tons of users that must be viewing
the really last version of some records in a browser (a patient
schedule).

I've recently developed a way to refresh commited tables. It uses
a table to store changed tables, a stored procedure,
Transaction.OnAfterCommit, a TIB_Events component and an Application
Idle Timer, to refresh only if the user is not using the software
(I'm thinking in a solution to do it by record). My (dumb) mistake
was forgetting to remove this Refresh from AfterPost, just
because I'm not setting it via object inspector. Sorry again.

>Sorry I can't be much help, because *something* is missing
>in the problem description.

It's not true. You've got that.

>Here's what the monitor shows when I insert a new row into an
>unfiltered query over the PROJECT table in the
>employee.fdb database, with all default settings,
>including AutoCommit true:

But there's something I'm still not understanding: why is
it fetching all records if the table is filtered with WHERE? But
don't waste your time thinking or answering me right now. I want to
be sure of that before feeding you with wrong information again.

I can't find words to thank you.

Antonio