Why are you adding the new field to Program instead of Data?
OR are you adding a field from Data to a layout in Program? (That requires table occurrences in Program that refer to the tables defined in Data.)
Ultimately I want to create a runtime solution and be able to provide updated versions of the Program without having to have the Data file changed. For now I am testing in a "regular" mode.
So, my thinking was that I could add a field in Program, and have the data in that field be stored in Data.
If I have to add the field in Data, that sort of defeats the purpose I had in mind.
BTW, I have found the Help, Knowledge Base, etc. not very helpful in all of this.
Thanks again for your help.
I'm not sure that I follow your logic. If you want the field to be stored in Data it must be defined in Data like anyother feld in your tables.
If this is a field you want to use to record/track a release number for the program file, then you'd define a table in your program file and define the field in it. This would be an "except to the rule" so that you can store data specific to that edition of the Program file.
OK. Suppose I have provided you with a runtime solution that acts as a check register. Name of person you wrote the check to and the amount.
You write checks like crazy, but observe that you would like a "Memo" field to record what you wrote the check for.
How do I provide you with a new runtime solution without you having to import all of your records from the old version?
The data separation model supports changes to the interface, the layouts, scripts, value lists etc. not changes to the tables themselves. The data separation model reduces the need for imports but cannot totally elminate them. A scripted import process that copies all records from all tables in the old data file and imports them into the new, then updates any serial number fields is still a necessity.
You could add a field to a new table in the interface file and define relationships that link this new table in a one to one relationship with the existing table, but this also defeats the purpose of the data separation model as this converts your interface file into a second data file that also happens to hold your interface elements.
Thanks for the clarification. Can you refer me somewhere that might help me see an example of the "scripted import process?"
Once again, Phil, you have been The Man!!
First you put a script in your original data file and all subsequent releases that goes from layout to layout doing a show all records so that every table occurrence has a found set of all records. This makes sure that all records can be imported from the data file.
The script in your new data file performs this "prepare for import" script as it's first task.
Then your script is just a series of Import Records steps set up to import the records from the old into the new.
To update serial number fields, you can sort your newly imported records and then use go to record [first] or go to record [last] (depends on your sort order) to go to the record with the largest serial number value. You can then use the Set Next Serial Value step to set the value to at least one number larger than this maxium.
If you want to be even more user friendly, you can define a container field and use insert file with the store by reference option to insert a reference to the original file in this container field. This allows you to pop up an open file dialog where your user finds and opens the original file. Your script then extracts the file path to the original file from the container and stores it in a variable so that your Import Records steps can all refer to this variable for the file path to the original file.
After the import is complete, either the user or a utility script can copy and rename files to replace the old data file with the new.
Thank you again.