Walt, you will find discussion about speed issues and its remedies in the following link,

http://www.lantica.com/Forum2/cgi-bin/yabb/YaBB.pl?board=gen_disc;action=display...

Sesame compiles all of the form programming when the form opens. This prevents us from compiling or interpreting the programming while the user is trying to actually interact with the form. It also allows Sesame to know if there are any problems or syntax errors in the program before any of it runs.

What could be the reason why it has been taking so long? Is it the size of the code? Is it the size of file? What are the determining factors as to how long it takes to load the file in retrieve spec? What can we do to shorten that time on the user's end?

When you run "test" inside SDesigner's programming editor - how long does it take? Does it produce warnings or errors?

Studied the explanations given by Mark and Erika. In Q&A compilation is performed while closing the program editor and if something is wrong, one has to correct it before it can be saved and compiled. In Sesame, even if something is wrong, it will let one save whatever is done by giving explicit message that it could not be compiled fully and let you work with it.

In the translating phase (QA to Sesame), we expect to have some editing and modification done, so this feature in Sesame is useful. But as a trade off, it need to re-compile the form (database) every time we open the form. For heavily programmed and long forms applications, especially when you have to open and close the forms every time you serve the customer is too much wastage of time and not practical.

Why it cannot be something like,  when it detects that something is changed in the programming module since the last use or when error was detected on the last run, it recompiles. If there was no error in compiling in the last run and no programming update, there is no need for recompiling.  This way the trade-off is more tolerable and sensible.  Programming change after stabilization of program may be done once in a blue moon and for that you pay the price every working minute of the day. It sure does not make a lot of sense to me!!!  

Quote:


Detecting that it is changed / unchanged, requires that at some point the program mark it as unchanged. In a client/server environment that is not logically possible between runs of the application unless we track every user that may ever open that form, and list whether they (individually) have seen the change, so that the system can mark that program as "unchanged" for that user.

If you mean that they (the users) keep the application open, but close the form over and over, each client can then track whether they have compiled that form's programming. They would have to compile it on the first open. But if they are willing to keep the application open, why not simply leave the form open? I can probably implement something like this. I'm looking into it. In the meantime, the work around is very simple - leave the form open.

Q&A users were taught over the years that they should leave Q&A down when not in active use. With Q&A this is especially important because it leaves the file in a "open" state while Q&A is "up", meaning that a network/power/systemic failure is likely to corrupt the open file. Sesame, on the other hand, loads files and does not access them in any way unless there is a change in data. The file is kept closed unless there is activity. Unless Sesame is actively writing to the file, which only occurs immediately after a change to a form, you can pull the plug or crash your OS, and the only result in the Sesame .db/.dat file is that it will need to be "unlocked". This is especially important in a cleint/server environment, where customer expectation is that a server will be continuously running - with the applications loaded and ready to access.

As some of the Beta testers know, we used to compile code as it was needed. But there were objections that because some of the code may fail to compile, while other portions would compile and run - that invisible data corruption (wrongness) could occur. So, I moved all the compilation to a central place (opening the form), and refuse to run any code if any portion of it is "bad".

I am on the fence about this issue. On one hand, I see the refusal to run any code because a portion of it will not compile, as hampering development and testing, in which case you may want to get a portion of your code up and running, before completing and debugging another section. But I also don't want to be in a position where some part of the code is failing and the data is left incomplete.

Quote:


Could it be, that incompletely compiled application will run in the preview mode of Sdesigner but would not run in the .db (Sesame runtime) unless it is compiled completely and cleared of all errors?

In other words, save as and merge application commands will fail if application is not fully compiled and debugged.

Quote:


I sure agree with you on this one. I hope someone puts something out soon!

At this point I would settle for Ray the reapers or Bharats notebook. 

Quote:


The field names contain numbers but there is probably a record in your Q&A database that has the data "____" in those fields. The errors are telling you that it is clearing those fields rather than have the junk data in them

Quote:

This sounds like a perfect example of a Q&A database that should be broken into subforms.  It sounds like you have all these pages for line items on the invoice.  Each of these lines should really be a separate record in their own database.  shown as a sub form to the Invoice form.  The other 138 fields are probably associated with the Invoice "header", common to all line items on the invoice.

I would even suggest you might want to do the redesign in Q&A before translating to Sesame. Make copies and work on the copies only.  It will take some effort, but make a new InvItems database, and be sure to use a Unique field for each record, most likely the Invoice number.  Copy the Invoice Number and all the info on line 1, for all the records with info on line 1 to the new database, then copy the Invoice Number and all info on line 2 for all the records with info on line 2, etc.  Do this for all 51 lines.  Now delete all 51 lines from this database and all you should have are the 138 remaining fields which will be the Invoice Header.

Now when translating into Sesame, bring both Q&A databases into the Invoice.db application.  Bring in only the Header information to the InvHeader database and bring in InvItems into the InvItems database.  Then make the InvItems a subform for Invoices form that shows the InvHeader information, linked by the Invoice Number field to show the InvItems records.

Note, the suggestions are a concept only, and the specifics may need to be altered based on the contents if the Q&A  records.  Example, maybe you can't use Invoice number as the common field, maybe you need something different like data and/ or time and/or record and/or Customer's PO, etc.

Erika wrote Quote:

Something that worked for me was to simply export all the info from all the fields in the Q&A DTF at once, into one export file. Then I selectively imported from that file with mutiple imports using [Ignore Column] repeatedly so that I could pluck just the fields I wanted on each pass.

This saved me from manually editing in Notepad.

(Hope I didn't forget something, it's late and I'm pulling this from memory out of a very sleepy brain. )

Quote:


You could, but you would need to do some pretty hefty munging of your header and line items files to get them into a single file of the correct format for the hierarchical import. If you do the relational link, then export the data from Sesame, it will create the hierarchical import file for you. You can then switch to natural links, import the exported file, and you're good to go.