After more than 100 Flexibility applications at more than 40 client sites I have never seen Flexibility in within itself cause corruption of Macola data. The nature of how Flexibility works prevents Flexibility from "corrupting" data.
Flexibility works by "Hooking" message calls to MS Windows Events. Hooking is a way of examining message calls to windows before they are sent to a window within MS Windows. This is basically a way of capturing input (keyboard and mouse) information before MS Windows has an opportunity to do anything with it. When using Hooking you determine what the keyboard or mouse message is trying to do to which window (a window can be a form, control, or any area of the screen that has a unique window handle) and then you can run custom code, pass on the original, message, and then run custom code again. With Flexibility the only custom code that is run is the initiation of the event within the Flexibility code itself. This code does nothing within itself; the only time it does anything is when a programmer adds code to the event proceure within the code.
As you can see, because of the nature of how Flexibility works, it never actually works with the database or modifies the original message sent to a window (with the exception of procedures like the macForm_Save procedure which provides an AllowSave value that when set to False prevents the passing of the window message to the "OK" button or "Save" toolbar button). Even an error in the event procedure within Flexibility will not cause the window message to be corrupted, or prevent it from running, because the Flexibility event procedure runs in a separate process from the Hooking code.
Now that I have detailed why Flexibility can not "corrupt" Macola, I will reiterate what others have said previously. Flexibility can be used for evil as well as good as is the case with any programming language. If corruption is caused through the use of Flexibility, the cause of the corruption is in the logic of the code itself.
I will say one last thing; in the early days of Flexibility Macola suggested the use of the ERS Data Objects. This object was a Macola designed database object that encapsulated both ADO and Btrieve transactional database calls. The btrieve transactional database calls could write data to the database in a manner that was inconsistent with standard Btrieve data writes. An example of this would be the dynamic portion of the next lot number in the IMCTLFIL_SQL (to late in the evening to look up the actual field name). If a user were to use the ERS Recordset Object from within Flexibility, then yes, Macola data could be corrupted. This object saw limited use and due to the release of newer versions of Pervasive that included improved ODBC drivers, the ERS Objects were no longer necessary not long after the release of Flexibility.
Scott Travis
infoSpring, LLC.
