Apologies if this has been asked before, but I just want to make sure of
something.

I have a relational database I made in FMP6, comprised of two related
files. I would like to upgrade this to a single-file solution in FMP8.

To do this, do I have to basically rebuild the second file as a table in
the first file? As in, set up the fields from scratch in a second table
in FIle1, import the data from File2.

That's not so big a task -- but then do I need to go through each layout
in File 1 which had portals to File2 and re-assign each of those fields
so they now point to the new version of the field in the new table?

.. . . and then any scripts that visited File2 also have to be re-tooled
individually, yes?

I realize I could keep it a 2-file design, but this is a database that I
created for an institution I no longer work for and I'm thinking a
single-file design might be more secure -- less prone to filing/renaming
mishaps. I think I could make these changes by hand -- laborious but
not crazy huge task. But I just want to make sure I'm not doing
something 'the hard way' oly to find there's a simpler approach
afterwards!

thanks
Albert

In article <asteg-559C21.11371306052007 (AT) news (DOT) west.earthlink.net>,
Albert <asteg (AT) mindspring (DOT) com> wrote:

The steps:

1. Batch-convert the FMP6 solution to FMP7 (8). To do this, drag both
FMP6 files onto the FMP8 icon. It will convert them both to .fp7 files,
with the relationships, scripts and layouts essentially intact. Go
through this two-file solution, and verify that it works right and the
data is intact.

2. Select one of the .fp7 files to be the main file. Make this selection
mainly on table complexity, the file with the most complex table. Then
build the other table in that file, import the data into that new table,
and redefine the relationships to point to the new table. Copy and paste
layouts as needed from the old file to the new, and import scripts as
needed.

A certain amount of rebuilding from scratch is desirable to streamline
the solution by taking advantages of the many feature of FMP8 that are
not available in FMP6, such as the use of variables in script steps, and
many others.

In FMP 8.5 Advanced, there is the ability to import table schema from an
external file. This would reduce the labor required to build the second
table in the one file. I do not remember if FMP8 has this capability.

--
For email, change <fake> to <earthlink>
Bill Collins

In article
<bbcollins-652E55.18400506052007 (AT) customer-201-125-217-207 (DOT) uninet.net.mx>
,
Bill <bbcollins (AT) fake (DOT) net> wrote:

Thanks, Bill for the concise roadmap. Just to clarify: when I
re-define the relationship from the Main table to the new secondary
table, the fields from the second file won't automatically match up to
their same-named "new" versions in the newly-formed table, will they?
It's looking to me like I'll just have to double-click on each field in
the portals to re-connect them to the data in their new place. There's
no way to tell all of those fields "Look here in this table rather than
over there in that old file) - right?

.. . . or is this the sort of thing I'm asking about?

Albert

In article <asteg-388A6D.18572106052007 (AT) news (DOT) west.earthlink.net>,
Albert <asteg (AT) mindspring (DOT) com> wrote:

Once you re-define the relationship in the new file, so that it points
to the new "secondary" table in that file rather than to the external
file, then all the fields in the layouts that were formerly fields of
the "old" secondary table will automatically become the fields of the
"new" secondary table. That is, provided the field structure is the same
in both the new table and the old external table.

--
For email, change <fake> to <earthlink>
Bill Collins

On May 6, 4:57 pm, Albert <a... (AT) mindspring (DOT) com> wrote:
After combing the two files and creating the new table and fields (all
with the same names as the old ones), then you go to the relationships
graph, double click on the old file and change it to the new table and
everything should match up.

In the Advanced version of Filemaker, you have the ability to copy and
paste entire tables (and individual fields and entire scripts) which
makes step one of the above process much easier.

In article
<bbcollins-83A4F2.08045207052007 (AT) customer-201-125-217-207 (DOT) uninet.net.mx>

Hmmm . . . okay, so I used the *very* handy "Import from File" function
an selected "New Table" as the 'target' on the import control box, and
sure enough, there was a nice new table with all the fields from the
secondary file floating free in the relationships graph.

So I severed the previous relationship with the table in the external
file and deleted that table. THen I created the relationship between
the Main table and the New Table, using the same key field. Dandy.

I haven't copied the *layouts* from the defunct file yet, but I'm trying
to get the fields in the Main File layouts with Portals to show up okay.
Initially, the portals were totally blank in Browse mode. Then I
thought "Ah - I need to reassign the Portal," which I did in layout mode
-- double-clicking in the portal and choosing the new field in the
pulldown menu.

Going back to Browse, I found that the graphcs and text labels etc. show
up okay, but the fields themselves (from the new table) don't work --
they say 'Table not found'. Dang! I found that by double-clicking on
these fields, I can select the fields in the new table manually and the
data shows up okay.

Is there some step I'm missing, whereby the transition is not happening
properly? The database is not so complex that I can't do this by hand,
but I'm frustrated that I'm not quite 'getting' the system right and
don't want to waste labor.

Thanks again for all the pointers!

Albert

PS -- I have now updated to 8.5 Advanced, so I should have all the tools
available.