bradleyboggs

Import Verification/Clone Files/Best Practices for Files

Discussion created by bradleyboggs on Jul 26, 2016
Latest reply on Jul 28, 2016 by cortical

Thanks for looking and for any guidance you might provide!

 

I'm trying to transition to the correct way of doing things with a Development copy of the file I'm working on. Finally looking into importing/updating data, I've figured out most of what I need to know to import data from the current production file into the new file. My main question: Is there a way to do a sort of checksum/verification to make sure that after import, the date in the new file (the file that was used for development) matches the data in the previous production file? I've searched the forums and Google to no avail.

 

I'm getting ready to write an import script to automate the import of our 35 tables (plus 3 other connected files), and I just wanted to see if there's a way to make sure everything imported correctly.

 

Secondarily: I don't have a clean "Clone" (just barely learned about them today). I know I can't make one from nothing since all copies I have of the file have been in production at one point, but what's the closest I could come? Take a known file with no apparent issues, run a recover to check for issues, then export the clone (which eliminates all the data). How would you handle this?

 

 

Blathering Background info/request for best practices:

 

Let me preface this by saying I know that my practices as mentioned below are not "Best practices" (and actually probably pretty heinous in most of your eyes). I'm here because I'm trying to learn how to remedy my errant ways and do things the right way.

 

I'm an in-house developer at a manufacturing company. Between office employees and ipads in the factory, we have about 30 users. We've been running FM12 since I started the system from scratch in late 2013.

 

Here's the cringe-worthy part: 99.9% of the time I've spent building the system, I've been working on the production database. Stupid and incredibly reckless? Yep, that's me! This isn't a story of a crashed database though. However, just yesterday I had what looks to be a corrupted index that effected only one record, seemingly related to an FMGo user. It looks as though that solution is now fixed (after trying a delete/reimport to no avail, I stopped the server, copied the database, and rebuilt the index using the recover tool (only rebuilt the index - disabled all the other stuff in recover). Seems to have solved the problem.

 

Best Practices: I've found Filemaker's official "Best Practices" regarding not working on production files, the need for keep empty clone copies, etc. and I'm working to be compliant with that. Any other recommendations/guidance?

 

One note: I'm getting ready to upgrade us from 12 to 14. I have a VM copy of our FM server and will be doing a trial run there first before moving forward with the production machine. Any tips/guidance here are also welcome.

 

In general, i just want to start doing things the right way and protect the business from some catastrophic failure because of my own stupidity. I've been lucky thus far - but luck will run out eventually.

 

If you made it this far, thanks!

Outcomes