TOPIC:

Hi All,

We have been getting the above exception from xs2ado in various places in our application. After some digging around we found it was happening when bBrowser was filling a screen grid with data, but only if the data did not fill the display area and require a vertical scroll bar. The actual call that was triggering the problem, when it happened, was a Skip call to reposition a recordset at line 715 in file bBrowser (Control).prg After more playing it only seemed to happen when the number of rows to skip was zero.

It seemed to me that skipping zero rows should be effectively a "do nothing" operation but it seemed be causing this problem for us. Without fully understanding why the code might generate a skip for zero rows, or if there might be side effects, I decided to adjust the code to not call the Skip if the skip count was zero and see if that broke anything. The if condition in the code clearly implies that skipping zero rows might happen.

Here is a bit of the code with my change:

// Prüfen, ob Datensatzgruppen berücksichtigt werden müssen
if !self:ExistRecordGroups() .or. uRecCount = 0
// Datensatzgruppen existieren nicht
lSuccess := iif(uRecCount == 0, TRUE, self:oServer:Skip(uRecCount)) // JCB
elseif uRecCount < 0
// Unter Berücksichtigung von Datensatzgruppen in Richtung Dateianfang skippen

I have marked the line I changed, which was line 715 in the code we have, with my initials. I just made the call to the Skip method conditional so it is not called when the skip count is zero.

This seems to have fixed the problem for us, so I thought I should report it in case it helps someone else.

Best Regards,
John

Hi John,

I checked the sources and with bArrayServer or DBF a Skip(0) works as expected in bBrowser.
The problem with this wrong return value from Skip(0) must be inside xs2ado and the recordset.

Best Regards
Gerhard

Hi John,
as Gerhard has pointed out with bArrayServer or DBF there is no problem.
This issue is related to the phantom records in bBrowser and Vo2Ado recordset.

Thanks for the replies,
I am running with SQL Server and I have noticed in the code that there seems to be different arrangements in some places for SQL databases, so that may be related.
During my debugging I also noticed that the problem was only happening during a call to CacheUpdate. The same code for many other grids in our application is not experiencing any issue and I never discovered what is different about the few places where it happened. The cache may be what diobrando refers to as "phantom records", so that may be involved too.
When I noticed in the code that skips of zero records seem to be allowed for, I wondered if the skip, apart from not moving the recordset, might have some other necessary side effects. That made me concerned that suppressing these zero record skips might cause a problem, but our experience since the change seems to indicate that is not the case.
There may be a proper fix elsewhere but we are good for now with this one.

I should also mention that I seem to have a different problem in a similar area of the code. In a few cases we have bBrowser going into a loop while loading a grid and subsequently getting a stack overflow. To be more exact, it looks like it actually completes loading everything but then gets into a loop after that. The loop also involves a call to CacheUpdate. The loop process seems to start with the recordset linked to the grid being changed by a call to SetRecordset. This triggers a grid update, and at the end of that I think an event raised from a CellSelect triggers a change of recordset again, hence the loop. I am still digging around with this one.

Best Regards,
John

John,

do you have some code to test this loop while loading and getting a stack overflow and also for that CacheUpdate?

Regards
Gerhard

Hi Gerhard,
I have made more progress on that loop and I believe the problem is in our code, not any library code. What seems to be happening is that a bBrowser grid is loaded and I think the cursor gets put in the first row of the grid. This triggers a CellSelect event that gets handled in our code. The code there does something I think is odd, it reloads all the grid data again. This triggers another CellSelect and the process repeats, hence the loop. Reloading the grid on CellSelect seemed odd to me but it started to make sense when I went back to the users of this system. I should mention the system was developed by someone else in VO and I am porting it to X#. The current production VO system behaves OK and we are down to shaking the last few bugs out of the X# code, including this one. There are two bBrowser grids on the window and we are loading the first. The CellSelect on the first grid is supposed to be loading related records, master/detail style, into the second grid, not reloading the first. The production code allows wildcard searches with matches in the first grid so you click on the one of interest and the second grid repopulates. The code I have does not seem to do that, so perhaps I have an old version too. I got this far yesterday, hopefully today I fix it.

Best Regards,
John