Hello all

At my workplace we are using FileMaker 6. It has been used for over 10
years now and somewhere down the path they did nothing to update the
version. I wanted to ask if the latest version of filemaker is
compatible with the files from version 6. Would I be able to import
the database as it is in FileMaker Pro 10?

Thanks and Regards
Vikram

On 2009-06-28 20:14:35 -0700, ShiVik <vikramvmalhotra1983 (AT) gmail (DOT) com> said:

The success of the conversion will depend very greatly on the
complexity of the FM6 solution.

If it's a flat file or a relatively simple solution, it will probably
convert quite well. If there are many relationships in each file, it
will need a great deal of work both before and after conversion to
properly resolve those relationship pointers. There are tools to help
with this, but the white paper on conversion available on the FM
website runs to 400 pages. This should tell you that there are a LOT of
issues to deal with when there is a lot of complexity. Field
definitions, scripts, and layouts can all break.

Going forward, the utility of the files has probably been compromised
over the years. Where we find neglect to upgrade, we usually find
sloppy backups, bad practices after server crashes, and other behavior
that leads to corrupted files. This is very common when there is no one
truly responsible on keeping the solution up to date.

You may want to consider a true rebuild into the new format. This means
you could keep using the present files until the changeover to the new
solution, it's an opportunity to re-examine business processes embodied
in the software, and you could begin to incorporate and take advantage
of all the new features since FM6. The difference is amazing between
the versions. I don't believe I would recommend to any client that
they convert 10 year old files and then try to build FM10 features into
it.

This all requires a budget of money and time, of course, and your
business may not be able to support this.

You might consider contacting a professional FM developer near you for
a one-day consult to fully inform you of all the issues involved.

On the other hand, if you feel adventurous, take a COPY of the files
and convert them just for yucks on a stand-alone machine (you can use a
free demo copy of FM10 to do this) and see how broken they are. Just
drop them onto the FM10 icon, or open the file and use File/Open. Do
not do this on the original files, use a COPY. Please.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA

Thanks for your prompt advice. I will look into how well the files are
imported from older versions on a standalone PC. But in any case, a re-
build is surely on the cards.

Thank you
Vikram

On Jun 29, 12:38*pm, Lynn Allen <l... (AT) NOT-semiotics (DOT) com> wrote:

I used FMPro Migrator from .Com Solutions to migrate our 20 FM6 files
to a single file FM10 solution. I am now in the process of rebuilding
everything, as all scripts in the old solution are either useless or
broken. Despite the large number of files, it is a very simple
solution in terms of relationships and business processes.

FMPro Migrator saved me many many hours of manual consolidation of the
files. So if you have more than just a few files, then that is the
way to go.

Keep in mind that even with FMPro Migrator, the process is complex and
detail oriented. Hiring a pro developer may still be the best way to
go.

Darren

On Jun 28, 11:14*pm, ShiVik <vikramvmalhotra1... (AT) gmail (DOT) com> wrote:

In article > On Jun 28, 11:14*pm, ShiVik
<vikramvmalhotra1... (AT) gmail (DOT) com> wrote:
We're currently using FM9, with what is basically an FM6 database. The
data moved just fine, but we had do do a little work on some of the
printing scripts IIRC. I think that there were some differences with
formatting for some reason.
When you convert, a new copy is made - you can still use your FM6 files
as if nothing had happened, so you are not committed until you are
ready to do so. I believe that was what we did - convert, see problems
- continue using 6 while we resolved problems - deleted all records
from FM9 database - exported data from 6 and imported into 9 when we
were ready.

--
Jim

In article
<1924ae3e-71c5-429d-aa01-7011899a84e8 (AT) n11g2000yqb (DOT) googlegroups.com>,
ShiVik <vikramvmalhotra1983 (AT) gmail (DOT) com> wrote:

I have converted several multi-file relational databases in .fp5 (FMP5 ,
6) to multi-table relational databases in .fp7 (FMP 7, 8, 9, 10). In all
cases I ended up with converted databases that worked just like their
..fp5 originals.

In order to take advantage of the new features of FMP 7/8/9, I had to
rebuild extensively but that was worth it. The fact that I had a
functioning version immediately after conversion was of great value
until I could get the rebuild done.

In order to convert a multi-file .fp5 database, select all the related
..fp5 files at once and drag them all at once onto the FMP 7/8/9/10 icon.
FMP 7/8/9/10 will do the conversion all at once, preserving all the
relationships, scripts and layouts, so the converted file works just
like the original .fp5 database.

Maybe some people had to do some tweaking to get the converted solution
to work like the original .fp5 database, but I did not have to.

As others have said, there are white papers about database conversion
and database migration on the FileMaker web site. Those are well worth
reading.

ShiVik wrote:

My first suggestion would be to make a copy of your FM6 database files,
open them in 10 and see what happens.

My best suggestion would be to purchase a copy of MetaData Magic
<http://www.newmillennium.com/index.php?submenu=MetadataMagic_Overview>
and run a conversion report. It will provide you a list of most
potential problems and will help you go through one by one to resolve
those potential issues. It will also help consolidate the file
references that were stored internally (i.e. hidden) in FM6.

I would say the three most widespread and most important conversion
issues you'll run into are:

1) Bad file references: references to old files that no longer exist,
which can create long delays while opening the solution or while some
scripts run which require other external FM files to open. You will
also likely have duplicate definitions that make continued maintenance
more difficult. Consolidating either before conversion (using MdM
above) or after conversion will be a smart move.

2) Need for more Commit Record script steps: FM10 allows you to switch
windows without first committing the active record in the first window.
The result is that you may start getting error messages (or scripts
will fail blindly if you have error capture set 'on') when you switch
windows without first committing the record in the first window. You
also get to think in 10 about whether or not you want to commit the
record with or without validation.

3) Print step conversion: In 6 you were able to set the print
orientation in the Print Setup step and the scope of records to be
printed from within the Print step, and those settings always held
between scripts and files. It's not always as clear in 10. More
importantly, print orientation does not convert properly in Windows; it
always defaults to Portrait so that you'll have to go back to your
previously landscaped scripts and reset them manually. And I have found
-- at least in Windows -- that the conversion process will lose any
non-default layout margins you've set in layout setup.

There are many other smaller things you may come across: graphics in
Windows lose their transparency and/or gradients and/or original sizing;
certain field calculations may not update themselves as they did
previously; field validations occur in a different order then before and
you may thereby run into issues where a field's validation runs in an
endless loop; etc.

Hope that helps...
Howard