Sizelock issue (OpenInsight 32-bit) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
{{tag>category:"OpenInsight 32-bit" author:"Colin Rule" author:"Jared Bratu"}}

[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]


==== Sizelock issue (OpenInsight 32-bit) ====
=== At 21 JUN 2012 09:12:38PM Colin Rule wrote: ===
 
 
<QUOTE>
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: [b]Once the process is finished, the sizelock is decremented by 2, restoring it to the table's original sizelock value.[/b]



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


</QUOTE>
----

=== At 21 JUN 2012 11:19PM Colin Rule wrote:  ===

<QUOTE>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





</QUOTE>

----

=== At 22 JUN 2012 08:47AM Jared Bratu wrote:  ===

<QUOTE>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.

</QUOTE>

----

=== At 24 JUN 2012 07:48PM Colin Rule wrote:  ===

<QUOTE>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



</QUOTE>

----

=== At 25 JUN 2012 10:10AM Jared Bratu wrote:  ===

<QUOTE>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.

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=41B1FDF60004F085D0BA9A700|View this thread on the Works forum...]]