5 Replies Latest reply on Jul 29, 2015 9:13 AM by philmodjunk

Move records from version 1 to version 2 after an update

stuartreid Jul 28, 2015 4:46 PM

Title

Post

I shipped version 1 of our filemaker database last January. It is a school solution and now has 250 students, 30 teachers etc etc.

Soon I will have new version ready for the start of the school year in Aug/Sep. Have made a gazillion improvements and added a lot of stuff but was conscious not to delete fields.

As every developer produces updated versions, I expected this process to be simple and easily done by my client at the school. But, I can't find anything.

I have written a script to go to a layout and export all the data from the layout's table. So far I've written script for 1 layout as a test but have 150 tables to deal with. So it can be done but it seems pedantic in this day and age.

So that gets the data out of the old version into 150 files on the desktop - ouch !

Now to get them into the new version.

What I can find in my searching is a description of the old sneaker net -- manually importing 150 files and matching them to the appropriate fields.

This really breaks down when you consider the non-technical nature of our client and worse if we have to do this for every client.

I am positive that other developers have solved this so ... anyone have some suggestions before I dive in.

Seems late in the game to discover this issue but, honestly, I assumed it was built in. We've written sports solutions (non-Filemaker_ where the data files where external to the app and so a new version just linked to the older data and that was it.

1. Re: Move records from version 1 to version 2 after an update

philmodjunk Jul 28, 2015 5:05 PM (in response to stuartreid)

There is no need to use Export Records at all for this.

A script in the new version of your solution can use a series of Import Records script steps to import the data directly from the original FileMaker File into the new. The user need only click a button to start up the process.

But be sure that your script also updates next serial value settings as well as import records and your original file should have a found set of all records on every layout in the file before you start importing.

You may also want to consider a Convert to Seperation Model as an option to use in the future.
Like Show 0 Likes(0)

Actions
2. Re: Move records from version 1 to version 2 after an update

GordonCox Jul 28, 2015 5:06 PM (in response to stuartreid)

Stuart,

I use RefreshFM from Goya (http://www.goya.com.au/refreshfm)

Regards,

Gordon Cox
Like Show 0 Likes(0)

Actions
3. Re: Move records from version 1 to version 2 after an update

stuartreid Jul 29, 2015 8:54 AM (in response to stuartreid)

Hi Phil, thanks - read a bit about the data separation model and it sounds like a solution that could work.

1 question came up - with the UI in 1 file and the data in another it is easy to swap the UI -- however, what happens when you add data fields to your working version or a new table? how does that get to the client's data file?

I'm sure the answer will pop out of my research ....
Like Show 0 Likes(0)

Actions
4. Re: Move records from version 1 to version 2 after an update

stuartreid Jul 29, 2015 8:56 AM (in response to stuartreid)

Gordon -- Refresh looks nice but the price is a bit heavy for schools --
Like Show 0 Likes(0)

Actions
5. Re: Move records from version 1 to version 2 after an update

philmodjunk Jul 29, 2015 9:13 AM (in response to stuartreid)

If you make changes to the data file, you have to import records from the old to the new. Data Separation can reduce the cases where a data import is needed. It does not eliminate the need for imports.

This can be scripted such that the user simply clicks a button--provided old and new file copies are sitting in the same folder or otherwise in a predictable location.

Another scripted option uses insert file and a container field as a way to present the user with an Open File dialog where they select the original file and then the system takes it from there to import the data from each of the tables in the original file. This is more flexible as you don't rely on the user placing the new file in a specific location before running the import script.
Like Show 0 Likes(0)

Actions

Go to original post