Flexibilty Corruption

[vbajock]

I have been called in to consult on an existing Flex app. The customer has two applications, Macola ES and a custom financial app, and they are not balancing out. There is a Flexibilty app that is supposed to bridge the two. The customer says a consultant working for an unidentified Macola VAR told him that it is possible for "Flexibity to Corrupt Macola Data" and this is the cause of the problem. This statement is utterly ludicrous on its face, but I must ask the community if they have ever heard of any such problem so I can show the customer the opinion of the professional community found on this forum. I am stunned that anyone working for a Macola organization of any kind would say this. The end result is that the customer is thinking of junking Macola.
Thanks for your help
Kirk

 

[dgillz]

I have heard Macola Tech Support say this type of thing, that writing or altering records in the Macola database, be it with MS Access, VBA, or a 3rd party app, can corrupt the data.

However, the only time I ever experienced that was in the initial testing of an application. I have a client with a C++ program that imports all of his orders (he wrote it himself), and he was not properly populating the OEORDHDR_SQL records. After comparing the records he wrote versus a few manually entered records, we tweaked the code and everything is fine. We have had no problems for months and months.

I will bet big $ that the person in charge of this project did not know Macola very well, or did not test the application, or did not write the flex to properly populate all the fields in the record as a hand entered record would be populated. Or maybe all of the above.

I recommend that you compare records created by Flex to records created manually and look closely at the differences.

If I can help let me know.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[kscheeler]

I agree with dgillz in that someone could write a flex app that wrote or updated records that went against Macola's standard business rules and therefore would look like junk data in Macola.

I also agree that you need to compare data touched only by ES and data touched by flex to see the differences and make the necessary adjustments.

Kevin Scheeler

 

[abaldwin]

I used to make a living updating, adding, and deleting Macola data using Flex Applications. I agree wholeheartedly with Don that the logic itself can be wrong and not all the proper entries are made etc.

After all, Flex is not making the actual data changes. The connection object used to access the db is making the changes. I have seen processes taking a while and the user reboot the machine in the middle of an update and the data becomes "corrupt". I put the corrupt in quotes because the record may or may not be complete and Macola does not have the information to handle its processes. This is not necessarily a problem with Flex but is most likely a problem with connectivity OR..........The application is wrong to begin with.

TEST TEST TEST TEST TEST.


Andy

Andy Baldwin

 

[vbajock]

After all, Flex is not making the actual data changes. The connection object used to access the db is making the changes"

Precisely. That's why saying "Flexibilty can corrupt data" is hogwash. Bad programming corrupts data. The carpenter is blaming his tools.

 

[vbajock]

I guess I need to re-phrase the question. DOes anyone know of any situation where Flex, in and of itself, due to some internal bug or design flaw of Flex itself, has caused data corruption?

 

[abaldwin]

NO.

Andy Baldwin

 

[dgillz]

No.

Ditto for tools such as SQL Stored Procedures, MS Access, VB, etc., etc.

Every instance of this I have ever seen or heard about was the bad programming Kirk talked about.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[vbajock]

So, Macola has not reported any instance of Flexibilty per se, corrupting data? VARS pls!

 

[dgillz]

I just searched the Macola infomine for "Flexibility" +"Corruption" and found nothing. I also searched for just "Flexibility", and just "Corrupt" and "Corruption" and found nothing.

This does not mean it has not been reported, but it certainly did not make the reseller portal.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[Rob7]

Flex as an application is not going to corrupt data, only the logic within it. Using either the ADO connection or the macForm connection have proven to be very solid over the last 5 years that I have been using them. The only time I have seen an application corrupt data is when someone connected through Access to Pervasive using the link rather than import. The end result was that errant characters were put in fields.

Rob

Cytec Corporation
rbrown@cyteccorp.com

 

[stravis]

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.

 

[TardisInc]

Well, I've run across more than a few times where Macola screws up my VBA apps.

I have to export everything, reset the form to Macola base, then add the project and import everything, then it runs fine. This also happens with my Access2K, so it's a VBA thingy, not a Macola thingy. I've been a Microsoft ISV and Developer for over 10 years.

Larry Wilson
TARDIS Systems, Inc.
larry@tardissystems.com
972-768-2965

 

[abaldwin]

I have heard vendors and even Macola state that the VBA application has been corrupted and needs to be exproted and reimported.

I personally have not seen this in any of my projects. I have seen a person update another program or even Macola itself where they are changing the location and or capabilities of certain dll's which may be referenced in a VBA project. This will certainly screw up the vba project. An export here is not required (as macola will tell you to do).

Sometimes you have to reference the old dll's sometimes you have to find work arounds.

Andy Baldwin