Progressive Snapshots of Data

[dp]

I'm developing a departmental budget. It's going through several iterations, and I need to keep snapshots of each step of its evolution. If I were using a spreadsheet or a flat-file database, I would simply save progressive copies with different filenames. But I'm using a FileMaker solution with 10 related files. Saving multiple copies of the whole cluster with different filenames is not only tedious, it creates problems with script calls and relationships. I tried including an editable value list that will let me distinguish between versions, but that doesn't work either, since the amount of money associated with each record changes from version to version. An anyone suggest a solution?

Thanks,

dp

[Kurt Knippel]

quote:

---

Originally posted by Doug Pinkerton:

I'm developing a departmental budget. It's going through several iterations, and I need to keep snapshots of each step of its evolution. If I were using a spreadsheet or a flat-file database, I would simply save progressive copies with different filenames. But I'm using a FileMaker solution with 10 related files. Saving multiple copies of the whole cluster with different filenames is not only tedious, it creates problems with script calls and relationships. I tried including an editable value list that will let me distinguish between versions, but that doesn't work either, since the amount of money associated with each record changes from version to version. An anyone suggest a solution?

---

What do you need these versions for?

I see two viable solutions. First you could simply archive each version into a Stuffit or Zip file, or you could burn them to a CD. The other solution would involve creating a series of duplication scripts, starting at your main file and working though all the others that makes a complete set of duplicate records that you can then edit.

Without knowing what you need to do with these versions, I cannot say which method is better.

[Moon]

Here is what I do (I am a Macintosh user, so my terms refer to its operating system). I quit FileMaker, duplicate the folder of the suite of files I am working on, and give the folder itself an identifying version number. Yes, it piles up lots of files on the hard disk, but that is why I have a big drive. By keeping sets together I avoid the renaming mess. Not elegant, but it is how I do it. I am interested to see if others have a better way of managing the problem.

I do not use FileMaker developer (yet), but I understand that it allows you to rename files and maintain the relationships without a lot of hassle. I wish we could do the same in FileMaker Pro, because an extra $500 for that one feature is a bunch if you don't need all the other stuff in Developer.

Hope this helps.

[dp]

quote:

---

Originally posted by CaptKurt:

What do you need these versions for?

I see two viable solutions. First you could simply archive each version into a Stuffit or Zip file, or you could burn them to a CD. The other solution would involve creating a series of duplication scripts, starting at your main file and working though all the others that makes a complete set of duplicate records that you can then edit.

Without knowing what you need to do with these versions, I cannot say which method is better.

---

[dp]

quote:

---

Originally posted by CaptKurt:

What do you need these versions for?

I see two viable solutions. First you could simply archive each version into a Stuffit or Zip file, or you could burn them to a CD. The other solution would involve creating a series of duplication scripts, starting at your main file and working though all the others that makes a complete set of duplicate records that you can then edit.

Without knowing what you need to do with these versions, I cannot say which method is better.

---

When I submit my original budget to the business office, it becomes part of the official record, and I am not at liberty to change it. When the boss comes back and tells me to shave a certain percentage from my budget, I need to change it and submit a revised version, but cannot make any changes to the original. It must be kept untouched, for reference purposes.

The scripts would be a workable option after this solution is finished. But it's still evolving, and that will have an impact upon the necessary scripts. I know, I'm supposed to have it all planned out before I build it. Oops.

Thanks,

dp

[esteshk]

I don't know why you want these "snapshots", but here's an idea I use for large multi-file solutions. Often for archiving purposes, I don't need to maintain a relational database system with all the power this provides, just a way to review data sets as needed in an iterface my end users are familiar and comfortable with. What I do is "flatten" may relational solutions. In other words, I combine the data from all the files in a solution down to one file. This is done through some rather complicated scripting and makes managing the "snapshots" alot easier. Yes, they become large files, but I compress then and save them in logical groups in a folder struture. I even make these "snapshots" available to the network via FMP Server. Imagine how quickly I would run out of available capacity if I mounted several multi-file solutions on FMP Server. This may not satify your requirements, but I have found it a reasonable solution for saving and making multiple data sets available on the network.

[dp]

quote:

---

Originally posted by Moon Mullins:

Here is what I do (I am a Macintosh user, so my terms refer to its operating system). I quit FileMaker, duplicate the folder of the suite of files I am working on, and give the folder itself an identifying version number. Yes, it piles up lots of files on the hard disk, but that is why I have a big drive. By keeping sets together I avoid the renaming mess. Not elegant, but it is how I do it. I am interested to see if others have a better way of managing the problem.

I do not use FileMaker developer (yet), but I understand that it allows you to rename files and maintain the relationships without a lot of hassle. I wish we could do the same in FileMaker Pro, because an extra $500 for that one feature is a bunch if you don't need all the other stuff in Developer.

Hope this helps.

---

Drive space isn't a big problem, so your idea would work. It's certainly better than the mess that I've created. One complication that I neglected to mention is that this solution resides on a FileMaker Server 5 box, and is shared by 4 people. If one person wishes to have the original open at the same time another wishes to work on version 2, there would be a problem.

I'm not renowned for my elegance, so I have no problem with your inelegant solution in the short-term. I suspect that, once the evolution of the tool stabilizes, I will develop the scripts suggested in the other post. But, if you think of an easier way to streamline the process, I'd like to hear about it.

Thanks,

dp

[dp]

quote:

---

Originally posted by esteshk:

I don't know why you want these "snapshots", but here's an idea I use for large multi-file solutions. Often for archiving purposes, I don't need to maintain a relational database system with all the power this provides, just a way to review data sets as needed in an iterface my end users are familiar and comfortable with. What I do is "flatten" may relational solutions. In other words, I combine the data from all the files in a solution down to one file. This is done through some rather complicated scripting and makes managing the "snapshots" alot easier. Yes, they become large files, but I compress then and save them in logical groups in a folder struture. I even make these "snapshots" available to the network via FMP Server. Imagine how quickly I would run out of available capacity if I mounted several multi-file solutions on FMP Server. This may not satify your requirements, but I have found it a reasonable solution for saving and making multiple data sets available on the network.

---

I had considered simply exporting to a spreadsheet, which is somewhat analogous to your suggestion. But, because of the way we work with these archives, ultimately I decided that I needed complete functionality for every version.

Thanks,

dp

[ccosner]

We have a similar need to produce snapshots of budgeting data in a relational system. Our current system "flattens" the data, as a previous post describes it and deposits it in an archive file, which is perfectly adequate to our needs.

Just some food for thought (not a tested solution):

What if, instead of moving the snapshot out of the system, you simply duplicated the active record (and each related record), tagged its key as a snapshot (and the keys of each related duplicate). The more keys and related databases the more complex this gets, but it seems do-able in theory.

If your keys are text fields, the duplicates could just be "existing key-S-year-month-day-hour" (1234-S-2002-02-21-16:00), which would keep them from relating to active data and make them unique, so they would relate to each other. That way they retain the functionality of active records, but they are effectively outside the active system. Of course, if you need snapshots more frequently than every hour, this example wouldn't produce unique keys.

To alert users that they were looking at a snapshot, you could add a calc field that recognizes snapshot elements in the key field, like "-S-" in this example, and produces a visual cue.

There are a lot of problems that could ensue, however, if the alert did not show up in every layout. Strict validation in every field to make sure the snapshot element (-S- in my example) is NOT in the key could effectively make those records unchangeable.

[BruceJ]

Ok.. this may be the easiest way yet...

Create a report or layout that provides all the info you want, with the look you want.

Create a script that goes into preview mode on the layout you created above, selects all, copies all, and then goes to another file and pastes the image into a container field.

Try it out, works real nice.

Just make sure the container field is as big as the page you are creating a snapshot of in the orignal layout.

You'll have images of the reports in their own file! Pretty cool stuff.