Hi,
I've got a window with a smartDataObject that I want to position to a specific record.
As pointed out in KB #P124079, when RebuildOnRepos is set off the fetchRowIdent may fail if the number of records per batch is too small...
Is there a way to fetch the row while keeping the flag RebuildOnRepos off?
If "fixed" the problem by doing an second fetchrowident if the first one fails but that is not a definite solution...
Best regards,
Wim
As far as I can see the knowledgebase entry only points out that the fetchRowident is slow. This is true about any (re)position operation when RebuildOnRepos is off, since the setting implies that all records prior to the searched record need to be on the client. There is no mention of failure.
The point I tried to make was that this seems like a bug that we're not aware of and that you probably should contact Support. I have to admit that I am not fully up to date with the recent changes to the knowledgebase system, but the entry that matches your number in the old system only mentions the performance effect of RebuilOnRepos and says nothing about failure. It would also be interesting to know which version you see this problem and if you actually see a difference in behavior depending on the batch size.
With RebuildOnRepos turned OFF the behavior I'm seeing is that when the record to be fetched is outside the batch size, e.g. record to be fetched is record # 320 and the batch size is 200, ALL records are fetched but NO repositioning takes place to the right record. The second fetchRowIdent right after that correctly repositions... So I agree with you that this may be a bug.
If I increase the rows to batch to include the record (e.g. by setting it to 400), the fetchRowIdent works correctly but obviously there's a performance penalty by getting more records to the client side.
The work around I've used for now is to set the RowsToBatch low (20) and turn RebuildOnRepos ON. That works and is fast. Only problem I had was when ALL records need to be exported but in that case I temporarely turn off the RebuildOnRepos, set RowsToBatch to a high number (1000) and do a fetchFirst, fetchLast to get all records to the client (to bad there isn't a fetchALL which could do all of that in one go ;-))
I'm using OE 10.1C SP04.
ham wrote:
With RebuildOnRepos turned OFF the behavior I'm seeing is that when the record to be fetched is outside the batch size, e.g. record to be fetched is record # 320 and the batch size is 200, ALL records are fetched but NO repositioning takes place to the right record. The second fetchRowIdent right after that correctly repositions... So I agree with you that this may be a bug.
That is a bug. It is quite serious so I assume it is fixed in newer releases, but I do not know for sure. You should check with Support. You could try to use findRowWhere or findRow instead. It used to be recommended to use this instead of fetchRowident, since fetchRowident needed two appserver hits.(This is not the case anymore and probably not in 10.1C)
If I increase the rows to batch to include the record (e.g. by setting it to 400), the fetchRowIdent works correctly but obviously there's a performance penalty by getting more records to the client side.The work around I've used for now is to set the RowsToBatch low (20) and turn RebuildOnRepos ON. That works and is fast. Only problem I had was when ALL records need to be exported but in that case I temporarely turn off the RebuildOnRepos, set RowsToBatch to a high number (1000) and do a fetchFirst, fetchLast to get all records to the client (to bad there isn't a fetchALL which could do all of that in one go ;-))
I'm using OE 10.1C SP04.
There's no fetchAll, but I believe you can set batchsize to 0 (=ALL) and only do a fetchFirst and avoid the fetchLast. You could also try to call the refreshQuery function instead of fetchFirst.The main difference from a fetchFirst is that is will reopen and reposition to current record and that it only works when the query is already opened. I'm not sure if this exists or works in 10.1C though.