{{tag>category:"OpenInsight 32-Bit" author:"Colin Rule" author:"Bill Reynaldos" author:"Richard Hunt" author:"Aaron Kaplan" author:"Jim Vaughan"}}
[[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]]
==== Table Compress (OpenInsight 32-Bit) ====
=== At 13 MAY 2008 10:29:16PM Colin Rule wrote: ===
I have a table with 650,000 records, and have run a proceure to clear unwanted items, and now have 510,000 records.
The database table is the same size, and has not compressed, at 350mb before and after.
Sizelock is zero, so should contract as per the online help.
I have run the Compress via the Database manager, but would prefer to have this as part of my cleanup program. Is there any procedure call to do this programattically, as we dont expose the database manager to our users.
Colin
----
=== At 14 MAY 2008 08:59AM Bill Reynaldos wrote: ===
Colin - You might take a look at the FIX_LH subroutine in the online Help to check out some of the available options.
Bill
----
=== At 14 MAY 2008 12:37PM Richard Hunt wrote: ===
The "LK" file is sized based upon the modulo and frame size (frame_size * modulo). It is not based upon the row count. If the frame size is 1,024 and the modulo is 23 then the "LK" file size would be 23,552. Along with that formula you have the threshold and the size lock that controls resizing.
The "OV" file is sized based upon the overflow frame count and the frame size. And a "compress" would remove unused overflow frames. So doing a "compress" would only effect the "OV" file.
If you are looking for a drastic way to "refresh" or "resize" your table; then copy all the rows to a temp table, clear the original table, verify that the original table is now sized to the modulo of 1, then copy back all the rows from the temp table. This procedure would do what you probably would want, except for the time it takes to do it.
Unless you are desperately needing disk space, just leave the table as is.
----
=== At 14 MAY 2008 03:38PM Aaron Kaplan wrote: ===
Sometimes, but not often, the information that determines when to contract gets a little corrupt. Not enough to destroy database integrity, but enough to stop resizing.
Try setting the sizelock to 2, then back to 0 and modifying the threshold value to 85%. That might be enough to trigger a resize. Resizes are a slow process though, and depending on the size of the records and how they are stored, it might take a while for the file to start to shrink. If you have large overflows and/or most of the records you deleted were in overflows, then the file might never resize.
This is because resizing is based off the percentage of empty frames verses the number of full frames. This is the threshold value. Increasing the threshold means that there should be a higher number of used frames to empty frames, so the file should contract. This means that if you set the threshold to 99%, you should start to see the file contact.
However, as Richard rightly points out, if you don't need the disk space, don't worry about it. I'm reasonably confident the system is working as intended, just not as expected.
----
=== At 15 MAY 2008 03:24PM Jim Vaughan wrote: ===
Aaron,
So is the weather too nice in the UK for you to make it to Vegas?
Your presence is missed.
----
=== At 04 JUN 2008 04:29AM Aaron Kaplan wrote: ===
Thanks. I missed going and catching up with everyone as well.
Unfortunately, I had a pressing family engagement back in Philadelphia that couldn't be postponed.
----
=== At 04 JUN 2008 01:52PM Jim Vaughan wrote: ===
See you next year?
----
=== At 06 JUN 2008 02:25AM Aaron Kaplan wrote: ===
Or next conference.
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=FA6B9AF2581A3F4585257449000DAA70|View this thread on the Works forum...]]