Export / Import help please

[Totes]

I have been working on a little runtime for our K9 unit mainly to keep up with feeding, photos, grooming etc. nothing too complicated). Another agency wants to use it as well so I want to give them a copy.

I know at some point we will have changes to the db and I will want to give the other guys the updated version as well.

So for the last two days I have been trying to follow some of the postings and try to figure out how to get the old stuff out of the old runtime and bring it back in to a new empty runtime.

I have managed to create a folder (these are Windows machines) and then export one table to the file. the problem is I can figure out how to get all the tables to dump to the folder.

I think I need some type of loop but all I can do is get stuck in a loop that never ends.

Can someone look at this and tell me if I am even close:

###This creates a folder on my c drive called "bcsok9old"

Send Event ["aevt";"odoc";"cmd/c:bcsok9old"]

###then I export records from the feeding table to the folder

filewin:/c:/bcsoK9old/feeding/feeding.fp7

The file is created but that is as far as I can get. I cant figure out how to the the other tables data (grooming, photos and vetvisit)to export with the first one.

Thanks for any assistance.

Edited July 4, 2009 by Guest

[IdealData]

Why go through the process of exporting to disk, when you could just as easily perform a straight import from the existing install to the new release using import from an FP7?

Your current approach requires that the existing install has the scripting built in to do the exports and the new release also has the import scripts - so that's 2 sets of scripts to maintain, whereas a single script set to do the import is all you would need to maintain.

If you make sure that the new release is always the 'master' then the scripting you require will always exist to perform the imports from the existing install.

FWIW I am mid-development of a system that is being updated in phases, so I am developing the import scripts as I progress to import the existing data and then put the latest release back up on the server.

[Totes]

Thanks for the reply.

If I take this route would they not have to import each table and know how to import?

I thought from reading all the posting that doing a script dump and import took the user out of the loop to an extent.

Thanks,

Jim

[bcooney]

Jim, have you seen my posts regarding updating a runtime? As Mark points out, you do not need to export files, just have the master import from the old file.

The hurdles as I encountered them were:

1. I need to know the path to the old file. If you have a consistent install, then you should know the path. However, I use the insert file as reference to capture the old file's path.

2. You'll need a script for each table. The script would go to a layout based on a TO for that table, (delete all records), import from the old file (saved import order), sort and use the SetNextSerial script step to, um, set the next serial ID so that your ID counters will not create records with duplicate IDs.

3. Then I chain the import scripts all together in one big script.

So, start by writing an import script for each table.

[Totes]

bcooney,

Hi, yes I did see your post (I never did see an example) that is what I was attempting to base my export script on was how you outlined it in your posting (that is what I wrote to you about the other day in the Runtime area).

From your post I gleaned that I needed to create a known folder, export to that folder and then import to the new empty runtime form that known folder.

I attempted to create a script that dumped the tables into the know folder and then the new runtime would find that folder and import, but of course it did not work.

If I do it the way described: just doing an import directly from the old runtime to the new runtime, I keep getting prompted with the import filed mapping with the source and destination.

Trust me when I say that the guys using the runtime can barely enter data. If I have them try to figure out a source table and a destination table the runtime will be populated with wrong data in the wrong place.

Or did I miss something completely?

Thanks for your time.

Jim

[bcooney]

Hello again. First of all, non of this really has anything to do with a runtime. So, you can sorta ignore that aspect.

I cannot post the file, as it is a commercial solution. But, I don't export, then import. Also, the prompts that you are receiving seem to indicate that you didn't check the [x]Perform without dialog on the Import Records script step.

I create a wizard-like interface to having the user locate the source file (the old runtime). But I distibute using an installer, so unless they've moved their files, I know where the source should be. Give me a couple of days, and I'll post a simple demo with the key steps.

[Totes]

I really do appreciate your time to this matter. And I know the K9 folks will also.

Jim

[bcooney]

OK, Jim, here's a demo of my upgrade process. You'll want to open MyFilev2_00, pretending that this is the new version that shipped.

UpgradeDemo.zip

[Totes]

bcooney,

Just downloaded the file. Now that I can see it in operation,I have a better understanding of how it works.

I will look at the scripts tonight when I get home and from what I see I should be able to bang out a solution.

This has helped me more than you will ever know, as I have a bad calculation in the K9 runtimes that I need to fix.

Hopefully one day I can return the favor.

Thanks agian,

Jim

bartow.org

[bcooney]

Just "paying it forward," Jim. Let me know if you have more questions.

PS: Pet a shepherd for me. I grew up with one, named Princess, of course!

[swissguy]

Hi

I followed this thread since I also have a solution to update my runtime. It is as such:

After installing a new version the user has to "import old data" from the old db (which is moved into a known location before install). An convenient update layout is provided to do this.

I do these steps in the import script:

- relogin current db with an general export account (with reduced privileges to import and export)

- open old db (is opened with this account, according to FM rules) in the known location

- call an export script in the old db to export all tables in a loop to a known location , do a show all first for every table

- count the records in the old db and return a string with all the numbers, together with the versionnumber of the old db

- save the return string

- close old db

- import all tables into the current (new) db in a loop

- calculate number of imported records for each table, compare with values in string

- report error if not same

- setNextSerial where needed

- compare version of old and new db and call apropriate migration script to update any table that has changed (have array for the last 10 updates)

- ask user to relogin with his account

- done

Works well.

That takes into account that some users might have skipped previous updates and makes sure that all changed tables will be migrated (new fields set, etc). Also makes sure that all records are here again.

Since I have an export script (for all tables) anyway I use this to do the export. The user is provided with export/import functions to a known location as a additional feature (besides db-backup) - if anything can go wrong it will...

Now, some people skip the export step and do just import - I checked your updatedemo that you provided earlier. But I do not see the show all that has to be done in the old db prior to import - as I understand FM, the found set that was used prior to closing the db is used per default. And we do not know what the user did last, right? So how is this accomplished without calling a script in the old db?

Thanks for all your thoughtfull posts.

Regards from Switzerland, Peter

Edited October 17, 2009 by Guest

[bcooney]

Hello again Peter,

That sounds like a solid routine. I don't do exports, because if you import from a closed file, all records are imported. If you import from an open file, the found set is imported. That's the key.

[swissguy]

Hi Barbara

Well that is good to know, I must have been misinformed. I might try to skip the export step but have to think about it cause I like my migration step and for that I need the version number - but come to think of it, that is stored in my system table which is imported - so I have it after import. Have to check it before overwriting it with the new value....

Well, it is the same with every programm you write: one always finds ways to improve it, it is never finished.

Peter