SDO bug? (jumps to last record)

C

cknicker

New Member
10.1B03 Windows platform. I'm not versed much in Smart Objects, nonetheless I need to get this bug fixed so any suggestions are appreciated. When requesting programmatically to position to a given row in a Smart browser the browse will instead jump to the last record in the browse. Depending on the db data, it only happens when attempting to position below a given record in the browse. If you change key values so the browse records sorts differently it will happen on a different record but still the same relative row from the top.
I've debugged the problem down to the fetchRowIdent call in a LocateRecID function in the SDO:

cRowident = DYNAMIC-FUNCTION('rowidwhere':u, cSearch).
IF cRowident NE ? THEN
DYNAMIC-FUNCTION('fetchrowident':u, cRowIdent, " ":U).
PUBLISH "FillInSidePanel":U.

cRowIdent gets set to non-blank value which is correct but after the call to fetchRowIdent I see the browse is repositioned at the last record. Return values for fetchrowident are for the last record.
At this point, I'm a bit intimidated at the thought of trying to debug data.p or whatever stock ADM2 code seems to be messing up. Suggestions?
 
Hi there!

I'm using 10.1A02 here, so my results may vary, but this approach (rowidWhere followed by a fetchRowIdent) is working fine here.

If the rowid returned by rowidWhere is for the last record in the dataset, then I would message out the value in cWhere to see what where clause is being passed in. It could be malformed in some circumstances, resulting in the last rowid being returned, and then the fetchRowIdent does its job.

Have a look at the value in cWhere for a reposition that works, and compare with one that just jumps to the end. If you post the results of the message, perhaps something will look suspect to us?
 
Thanks for the reply. I did check the row id returned by rowidwhere and it is for the correct record so it's definitely a problem within fetchrowident. I may try changing the RebuildOnRepos setting for the SDO as soon as I figure out how to do that since I'm suspicious result set handling may be part of the issue here.
 
well, I did discover a workaround. I check the returned rowid from fetchRowIdent. If it doesn't match cRowIdent I simply repeat the fetchRowIdent call and the 2nd time it works...
 
Wow. That sounds like a bug in the ADM to me. I think you're on the right lines with the record sets being involved, but even with a large record set and a small rowsToBatch, I can't reproduce it here!

Maybe it's been introduced after 10.1A02? Regardless, you could report it to PSC as a bug?

I'll be sure to watch for this when we next upgrade. Bound to catch me out - we use this approach all the time.
 
I am going to try and report this to Progress and will post back if anything comes of that. Be warned that it doesn't happen with all dbs. I may look at the rowsToBatch settings to see if that changes the behavior at all so thanks for that tip.
 
You must log in or register to reply here.
Back
Top