I understand that FM7 introduced the possibility of having more than one table in a file ... and that it was thereby possible to have metadata and layouts in one file and data in another. Is this so? If so, is it possible to combine layouts from several files into a single file?

I understand that FM7 introduced the possibility of having more than one table in a file ... and that it was thereby possible to have metadata and layouts in one file and data in another. Is this so? If so, is it possible to combine layouts from several files into a single file?

I understand that FM7 introduced the possibility of having more than one table in a file ... and that it was thereby possible to have metadata and layouts in one file and data in another. Is this so? If so, is it possible to combine layouts from several files into a single file?

Read up on the data separation model in the FMP 7 Mega Tech Brief, available on the FMI web site.

Read up on the data separation model in the FMP 7 Mega Tech Brief, available on the FMI web site.

Read up on the data separation model in the FMP 7 Mega Tech Brief, available on the FMI web site.

In the one file creat all your necessary tables, in other file creat your necessary layouts with showing records from сorresponding file.

In the one file creat all your necessary tables, in other file creat your necessary layouts with showing records from сorresponding file.

In the one file creat all your necessary tables, in other file creat your necessary layouts with showing records from сorresponding file.

Hi Vaughan,

While this is an excellent and long brief, my quick perusal of it leads me to think that it does not discuss how to migrate table definitions, layouts etc. from one file to another. I can migrate the actual data via the export/import functions, but if for example, I have two tables, is there a way to import the defintions of the tables into a separate file, and the layouts into another, or do I have to recreate all of this information manually?

Thanks,

Pat

Hi Vaughan,

While this is an excellent and long brief, my quick perusal of it leads me to think that it does not discuss how to migrate table definitions, layouts etc. from one file to another. I can migrate the actual data via the export/import functions, but if for example, I have two tables, is there a way to import the defintions of the tables into a separate file, and the layouts into another, or do I have to recreate all of this information manually?

Thanks,

Pat

Hi Vaughan,

While this is an excellent and long brief, my quick perusal of it leads me to think that it does not discuss how to migrate table definitions, layouts etc. from one file to another. I can migrate the actual data via the export/import functions, but if for example, I have two tables, is there a way to import the defintions of the tables into a separate file, and the layouts into another, or do I have to recreate all of this information manually?

Thanks,

Pat

The tech brief does suggest some tools to help in migration. Specifically, FMRobot from New Millennium. For smaller solutions, it's not too hard to transfer table definitions and layouts manually. Many scripts will be obsolete in a combined file, so these may be better to import as needed.

The tech brief does suggest some tools to help in migration. Specifically, FMRobot from New Millennium. For smaller solutions, it's not too hard to transfer table definitions and layouts manually. Many scripts will be obsolete in a combined file, so these may be better to import as needed.

The tech brief does suggest some tools to help in migration. Specifically, FMRobot from New Millennium. For smaller solutions, it's not too hard to transfer table definitions and layouts manually. Many scripts will be obsolete in a combined file, so these may be better to import as needed.

I'm attempting to convert a fairly complex but small application. I beg to differ that it is not too hard to transfer the definitions manually, if by manually you mean to re-develop the layouts from scratch. This would be very tedious, and probably introduce a large number of errors. Without using FM Developer or expensive tools such as FMRobot (which I understand only works on the FM 5 or 6 versions and thus can't be used after migration), is there anyway of moving the scripts without opening each one and copying the text to a new script? In my experience, most other 4GL tools have an export function for metadata.

I'm attempting to convert a fairly complex but small application. I beg to differ that it is not too hard to transfer the definitions manually, if by manually you mean to re-develop the layouts from scratch. This would be very tedious, and probably introduce a large number of errors. Without using FM Developer or expensive tools such as FMRobot (which I understand only works on the FM 5 or 6 versions and thus can't be used after migration), is there anyway of moving the scripts without opening each one and copying the text to a new script? In my experience, most other 4GL tools have an export function for metadata.

I'm attempting to convert a fairly complex but small application. I beg to differ that it is not too hard to transfer the definitions manually, if by manually you mean to re-develop the layouts from scratch. This would be very tedious, and probably introduce a large number of errors. Without using FM Developer or expensive tools such as FMRobot (which I understand only works on the FM 5 or 6 versions and thus can't be used after migration), is there anyway of moving the scripts without opening each one and copying the text to a new script? In my experience, most other 4GL tools have an export function for metadata.

The experience of many, many developers has been that except for all but the most simple of solutions, it's better and faster to redesign and rebuild solutions from scratch than it is to convert and repair.

This is mostly because FMP 7 offers new and more efficient ways of doing things that have no FMP 6 equivilent; and many techniques necessary in FMP 6 are inefficient and cumbersome in FMP 7.

The most common methodology seems to be to convert the existing solution to FMP 7, then redesign and rebuild while recycling as much from the old converted system as makes sense. Often, it's surprisingly little that makes sense to be recycled.

The experience of many, many developers has been that except for all but the most simple of solutions, it's better and faster to redesign and rebuild solutions from scratch than it is to convert and repair.

This is mostly because FMP 7 offers new and more efficient ways of doing things that have no FMP 6 equivilent; and many techniques necessary in FMP 6 are inefficient and cumbersome in FMP 7.

The most common methodology seems to be to convert the existing solution to FMP 7, then redesign and rebuild while recycling as much from the old converted system as makes sense. Often, it's surprisingly little that makes sense to be recycled.

The experience of many, many developers has been that except for all but the most simple of solutions, it's better and faster to redesign and rebuild solutions from scratch than it is to convert and repair.

This is mostly because FMP 7 offers new and more efficient ways of doing things that have no FMP 6 equivilent; and many techniques necessary in FMP 6 are inefficient and cumbersome in FMP 7.

The most common methodology seems to be to convert the existing solution to FMP 7, then redesign and rebuild while recycling as much from the old converted system as makes sense. Often, it's surprisingly little that makes sense to be recycled.

I agree with Vaughan, that often it is easier to rewrite from scratch. Although this sounds like a lot of work, it's not as much work as the effort that went into the original solution, because you already KNOW the business logic required, and that's half the work. All this is debated in that tech brief.

To answer your questions, PAW, here are some basics to combine your files:

First the fields:

1. Sort your source file's field definitions by Creation Order, then print to PDF and open it in Preview.

2. With that open in one window, open your desination database, and add the new table.

3. Begin typing fields. It's not that hard to type out a hundred fields, just be sure to type the names exactly as they were in the old file. For the calcs, leave them blank for now.

4. Tie in the new table into the relationship graph, changing the existing external references to the source table to refer to the new table.

5. Go back and add the lookups, auto-entered calcs, and calculations, copying the formulas from the PDF. Be sure to set the correct result type for the calcs.

Next the scripts:

1. Open scriptmaker in the destination file.

2. Hit the Import Scripts button.

3. Open the version 7 source file, and select the scripts you wish to import.

Now the layouts:

1. Open the source file to a layout you wish to copy.

2. In Layout Mode, Select All, and Copy.

3. Go to the destination file and add a new blank layout, choosing the correct TO as the layout's base table.

4. Paste the clipboard contents into the new layout.

5. Check and fix the button definitions, as sometimes they don't match up right.

6. Go back and fix the scripts, especially Go to Layout steps.

If the source file had had fields deleted in its lifetime, it's likely the layouts and scripts won't match up to the new fields correctly, as fields are matched with an internal ID and not by name. This is tricky to fix ahead of time, but if you know where those fields were in the creation order, it's possible to add dummy fields in the new table to take their place, so that they will match when you paste the old layouts and import the old scripts. Most of the time I fixed those manually, but at one point I did figure out where to insert those dummies (I can't remember now.)

If you have a large solution and you're determined to combine your files, then those expensive tools are probably worth it.

I agree with Vaughan, that often it is easier to rewrite from scratch. Although this sounds like a lot of work, it's not as much work as the effort that went into the original solution, because you already KNOW the business logic required, and that's half the work. All this is debated in that tech brief.

To answer your questions, PAW, here are some basics to combine your files:

First the fields:

1. Sort your source file's field definitions by Creation Order, then print to PDF and open it in Preview.

2. With that open in one window, open your desination database, and add the new table.

3. Begin typing fields. It's not that hard to type out a hundred fields, just be sure to type the names exactly as they were in the old file. For the calcs, leave them blank for now.

4. Tie in the new table into the relationship graph, changing the existing external references to the source table to refer to the new table.

5. Go back and add the lookups, auto-entered calcs, and calculations, copying the formulas from the PDF. Be sure to set the correct result type for the calcs.

Next the scripts:

1. Open scriptmaker in the destination file.

2. Hit the Import Scripts button.

3. Open the version 7 source file, and select the scripts you wish to import.

Now the layouts:

1. Open the source file to a layout you wish to copy.

2. In Layout Mode, Select All, and Copy.

3. Go to the destination file and add a new blank layout, choosing the correct TO as the layout's base table.

4. Paste the clipboard contents into the new layout.

5. Check and fix the button definitions, as sometimes they don't match up right.

6. Go back and fix the scripts, especially Go to Layout steps.

If the source file had had fields deleted in its lifetime, it's likely the layouts and scripts won't match up to the new fields correctly, as fields are matched with an internal ID and not by name. This is tricky to fix ahead of time, but if you know where those fields were in the creation order, it's possible to add dummy fields in the new table to take their place, so that they will match when you paste the old layouts and import the old scripts. Most of the time I fixed those manually, but at one point I did figure out where to insert those dummies (I can't remember now.)

If you have a large solution and you're determined to combine your files, then those expensive tools are probably worth it.

I agree with Vaughan, that often it is easier to rewrite from scratch. Although this sounds like a lot of work, it's not as much work as the effort that went into the original solution, because you already KNOW the business logic required, and that's half the work. All this is debated in that tech brief.

To answer your questions, PAW, here are some basics to combine your files:

First the fields:

1. Sort your source file's field definitions by Creation Order, then print to PDF and open it in Preview.

2. With that open in one window, open your desination database, and add the new table.

3. Begin typing fields. It's not that hard to type out a hundred fields, just be sure to type the names exactly as they were in the old file. For the calcs, leave them blank for now.

4. Tie in the new table into the relationship graph, changing the existing external references to the source table to refer to the new table.

5. Go back and add the lookups, auto-entered calcs, and calculations, copying the formulas from the PDF. Be sure to set the correct result type for the calcs.

Next the scripts:

1. Open scriptmaker in the destination file.

2. Hit the Import Scripts button.

3. Open the version 7 source file, and select the scripts you wish to import.

Now the layouts:

1. Open the source file to a layout you wish to copy.

2. In Layout Mode, Select All, and Copy.

3. Go to the destination file and add a new blank layout, choosing the correct TO as the layout's base table.

4. Paste the clipboard contents into the new layout.

5. Check and fix the button definitions, as sometimes they don't match up right.

6. Go back and fix the scripts, especially Go to Layout steps.

If the source file had had fields deleted in its lifetime, it's likely the layouts and scripts won't match up to the new fields correctly, as fields are matched with an internal ID and not by name. This is tricky to fix ahead of time, but if you know where those fields were in the creation order, it's possible to add dummy fields in the new table to take their place, so that they will match when you paste the old layouts and import the old scripts. Most of the time I fixed those manually, but at one point I did figure out where to insert those dummies (I can't remember now.)

If you have a large solution and you're determined to combine your files, then those expensive tools are probably worth it.

It's not that hard to type out a hundred fields, just be sure to type the names exactly as they were in the old file.

Just curious: exporting to .mer, then opening the exported file?

It's not that hard to type out a hundred fields, just be sure to type the names exactly as they were in the old file.

Just curious: exporting to .mer, then opening the exported file?

It's not that hard to type out a hundred fields, just be sure to type the names exactly as they were in the old file.

Just curious: exporting to .mer, then opening the exported file?

Hi Ender,

This is very helpful information. I wasn't aware of the fact that I could export scripts ... now I know. I am a newbie as far as FileMaker is concerned ... there is lots to unlearn from other experiences. BTW, is there any way other than by taking screen shots of documenting scripts. I can print out relationships and table layouts ... but so far I have been unable to find out how to print out scripts.

Just a BTW ... I am not that familiar with the existing system. I have been asked by the system owner to convert it to FM7 ...but they have a smallish budget so I do not want to deliver a cadillac solution when all the want is a VW.

Thanks.

Hi Ender,

This is very helpful information. I wasn't aware of the fact that I could export scripts ... now I know. I am a newbie as far as FileMaker is concerned ... there is lots to unlearn from other experiences. BTW, is there any way other than by taking screen shots of documenting scripts. I can print out relationships and table layouts ... but so far I have been unable to find out how to print out scripts.

Just a BTW ... I am not that familiar with the existing system. I have been asked by the system owner to convert it to FM7 ...but they have a smallish budget so I do not want to deliver a cadillac solution when all the want is a VW.

Thanks.

Hi Ender,

This is very helpful information. I wasn't aware of the fact that I could export scripts ... now I know. I am a newbie as far as FileMaker is concerned ... there is lots to unlearn from other experiences. BTW, is there any way other than by taking screen shots of documenting scripts. I can print out relationships and table layouts ... but so far I have been unable to find out how to print out scripts.

Just a BTW ... I am not that familiar with the existing system. I have been asked by the system owner to convert it to FM7 ...but they have a smallish budget so I do not want to deliver a cadillac solution when all the want is a VW.

Thanks.

Well ... I answered my own question ... I did not realize that the print function was only available from the list of scripts in ScriptMaker. I thought it would be available in the Edit function (stupid me!).

Also, I see that there is an import function for scripts and not an export function.

Well ... I answered my own question ... I did not realize that the print function was only available from the list of scripts in ScriptMaker. I thought it would be available in the Edit function (stupid me!).

Also, I see that there is an import function for scripts and not an export function.

Well ... I answered my own question ... I did not realize that the print function was only available from the list of scripts in ScriptMaker. I thought it would be available in the Edit function (stupid me!).

Also, I see that there is an import function for scripts and not an export function.