Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Fix_LH

Does anyone know the logic behind the Fix_LH routine in OI? When a table with a GFE is "fixed", the table must be accessed at a lower level than RTP57. That is how all the "good" records are extracted and the GFE's are skipped. Knowing how to do that, as opposed to Readnexting (which stops upon hitting a GFE) would be very helpful with my currently client and cleaning up their data.

Thanks in advance!

Michael

Comments

  • I don't know. You could create a profile log and get a good insight into the various routines that get called. Then you might be able to use that and create a workflow process for Fix_LH.
  • Hola all,

    The conventional wisdom among some of the "old-timers" with my client is that FIX_LH can actually be run while a table is in use. I know that RTI_MAKETABLE absolutely cannot, and I thought FIX_LH was the same. Does anyone know if FIX_LH, especially the compress function, can be used while a table is being accessed?

    Gracias! And Happy Easter!
  • Without endorsing the practice, FIX_LH can be used on a live table because it works on the groups that have problems (like a surgical strike) and doesn't do anything to the overall structure of the table itself. I don't know about the safety of using the compress function on a live table. My gut tells me it should also work because it is just reorganizing frames, which is what Linear Hash is capable of doing anyway. I would expect access to the table to be slow during this process.

    RTI_MAKETABLE creates a new table and copies the rows from the old one. This is why it can't be used on a live table.
Sign In or Register to comment.