How stupid can they be???

[SteveB]

I had posted a thread about upgrading runtimes last week. It received no comments until this morning because, I suspect most developers don't make runtimes. I purchased FM7 last week and began thinking about upgrading a 20+ file runtime.

Guess what? Those idiots require that you upgrade the previous runtime to FM7 before you can import the data. For those of you who don't understand the implications, runtimes are equivalent to EXEs. You can't go back to runtimes and add anything. My imports have always been from one FP5 file to another FP5 file, which when converted to a runtime is now unmodifiable. So, net, I have no clear way of getting data out of my clients' existing versions.

To answer my own question: They are very stupid!

Steve

[The Shadow]

Have you tried using the new "Convert File" script step inside your FM7 runtime to upgrade the previous one?

[SteveB]

No, the runtimes are already out in the field. I will probably have to do a two-phase upgrade: Upgrade from the current runtime to one that can dump the data to an intermediate file format.

Steve

[The Shadow]

Right, but if you could make the intermediate format a converted FM7 runtime, you wouldn't need to worry about formatted text and other such issues.

I'm thinking the runtime you ship would contain an import script whose first step was "Convert File", then import from the upgraded data to your new runtime.

[SteveB]

I just tried your suggestion. It requires user interaction, which is the last thing my users can cope with. You can't make it run silently. I can't do it personally since the users are scattered all over the US. I think I'm left with exporting the data from each of about 12 (of 22) files as separate .MER files. The CSV format doesn't put out a header record, so I don't think it would work very well. Maybe .DBF?

Steve

[SteveB]

It can't be a DBF, since field names get truncated and mashed. MER. is probably the best, since I can work with matching field names. Just have to delete the header record after import.

Steve

[rogermax]

Steve, Are they v6 runtimes? if so you could export xml. if not then I think merge is the best. I am working on the same thing. I plan to build in some xml scripting before I have anybody upgrade to v7 runtime.

[SteveB]

Hi Roger:

Little hot on my side of the valley.

The runtimes were made with 5.5. Is there any advantage to using xml over a MER. file?

What I plan to do is use a 5.5 file with one script that exports the data from each of the files. I'll execute this file from within my installer. When the new version starts up, it will do an import.

Steve

[rogermax]

Yeah, hot here too, plus the a/c on the fritz. Your solution sounds like it will work peachy. Sounds like you planned ahead with a script for export built in.

[Oldfogey]

Please stop grizzling about the heat. I'm freezing to death.

Steve, one of the things I'm playing with is getting my customers to email the main files to me so I can do the conversion and send back the whole lot. My main distributed runtimes are for a franchiser who is only just getting off the ground - only two remote sites so far. Trouble is the V7 runtimes are around 20Mb.

I was going to tell them to forget V7 until it's fixed but converting the runtimes raises another complication.

I had never heard of .MER but just had a look. It's CSV with header record. Anything else special?

I am really nervous about export and import, mainly because FMP gets paths lost so easily.

BTW FMI aren't stupid. They're very smart because they know that we stupid customers will go through all kinds of gyrations to keep FMP and they just have to sit back and watch (and laugh.) Why spend money on a runtime-runtime tool when we are forced to do it anyway? They just think they are Microsoft.

[JerrySalem]

Steve,

Reality check for the export from FM6 then import to FM7 scheme proposed. (BTW am also in the same boat)

YOU control the export and the import (read import order). The way I plan to do this is to have a script for each file that exports the user data to a temp CVS file. Then in FM7, the import and import order is scripted ahead of time so that the fields already match up. No need to mess with .MER, .DB or XML files.

BTW While I am doing the scripting I find it usefull to create a record whos field CONTENTS is the field names. For example, the Field FName, contains the string "FName" etc. This doesn't work for Num data but at least is a start.

[SteveB]

Jerry:

I'm using 5.5, not 6.0 altho I would think they are esentially the same. The reason I choose .MER is twofold: MER puts out a header record, and it allows 'Match On Field Name', neither of which CSV allows. So I don't have to create a header record. All I do is delete the first (header) record after import.

My problem was that I can't go to v7 until I release this version because my existing version imports from the old to new version using FM file to FM file. Given that it's just data import, one would think the lunkheads would have enabled the capability.

I remember that you've messed a bit with FM Mobile. Have you ever written a data synch subsystem? I'm going to have to write one between 2 runtimes and between a runtime and a Palm.

Steve

[JerrySalem]

I wasn't clear. when you import use 'Last import order' this is scripted so that the end user dosn't see this ever. The 'header record' you created is only for testing. Actual users in the field don't have this field. They export their data to the CVS, then your script remembers your import order from the testing and imports in the right order. No need for a Mer table at all.

One of the many reasons I haven't moved everything to 7 is because of Mobile. I am still waiting for a resonable product!

Jerry

[FMDuck]

This is a real problem for me also. I have over 100 users with a 37 file solution that is about 80Mb empty (many fields!) I haven't addressed this yet, but I typically export to an HTM file since it will export with headers and Excel will read it easily. I then load it into Excel and then save it as an Excel file for reimporting. This helps so long as you have 65535 records or less. This is no help here in the V6 to V7 problem, but if this info helps give anyone any new ideas, please post them.