The Model Is King, Pt 1

In DataEase and Ffenics, the data model -- that thing that is represented by a little diagram in the query by model dialog -- is king. Whenever a change in a procedure, say, sends your procedure body to the waste disposal, you can bet you made a change that affected the data model.

I was reminded of this in a support call this week, where the user had a pride-and-joy procedure with a beatiful, bouncing layout ... and they wanted to make what seemed like a simple change. They added a line of code before the main 'for' loop that checked to see that a value in the data-entry form was set:

if data-entry MyValueToCheck = blank then exit . end .

Why would such a simple addition bring the roof down? Because it changes the data model.

Basically -- and this is another golden rule -- for every document, there can only be one parenting table. Perhaps less obvious is that this 'if' command required something to parent it ... and in these instances Ffenics and DataEase inserts its standby DQL Scheduler. Try it and see:

1. Mock up a simple for/list records
2. Accept the default body
3. Move one of the fields just to highlight that it is changed
4. Add an if command above the for (try 'if year ( current extended date ) = 2010 then exit . end .')
5. Compile and accept the default 'merge changes' for the new layout.
6. Note than previously moved field is back to its default position.
7. Go to Document -- View Data model to see that the DQL Scheduler table has been inserted at the left.

I'm working on an article to document what types of changes will kill your body/layout.

In the meantime, there are several workarounds (other than start again...):

1. Add the sense of the 'if' to the selection criteria for the main 'for' ('for MyTable with data-entry MyField not = blank' )
2. Add the 'if ... exit ... end' statement as is immediately after the 'for MyTable'
3. Add some logic (e.g. make the field required) to the data-entry form/interactive header to do the check for you in the first place.

Note that 1 and 2 will likely incur a small performance overhead depending on what else you are doing and on the number of records in MyTable -- you'll have to be the judge of what is acceptable.