Subject | Re: [IBO] Insert has really to "Fetch All Rows"? |
---|---|
Author | consultor_cys |
Post date | 2004-08-13T20:29:18Z |
>I saw your other post and tried (unsuccessfully) to reproduceHelen,
>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.
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. ItWhile I was analysing the paragraph I thought it could be an
>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?
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 caInvalidateCursorNo. caFetchAll is exactly what I don't want. They are all set to
>which, if your KeyLinks are correct, should fetch only the
>inserted rows after a
>commit. Have you accidentally changed this to caFetchAll?
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 setTo True.
>to True or False?
>When it's true, the dataset refetches all of the columnsThanks, I didn't know that.
>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.
>Note: with the default settings for TIBOQuery, posting insertsAre you perhaps calling Refresh somewhere?
>(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.
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 missingIt's not true. You've got that.
>in the problem description.
>Here's what the monitor shows when I insert a new row into anBut there's something I'm still not understanding: why is
>unfiltered query over the PROJECT table in the
>employee.fdb database, with all default settings,
>including AutoCommit true:
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