I miss this whenever I save a clone and need to import the data from a populated db: I would like an "Import All Data" option so I don't need to go table by table selecting the "import matching fields" option ... that is, an "Import all matching fields from all matching tables" so I can have a clone populated with just one click ... does it make sense?

It's a wish that is solved with just one script, though you'll need to keep it up-to-date as your data structure changes.

You are right ... I usally have one script with multiple "import" script steps, but I was triying to save the time to add the new tables import steps since I usually need this in the development stage, so the structure is constantly growing ... I guess I'm just getting lazy :

Or...don't save as a clone, just delete the records in the tables that you want to clear with a script.

OK. Everyone but me saves as a clone. What am I missing? Is this a file maintenance technique?

I like to make frequent back ups when I develop. I've just started using zippScript 2.2 to schedule a back up every 30 minutes (instead of having to remember to do it) and I do one on close and manually whenever I've done something tricky. I also like to have data in the tables when I develop. So Save As Clone keeps my backup folder for a particular solution in development to a manageable size.

That is an interesting technique. My personal preference is to develop on a home server. This helps prevent all sorts of problems that can occur during development. I don't quite backup every 30 minutes though : I have a schedule a backup on the server for every three hours and have a different folder for each. It's a little bit of hassle but I think it's worth it.

Thank you for the tips. Here is the thing: let's say that you create "Solution Version 1" and you sell it to a number of companies. After some time you create "Solution Version 2", which is the same as V1 plus some more tables, layouts, etc.

After you are done developing V2, you save a clone, "take" the clients' V1, and, by using an "Import data" script, populate V2, and give it back to the client.

So far so good but ... when you create V3, and take client's V2, you'll need to modify the "import data" script in order to take into account the new tables created in V3, that's why I thought the "Import all data from all matching tables and fields" would be useful ... (with an extra checkbox for "set next serial #s as per source tables".)

In any case, I guess there is a better way of doing this ... I thought of starting using the separation model, but if you create new fields and tables still need to substitute the "data" file with the new one and import the data ...