Use a script to export the data. The script can consist of a series of Export Records steps to export your data.
Not a bad idea, I may give it a try. Since this was suppose to be one time export, it didn't come to me as solution, but it worth to try.
Of course, if someone has a simpler solution, I am open to hear it, too :-)
What exactly is not working when you convert from 11 to 13?
The process get aborted with no real explanation in the log.
I've got a converter file from Filemaker Inc, which is using shell processes to convert the files, avoiding using FM at all for the conversion process. It works great on clones, but on files with data, it shows problems, as soon as it starts the conversion process.
Also, I've put some thoughts about making an export script, but that is also not very helpful since I have a lot of calculations in my tables, so exporting them is painfully slow. And if I have to go to each table to define what to be exported and what not (for the script), is not benefiting me much, since I may need to do this once, twice max (if I am testing something).
It's probably the manual approach that might work best for me.
With the script, you don't save a lot of time, but usually can save some time because you can set up one Export Records script step in your script, then duplicate the script step and just edit the setting a bit to export the next table's data, though excluding the calculation fields from your import--which will trade a longer time exporting for a longer time setting up your script will "eat up" much of the savings from scripting it like this.
The fact that your conversion aborts is not an encouraging sign as it could indicate that one of your files id corrupted.
I was concerned about the corruption, too. But, then why would the conversion tool work with clones and not with the same files when they have data in them? To me, that might be a data corruption, which makes the process of making clones and importing plain records back more secure and safe method of conversion.
Intrigued by Rick's response I wanted to trigger the error so I can re-produce it and show it to him. By trying that I dropped my FM11 file directly into FM13, not by using the converter with shell commands. The conversion went smooth with no errors. So, now I am questioning a bug in the shell command converter rather than in my files (but I am not excluding the possibility of them being in fault).
Thanks for chiming in.
The converter was nice, since I have a 100+ dbs, and I made a file in FM13 with one record representing one of the dbs, so I looped through all of them and I converted them to FM13 in no time (through a script). That way if I need to do that again, it quite easy, if I have a new set of clones (as I said previously, the files with data are returning an error and are not being converted).
The corruption may deal with how the data is indexed in the file and thus, a clone, that is free of indexes does not cause a problem during conversion. There could be any number of similar reasons where its the interaction between data and structure within the file that "trips" the particular corruption caused crash.
As a test, you might try converting one file at a time to see which file or files has this issue, then try recovering the FM11 copy before converting to FM 13.
Thx, Phil, I will try the test next, and see what the result will be.
I am a bit concerned to use a recovered copy from FM11 for moving into FM13 since, that is one of the things that were never recommended (using recovered file into production), but just as test it may give me more info of what is going wrong and where.
While "best practice" is to not use a recovered copy, it is sometimes your only option. Most of the time a recovered copy that recovers with the "Ok to use" result is perfectly fine to use. It's just that there's still that small chance that the recover may not have perfectly fixed all issues--but in this case, that may be a better option than any of your alternatives.