Greg G Posted February 26, 2007 Posted February 26, 2007 What is the best way to issue an update for a runtime so there are no data problems? Greg
omegagoh Posted February 27, 2007 Posted February 27, 2007 (edited) Dear Greg, I think in order to have least impact on the data, you may consider separating the data from the rest of the FM elements (the main exception is security setting). What I mean is store data in files that contain basically only tables, fields and a blank layout with a button (and a script, of course) to return to the Viewer file. The Viewer file has references to the data files (thus the tables and fields). Then, add the other elements such as Table Occurences, Relations, Value Lists, Custom Functions, Scripts, Variables, Layouts etc to this Viewer file. This is my understanding of Data Separation. The key for Data Separation is File Reference. In this way, you usually only need to update the Viewer file. Thus, no impact on the data files. Taking one step further, you may consider storing the calcultion fields' expressions in either a global table, global field, global variable or value list. Then using a mix of Let and Evaluate Functions to evalute the expressions. In this way, you may change the expression without affacting the raw data and without going to Define Database. For example, a Contacts Table having three fields First Name, Last Name and Full Name. Both First Name and Last Name are user-entered raw data. Define Full Name as Evaluate(myGlobalTable::FullNameEx). With this, you can edit the FullNameEx (the content is the expression!) at anytime without affacting the raw data. This is my understanding of Logic Separation. The key invloves a mix of Evaluate and Let functions. Please forgive me if my understanding of Data Separation and Logic Separation differ from the others. Best regards, Omega Goh The FileMaker Specialist Speedy Scaleable Solutions Edited February 27, 2007 by Guest
Greg G Posted March 2, 2007 Author Posted March 2, 2007 I am already using the data separation model but I know that at some point I will have to update the entire solution. Is there a way to make this work without too much impact on the user? My biggest concern is being able to get all of their data out and into the new updated DB knowing that there are a number of container fields through out the DB.
Inky Phil Posted March 2, 2007 Posted March 2, 2007 Hi Greg I have a simple procedure that seems to work. When I issue the runtime I create a folder called 'temp' and make sure that this is placed into the runtime folder. On my admin screen I have 2 buttons - export and import. These both do what it says on the tin. The export button runs a script which places a copy of each data file into the folder called 'temp' using the 'save a copy as' script step. The import button runs a series of scripts that goes from table to table, empties them and then imports one table at a time into into my data files using the files that are in the 'temp' folder as the source. The last thing that the script does is go to the last record in each table and reset the next serial value to that records serial value + 1. So the user opens the old runtime, clicks the export button, shuts the old runtime, renames the folder 'old runtime', copies the 'temp' folder from the 'old runtime' folder into the new one, opens the new runtime and clicks the import button. Job done! Works for me HTH Phil
Genx Posted March 2, 2007 Posted March 2, 2007 (edited) I like the idea of setting the serial number to the last record + 1, that one always proved to much effort for me otherwise, you'd have to make sure to sort by the serial field first though... or unsort the records, whichever works better. Edited March 2, 2007 by Guest
Greg G Posted March 2, 2007 Author Posted March 2, 2007 Thanks Phil. That helps a lot. I suspected that a procedure such as that would be necessary but having never done this before I want to make sure I don't create a problem later. Do you think there will be any issues with the contents of container fields, both referenced and inserted into the DBs? Greg
Inky Phil Posted March 5, 2007 Posted March 5, 2007 I wouldn't think so Greg. So long as the fields are matched up properly on the initial import then you should get an exact copy of the original file. My system definitely brings in inserted objects in containers and although I do not think I have ever done a reference, I do not see why it shouldn't work, A simple test would soon give you the answer. Best of luck with it Phil
Greg G Posted March 14, 2007 Author Posted March 14, 2007 I thought of another related question. With this export/import process what will happen with Value List data that the user has added? Greg
Inky Phil Posted March 15, 2007 Posted March 15, 2007 The value lists will come just fine but I have just yesterday discovered a problem with my procedure. For some reason a runtime created in 8 or above appears to have lost the ability to 'see' into subfolders. This is rather annoying as it used to work before in 7. After a frustrating day trying to work out why this is happening the only solution that I have come up with so far is to have the source files directly in the same folder as the runtime and not within a subfolder GRRRRR! Phil
Recommended Posts
This topic is 6461 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now