I have a new screen which I wrote to manage the sizelocks on all tables using FIX_LH.

I set all tables to Sizelock 2.

I closed the application and restarted it, and some tables showed sizelock 0.

The online help states: Once the process is finished, the sizelock is decremented by 2, restoring it to the table's original sizelock value.

Is this right??

The tables which were reset to sizelock 0 ran though a select/readnext loop, during the app startup.

It should have changed the sizelock from 2 to 4 (ie incrementing by 2) and then from 4 to 2, to its ORIGINAL value, but no, it changed from 2 back to 0, which is not its original value.

Please can anyone advise if this is expected behaviour.

How can I enforce the keeping of tables as sizelock 2 until I am ready to resize them myself.

Do I need to reset tables to sizelock 2 after a select statement?

Colin

I would like to modify/clarify my earlier post as I was incorrect in some of the statements.

I set the tables to No Resize (sizelock 2).

Ran a select, and the tables remained as No Resize.

I set the tables to Resize Up (sizelock 1).

Ran a select, and the tables changed to Resizable (sizelock 0).

This conflicts with the Sizelock online help which states it should restore to its original state.

Is this supposed to happen like this, or is this an issue?

I set the tables to Resize Up (sizelock 1).

On another workstation I ran a lengthy select on a table.

During this process, on the first workstation I refreshed the screen to show the table, and this remained as Resize Up.

This conflicts with the Sizelock online help which states it should increment sizelock by 2.

When complete the Sizelock reset to Resizable (sizelock 0), as first issue above.

Is this supposed to happen like this, or is this an issue.

Also, is there a specific SELECT statement that is supposed to trigger the +2 increment, eg RLIST SELECT as opposed to Basic+ select?

I have some major issues with data corruption, and I am trying to ascertain the cause, and until I can confirm or not whether sizelock is working properly, I cannot pinpoint the area at risk.

The earlier questions remain, should I reset Sizelock=2 manually after a select statement?

Thanks

Colin

Recent tests uncovered a behavior in Fix_LH where the function would automatically reduce Size Lock by 4. This was a exit check to ensure any size lock changes by Fix_LH were cleared. For example ReadNext calls Fix_LH to set/unset the size lock. This reset caused problems setting a specific size lock value with Fix_LH because the any specified size lock values less than 4 would be automatically reset back to 0. The problem has been fixed for OI 9.3.2.

You can work around the issue by taking the reset reduction into account. For example, if your desired size lock is 2 then call Fix_LH with a desired size lock of 6.. If your desired value of Sizelock is 1 then call Fix_LH with a desired size lock of 5.

I think this will explain the behavior you are setting. Please let me know if you have further questions.

Thanks Jared

Is this a LH fix, ie something we can get for OI 8.0.8, we it will be some time before we go through the hoops to OI9x.

Colin

There are no scheduled patch releases for 8.x

Almost all new workstations are x64 and since 8.x has complications with DEP most administrators are hesitant to disable DEP for backward compatibility. All forward development and maintenance has been on version 9.x because it is supported on current platforms.

View this thread on the Works forum...