I have a simple application that was basically working, and now is essentially non-functional.  Need recovery assistance and autopsy analysis.

History:
I added three more new fields to the database, and then added three Read Only elements at the end of the single form for that database.

I added a box with a colored border by using backfill.
I decided to reposition some fields for a more logical flow.  Doing Layout Design Saves, and Reconciling with Application to test LU statements.

After repositioning fields, I did an align across the top to make sure all fields were in proper sequence. 

I ran the program, and suddenly calculations that were OK before, were not correct.  Some fields wre being blanked out.  Appeared to be a result of going to fields in wrong sequence. 

After spending time unsuccessfully looking for obvious errors, I dedided to force the control of the flow over any alignment issues, I went into each field and added a GOTO statement on the Element Exit action.  That did not fix it.  I removed the box element, could see no relationship, but who knows....no change with that either.

After some more unsuccessful analysis, I decided it was best to trace the actions, so I then added the following statement to every element's Element Exit event:
WriteLn ("Starting on Element Exit routines for: "+ @CurrentElement()). This appeared to be a good move, Was able to see flow of execution.

Sure enough, program execution was skipping some fileds, going to wrong fields, and results were unexpected.  These executions were totally non-compliant with the GOTO statements.

After reviewing specs on the elements, looking for Read Onlys, etc. chasing for a while (too long) I then added the following statments:
WriteLn ("Starting on Element Entry routines for: "+ @CurrentElement()).
and
WriteLn ("Starting on Element Change routines for: "+ @CurrentElement()). to their respective fields.  Write Ln is still working OK, but results make no sense at all.  No reason for the actions that are happening.

Sample of WriteLn results are:
Starting on Element Exit routines for: REP
Starting on Element Change routines for: REP
Starting on Element Change routines for: REP

Actually, this was the result after leaving the first field: WORKDAY.  I should have seen a message about Exiting WORKDAY, and Change in WORKDAY.  The next field is REP, and I should have seen a message about Entry into REP.  I never pressed ENTER or TAB to leave the REP field, it is not Read Only, and the cursor is sitting there.

This is just a short sample.  Later in the flow, I may see about 16-20 WriteLn statements from 4 or more fields that I never went into.

Then decided to copy the Design, hoping to be able to rebuild a new application.  I  made a new empty application.  I opened that application and did a Merge Application with the "defective " one.  I then did a Mass Delete to remove all records from the two databases in the new application.  Same results.....firing sequences are not logical.  It would appear that this application and the designer files are totally corrupted.

I had been making frequent Saves in the Layout mode after checking out that Program had no errors.  But unfortunately, somewhere in the process it would appear that the designer file became corrupted with no indication.  Because of testing LU statements, I also had done Replications with existing database.  (It is impractical to create a new application every time you want to test some programming, but I may have to do that from now on...GROAN).

System had been shut down and rebooted, no change.

I would like to sent the file for analysis and/or recovery.  Any recomendations to recover here will be great, but really need to understand how this has happened.

Hi Carl.....

Thanks for the thought, but been there also.  My understanding is that is that the Programming Sequences are only for Programs Statements that used to be prefaced in Q&A with a #n vs. the < or > prefaces, or by pressing F8.  In that situation the n determined the sequence of those statements.

I almost never used any of those statments, always use on Field Enter/Exit.  But even though those are the guidelines, there is still a lot to understand about the logic of Sesame.  So even though I had no Form Change events written, I still had gone througn and resequenced the list of fields to match the same sequence as the flow I had laid out on the form, but no difference.

One thing I have learned is that if you use the mouse to click in any field, the Element Exit event seems to be called up in the element the mouse was last in.  Thinking about it I am not surprised, but I am still accustomed to using Tab and Enter from Q&A and triggering events in that manner.  In Q&A, you could do a Shift-Tab to back into a field without triggering the On Exit/On Enter actions between the two fields.   In Sesame that cannot be done, the events will trigger.

It also looks like Element Exit events fire before Element Change events.  But I am rerely seeing Element Enter events being called up.

I am now in the process of removing elements and programming statements, one field at a time, looking for a cause.....I will beat this!

Thanks again, though, I appreciate the help.

Quote:


Besides the use of  the writeln window is there some kind of command line switch we can use to have a trace feature turned on?

Hello Ray....

I just got in, and sent a Zip file to your attention.  I have made progress last night and seem to have isolated a problem where one programming line does an XLU, returns the correct value (using WriteLn to see value), but destination element refuses to accept any value but 0.  Even manually changing it, it returns to 0.  It is at this point that the programming seems to jump into a non-logical sequence of elements and programming.  WriteLn shows activity in elements where it should never go.  I will continue to pick away at my end, but hope you can do an "autopsy" to find out what is really happening.

Thanks for your help, and wishing you great success.