I have a scripted backup for data and development updates. For the data backup the script uses a check layout for each table, and exports idividual files. The challenge is that during development, if there are new fields added, these do not show up in the export without a manual "clear all" / "move all" step. I noticed that in the dialog, there are both Layout and Table selections. By default it reverts to the Layout selection.

1 - Is there a way to force the Table selection at export via scripting?

2 - Is there a way to force the "clear all" and "move all" via scripting?

thanks

I guess the real question comes down to, is there a way to ensure that every field of a table is automatically exported every time?

any takers?

thanks

I suppose there is, but why are you doing it this way? Why not just backup the file?

You ask a good question. This is the first db I have been involved with, so please pardon my ignorance when it shows. I do want to hear your suggestions, and to learn how to do it better and smarter.

It is part of the process for development updates to the server version of the db. It is not a clean gui/data separation model, but kind of a hybrid for development purposes. I am developing at my desktop, and upload that to the server when appropriate. The exports are what I use to pull the current data into the current gui before uploading to the server. I read through quite a bit on the forum including your Deployment scripts to try to get a handle on how to do it. Whereas it seemed your scripts were driven at a field level, mine are based at a table level. That is why it is important that the user export all the fields in each table. Then the import step uses matching names. If the export would always grab every field at a table level I could eliminate the dialogs and it would run with less possibility of user error. Thus the question.

You do not need exports. FM files import from each other. So, when you are ready to host the "new" version, you will need to unhost the old version, take it down, and run an import routine from old version to new version. Then upload the new version.

This can be scripted, but I always leave the import dialog showing so that I can see the field mapping dialog--just in case.

Thanks,

I will have to look into our process. That is where the download in the steps came from. Back to the original question, it doesn't seem that there is a way to force an export to a table and to all fields on that table then. Correct?

thanks all,

I guess so then. thanks

Not so, then. I haven't the time right now to confirm a guaranteed export of all fields. Although, my instincts hope that it's there. The sure way to get all the data is just use a backup.

Thanks, I will look into that more as well.

I appreciate the help.

If you ever do find a way to do the table import, I'd still be interested.

Have a great weekend.

Just as a follow up on this post. We have dug deeper and not been able to find scriptable controls to accomplish what this post requested. Export by table as opposed to by layout, and select all fields. At this point, I don't think it is possible. We have just told our developers this is a check step in the process. If it ever comes available or is there, but we just haven't found it that will be a good thing.