I have a 13 files solution working with FM 5.5 Win XP.
Everything is working OK but I'm thinking upgrading to FM 8.0

I want to recreate everything using data separation so upgrading the new
solution would
be easier. I could just ship the new solution to users and the would only
have to copy the new
interface file over the old one and they would not have to import records
from the old version to the new one.
At least, I think that's the way it should work... I'm I right ????

I would like to find some info on data separation and the way to create the
solution.
I'd like to know what to do and what NOT to do...

Could anybody point me in the right direction ??

Thanks

Claude

In article <ZSZVe.98076$eW1.714532 (AT) wagner (DOT) videotron.net>,
"Claude Carlos" <carlos.cl (AT) videotron (DOT) ca> wrote:

You have to convert the old files to .fp7 files (The files in FMP 7 and
FMP 8 are .fp7 files).

FMP 7 & 8 can not use .fp5 files directly, but can convert them to .fp7
files. So the short answer is no, you can not do it the way you propose.
However, the conversion/migration process is not all that difficult,
depending on the complexity of the solution you want to convert.

There is extensive literature on the Filemaker web site and elsewhere
about file conversion and file migration to FileMaker 7 or 8. It is the
same process for Filemaker 7 and 8. Go to the FileMaker web site and
read about it. There have also been extensive discussions on this
Newsgroup, since FileMaker 7 came out.

Bill Collins

--
For email, remove invalid.

Claude Carlos <carlos.cl (AT) videotron (DOT) ca> wrote:

Claude, start by converting all your files to fp7. Now you're ready to
use them as the data files in the solution.

Build the separate interface file, add file references to each data
file, and place all the Table Occurrences from the data files you need
into the relationship graph. Now, rebuild your layouts in the interface
file, pulling the data from the data files. You will be amazed at how a
layout based on a table occurance behaves as if it is IN the native
file.

However, as for your upgrade scenario with your clients, unless you can
make the conversion without making a single change in your fp.5 files,
you will not be able to simply send out a single .fp7 interface file
THIS TIME.

You will almost certainly have to clean up file references and
straighten out and delete lots of structure in the data files before and
after conversion. I recommend you read the conversion white paper on the
Filemaker inc website. There are tools to help, such as New Millennium's
MetaDataMagic with file reference fixer, which you use before
conversion.

You will also have to convert and edit your privilege sets and
account/passwords in the data files to match FM 8/7 new features. This
is not something that your clients can do.

You will be better off rebuilding and converting everything at your
site, and then writing an import routine into your changed data files
that is targeted at newly converted and unchanged files like the ones at
the client sites. This one time, users will have to convert and import.
The NEXT upgrade, however, if you can manage to anticipate any further
needed changes in data files, can be just an interface file change.

I recommend you put lots of extra, unused fields of various types into
each rebuilt data file before you deploy them to your customers. Then if
you need to do changes beyond the interface file, you can map to those
unused field, and for calcs, learn all about scripting and Evaluate().

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

"Bill" <bbcollins (AT) invalid (DOT) earthlink.net> a écrit dans le message de news:
bbcollins-CFAE93.15020714092005 (AT)....earthlink.net...
I know I can't use directly .fp5 with Fm 7 or FM 8,

My question is more about Data separation. Because I think i'll rebuild the
solution from scratch

Is there a book or documents explaining how the files should be created and
what can be done or not.

Also, once the new solution is done, how do I get the data from the old (13
files) into the new "tables ".

I have just been reading a little about separating data from the main
FM8 file in the "Filemaker Pro 8 Advanced Development Guide" that came
with FM8 Advanced. It talks about "auxiliary files" in the runtime
section but doesn't explain how these work. So it can be done but, like
you, I am still looking for some detailed advice.

Michael Paine


Claude Carlos wrote:

"Lynn allen" <lynn (AT) NOT-semiotics (DOT) com> a écrit dans le message de news:
1h2vo9v.12gxk1h1f7pvoiN%lynn (AT) NOT-semiotics (DOT) com...
Thanks Lynn
As usual you give a VERY clear answer to a question.

Now , my work starts....

PS I bought FM pro Dev 7 a few months ago but never had the courage (or
time) to start using it..

Do you think I should upgrade to FM 8 Advanced now ?
Are there significant benefits ???

Thanks again

Claude

If you want to see what you can really do with FM7 or 8, download the
"FileMaker Business Tracker" from
http://www.excelisys.com/

This is a solution that was put together by FileMaker and Excelisys and
it really shows off the capabilities of FM7 as well as how the guys at
FileMaker thought we should be using there application. The file is
completely open source but is shrink wrap quality.

I recomend having a look at this file, even to advanced level users.

Claude Carlos <carlos.cl (AT) videotron (DOT) ca> wrote:

Don't even start with 7. FM8Advanced is so much better you can't even
imagine it. Start with the ability to copy/paste fields, script steps,
whole tables from one file to another, and go to custom menus, buttons
in the tab order, tool tips with dynamic content...I'd say that was
significant.

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

Claude Carlos wrote:

Hi Carlos,

Data Separation Model is the only way to go (imo). The benefits are
substantial.
Having migrated (10+) largish solutions now, from FM6 to FM7 using DSM,
the real tedious bit has been manually re-creating fields and tables.
FM8 nows does that.

You are essentially correct in thinking that revisions/updates can be
posted to the end user, and usually, once the inevitable
'missing/required/we could do with that...' fields are fully resolved,
all new improvements are largely user file only. Updates become simple
drop overwrites.

email me off group if you like, I have a couple of (very) simple step by
step demos



Chris Brown
University of Adelaide

News server access again!

In article <1QOXe.533$uQ6.27374 (AT) news (DOT) optus.net.au>,
cbrown (AT) medicine (DOT) adelaide.edu.au says...
I'm not entirely convinced yet. Sure superficial layout facelifts are
easier, but a great deal of the security options and of course the table
definitions themselves can't be separated out. The field definitions are
quite a bit more than just 'text/number" - its where calculations,
validation, and autoenter/lookups are all defined. Furthermore,
'priviledged' scripts that exceeed the users authority must reside in
the data file, further diluting the 'data separation'.

In my experience its quite unusual to perform a nontrivial system update
that doesn't impact on what would be in the table file.

I'm not saying the 'data separation' paradigm is a bad idea, for
example... one of its key strengths in my opinion is building different
portal-apps to the data for different classes of user, and in that way
increasing security, while simplifying development... but as a means to
literally separate data from application to enable you to avoid having
to do imports? Its not quite the holy grail proponents make it out to
be.

-regards,
Dave