New to fmp7

[mattc]

Hi

I have done quite a bit of database developement in fmp5 & 6, but have just gotten around to looking properly at fmp7.

One solution I am converting over is a technical call logging system comprising of a number of fmp5 files:

Contract

Call Log

Customers

etc

I have managed to convert this solution over in a working state (apart from a couple of silly script glitches), but am curious as to which is the best way forward.

My understanding was that among other features fmp7 can have multiple tables per db file (as aposed to my seperate fmp5 files above). During the conversion I was expecting an option to 'flatten' my solution into one database file.

Q. Is there a way to do this & is there any benefit?

My solution is reasonably complex with quite a few relationships (both between files & self joins etc). Re-creating parts wouldn't be an option with the time already invested.

Q. Are there any issues keeping the files seperate?

Sorry if this sounds amateur but i wish to get the foundation correct in version 7 before I continue development.

Thanks for any help & appologies if this is a duplicate question - the searching doesn't seem to be write since the Forum upgrades?

Matt

[PatriciaW]

Following advice from several forum veterans, I adopted the separation model. I created separate files for each logical database. Some of these databases included more than one table ... where there was a one to many relationship e.g. between a client and the client's phone numbers.

Then I created a single user interface file which included all of the previous layouts and scripts.

This has worked for me so far.

[RalphL]

Hi

I have done quite a bit of database developement in fmp5 & 6, but have just gotten around to looking properly at fmp7.

One solution I am converting over is a technical call logging system comprising of a number of fmp5 files:

Contract

Call Log

Customers

etc

I have managed to convert this solution over in a working state (apart from a couple of silly script glitches), but am curious as to which is the best way forward.

My understanding was that among other features fmp7 can have multiple tables per db file (as aposed to my seperate fmp5 files above). During the conversion I was expecting an option to 'flatten' my solution into one database file.

Q. Is there a way to do this & is there any benefit?

FM7 does not have the means to combine the files into one database. There is a tool FM Robot ( http://www.nmci.com )that will do this but you must first make a DDR for each of the files. This implies that you use Dev 7. I think that you will see the benefits as you continue. It often reduces the number of scripts, value lists, relationship and even fields.

If you don't use FM Robot then you will have to create the tables as if it were a new database. You will be able to copy and paste layouts.

My solution is reasonably complex with quite a few relationships (both between files & self joins etc). Re-creating parts wouldn't be an option with the time already invested.

Q. Are there any issues keeping the files seperate?

Sorry if this sounds amateur but i wish to get the foundation correct in version 7 before I continue development.

Thanks for any help & appologies if this is a duplicate question - the searching doesn't seem to be write since the Forum upgrades?

Matt

The main disadvantge to keeping the files separate is you loose the experience of learning 7.

[PatriciaW]

One problem I discovered was that Go To Related Records doesn't work with the separation model. It requires that the layout be in the same file as the table. That required significant work around.

[RalphL]

You can use External File's Layout. Or just add a blank layout based on the file.

[CobaltSky]

One problem I discovered was that Go To Related Records doesn't work with the separation model. It requires that the layout be in the same file as the table. That required significant work around.

I'm afraid that is entirely incorrect, Patricia. The Go to Related Record command works fine entirely within an interface file (source and destination layouts in the interface file, both tables in other files). No work-arounds required.

I suggest that you take another look at it. B)

[PatriciaW]

I stand corrected. I had a problem with this during my FM7 learning curve and someone led me to believe that this was the case. Now that I read the help more carefully I see that I was wrong.

Mea culpa B)

[mattc]

Thanks Guys!

I take the points about possible reduced scripting / layout's etc, but no one has mentioned performance...

Is there an overhead to running the database across multiple fp7 files compared to having it in one self contained file?

[CobaltSky]

Interesting question, mattc.

The short answer is no, there isn't.

The (slightly) longer answer is that in fact, for the most part, the cookie crumbles in the other direction. In the first releases of v7 there was in fact a slight performance disadvantage to having many tables in a single file - though this did not apply to all operations and one or two (most notably pertaining to a bug which results in painfully slow drawing of pop-up menus when a large number of files are open) counteracted the general trend.

Later releases of 7 (most notably v3) seem to have reduced the impact in this regard (though the pop-ups issue remains).

However notwithstanding all of the above, the reasons for choosing a solution structure are many - and overall slight performance differentials in one rev or another are rarely likely to be the most compelling. B)

[Inky Phil]

Forgive me Ray, but does that mean that the slow pop ups problem is minimised if all the tables are in one file or is it minimised if one uses seperate files?

phil

[CobaltSky]

The former, Phil.

Specifically, I understand the issue has to do with FileMaker's internal allocation of memory for screen draw. Thus if more files are listed in the Window menu at any given time, more memory is reserved for managing the imaging of windows for each of those files (whether they are displayed or not) and this compounds a memory management issue which slows down the building of value lists for display in pop-up menus.

So, if the tables are in fewer files, the performance hit will be less (ie the lists will display more quickly).

However since it is not the number of files per se but the number of *open* files at any one time that determines the impact of the problem, there are other ways to ameliorate it. Eg a solution management strategy which closes files selectively to minimize the number open at any given time. Challenging - but doable with careful planning. B)