SM - importing records

[stefangs]

Hi,

 

<background you may skip over>

over the last few years, I've converted many of my personal files to the SM (the dirty one, that is), mostly because it's interesting. I don't use servers or any sort of multi user environments. I'm only mentioning this to say that I have had some limited exposure to the SM.

 

I used to have some solutions deployed in back in the FM6 days and to this day I'm getting bugged here and there that I should upgrade my stuff, which I may or may not do. If I do, I'd like to use the SM, because it would be ideal to deploy updates which typically deal with features/work flow, etc. rather than data fields, making an update rather simple for the user. Importing data from 30+ files was by far the most annoying aspect of updating my solution back then, even though there was some script assistance.

</background you may skip over>

 

At some point, though, I assume, there will come a point when the data file needs to be upgraded, too (probably sooner than later) and I wanted to get your opinion on this idea:

 

Have a script that tells each table to spills its guts into a csv file, so the user will end up with a bunch of files which he can import into a newer version or even decide to do something else entirely. After all, all data in these files is the user's data, and perhaps he decides to abandon my solution and use Excel instead or whatever.

 

The next step then would be the only manual action required by the user, which is to move all these files into the folder of the updated version to a very specific location (perhaps a subfolder). User can then open the new version and run another script that injects all these csv files into the proper table.

 

This would be a massive improvement over the old methods, but I'm asking here because there may be some pitfalls Im not foreseeing. Or perhaps there is a better method altogether.

 

What do you think?

 

Thanks,

Stefan

[GisMo]

I don't see any crippling issues with that you're proposing. It might be easier to just save the CSV files to the location of the "new" data file that way the users don't need to move the files. Then you just open the new UI file and the import it automatic via a script. The separation model is excellent for making revisions and also testing with sample data versus the live data.

[stefangs]

I don't see any crippling issues with that you're proposing. It might be easier to just save the CSV files to the location of the "new" data file that way the users don't need to move the files. Then you just open the new UI file and the import it automatic via a script. The separation model is excellent for making revisions and also testing with sample data versus the live data.

Thanks for the vote of confidence. I guess it's a viable method then!

 

The reason I don't put the export files elsewhere is because I can't be sure where the user puts his update. There may be more room for error trying to run a script that doesn't find a destination location.

 

BTW, can FMP be told to create a folder? Otherwise I'd basically ship the solution with an empty folder in place. This may also lead to problems if someone decides to remove that 'redundant empty folder', not knowing that some dormant script may expect it in the future.

 

Thanks,

Stefan

[GisMo]

Stefan,

 

Yea, it's tricky, but you just need to be crystal clear about the upgrade steps with your clients. Too bad there's no installer/upgrader files that filemaker can generate to handle this..Maybe you can build one with this plugin: it let's you create a system folder among other useful things: http://www.360works.com/scriptmaster/

[stefangs]

Stefan,

 

Yea, it's tricky, but you just need to be crystal clear about the upgrade steps with your clients. Too bad there's no installer/upgrader files that filemaker can generate to handle this..Maybe you can build one with this plugin: it let's you create a system folder among other useful things: http://www.360works.com/scriptmaster/

Thanks for this link - that sure looks interesting. I'm going to check it out right now.