Jump to content
Server Maintenance This Week. ×

FM7 Layouts


This topic is 7306 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

I only just got FMP7 a week ago, and I'm still trying to wrap my head around the new file structure, changes in field definitions, calcs, and so on.

I have a pretty good understanding of databases with multiple tables (having dealt with it to a limited degree in Access), but I had a question: it appears to me that, in a situation where you have multiple related files, now ALL of the layouts have to be in a single file.

Is this true? If so, I take it this now means we have to use the "New Window" command to bring up an alternate layout from one of the other related tables?

This has me perplexed -- I guess just because it's a kind of jaw-dropping problem that now, instead of having 11 files, each with maybe 40-50 or so layouts, now I have ONE file with 500 layouts! Ai-yi-yi...

I'm still baffled as to why FM Inc. wouldn't or couldn't develop a conversion program on their own that would take a multiple-file solution and make it into a one-database/multiple-table solution. That would've been a perfect thing to include in Developer 7.

I've read all the docs on FMP's webpage. The problems in migrating solutions over to 7 are hard enough that I already know a client who is mulling over just abandoning FMP and going to Access. I'm arguing with them not to do this, but it's going to be a real issue in the months ahead.

--Marc W.

FileMaker Version: Dev 7

Platform: Mac OS X Jaguar

Link to comment
Share on other sites

Simply changing the layout changes the table you're now looking at in the window.

If you want to stick with multiple files you can now.

"I'm still baffled as to why FM Inc. wouldn't or couldn't develop a conversion program on their own that would take a multiple-file solution and make it into a one-database/multiple-table solution."

Because it's more than just layouts that need to be imported into the one file, it's scripts and fields too. And scripts that call other scripts in other files make it all too complicated for a dumb conversion program to get right 100% of the time.

Link to comment
Share on other sites

  • Newbies

Vaughan said: Simply changing the layout changes the table you're now looking at in the window.

Yeah, I figured that. Again, it's just such a massive paradigm shift, it's hard to get over. But I take it my guess is correct: all layouts now live in one file, and the tables share all layouts. It's just a question of defining which table and fields show up in any one layout.

After 10 years of dealing with FMP 2-6, the whole thing makes my brain hurt. But I'll eventually get over it.

Vaughan said: Because it's more than just layouts that need to be imported into the one file, it's scripts and fields too. And scripts that call other scripts in other files make it all too complicated for a dumb conversion program to get right 100% of the time.

Oh, I dunno. I've always had the opinion that almost anything you can do by hand -- especially boring, repetitive tasks -- are more efficiently done by a program. And the fact that already, two third-party companies have come out with FMP6 -> FMP7 utilities tells me that Filemaker Inc. didn't do enough to make this job easier for us. Even if they had created a utility that would take standalone database files and then convert them one at a time to tables, then let us go in and fix the scripts by hand... even doing that would've been a great help. One of my main projects has 11 databases files, some with 70+ fields, and having to painstakingly recreate all the definitions and calcs alone is going to take many days of drudgerous work.

I can see it literally taking *months* to get complex solutions converted to FMP7. That's a real drag, and there's no other way to look at it. The key for me is going to be whether the search and sort speed advantages in 7 will be that much better than FMP6. Does anybody have any figures yet on the real performance differences between the two versions?

--MFW

FileMaker Version: Dev 7

Platform: Mac OS X Jaguar

Link to comment
Share on other sites

>Does anybody have any figures yet on the real performance differences between the two versions?

I'm working on some speed tests with the FM7 Server preview. I should have some more results posted in the Server forums within a day or two. It looks good so far...

Link to comment
Share on other sites

Marc Wielage said:

Oh, I dunno. I've always had the opinion that almost anything you can do by hand -- especially boring, repetitive tasks -- are more efficiently done by a program. And the fact that already, two third-party companies have come out with FMP6 -> FMP7 utilities tells me that Filemaker Inc. didn't do enough to make this job easier for us. Even if they had created a utility that would take standalone database files and then convert them one at a time to tables, then let us go in and fix the scripts by hand... even doing that would've been a great help. One of my main projects has 11 databases files, some with 70+ fields, and having to painstakingly recreate all the definitions and calcs alone is going to take many days of drudgerous work.

FileMaker Version: Dev 7

Platform: Mac OS X Jaguar

There's no need for drudgery, FMRobot from New Mill. can do the a lot of the work for you. Food for thought: New Mill. is a FSA partner, which means they knew months ago that FM7 was going to ship with no import table, but that also implies to me that FMI knew FMRobot would exist at ship time. My analysis, they're all in it together. wink.gif

Personally, I'm a bit surprised everyone seems so keen to get all their tables into a single file right *now*. When I make a new table in a project I'll try putting it into an existing file, but for my immediate "conversion" I'm just using the graph to repoint tables to their data files and get rid of some pipelining.

While I would love an "import table" feature also, I'd prefer to see cut/paste of script steps between files; that's something that would help speed conversion, and I could continue to use it after I'm converted also.

FileMaker Version: Dev 7

Platform: Mac OS X Panther

Link to comment
Share on other sites

  • Newbies

The Shadow said: My analysis, they're all in it together. wink.gif

Give that man a cigar! Yeah, that's pretty much what I think, too. I guess that nobody has really come out and said it, yet, but that's the same conclusion I'm coming up with. It's as if FMI deliberately held back on giving us all the tools we needed for smooth conversion between FM6 and FM7, and gave this "feature" to the third-party developers first.

Personally, I'm a bit surprised everyone seems so keen to get all their tables into a single file right *now*.

Well, I think there are some considerable benefits -- especially if you had a brand-new solution and started it that way. In my case, I have some fairly complex Find scenarios that I can already see will happen much faster given one database and multiple tables, vs. multiple files. As FMP has already said, if nothing else, there isn't a need for as many "external" scripts anymore, since they can all live in one place now. That alone will simplify a lot of things for me, since in my main application, I had to do a lot of fancy footwork -- firing off scripts in one file, bouncing back to another file, setting fields, hiding screens and stuff, just to let things happen in the background. One quick experiment showed me that the new structure for FM7 cuts the speed down by a third.

While I would love an "import table" feature also, I'd prefer to see cut/paste of script steps between files; that's something that would help speed conversion, and I could continue to use it after I'm converted also.

Well, given that we can import scripts already, couldn't you just do it that way? On the other hand, I agree with you that cutting & pasting script steps would be handy -- even when you're in one file.

FileMaker Version: Dev 7

Platform: Mac OS X Panther

Link to comment
Share on other sites

Although the idea of a table merging utility is attractive on the face of it, I don't think it's really such a great idea. An FM6 style solution in FM7 wouldn't be ideal. As an example: concatentated fields for 2-or-more-away realationships are deadwood. The translated solution would be filled with clumsy, unecessary chunks and bits.

Granted, the planning necessary to get a solution moved and modified...yikes! But slapping a Lamborgini body onto my Ford Escort guts?

As to mega files with hundreds of layouts, the article "Upgrading to FileMaker 7: How to migrate existing solutions" (http://www.filemaker.com/upgrade/techbriefs.html) had a fair discusion of the reasons to use single or multiple files. It discusses having seperate files for tables and scripts and when this may be advantageous. Possibly spliting layouts out to seperate files would be possible and helpful? Strange idea.

Considering the choices that need to be made as tables are brought together in a file or grouped in several files...I think an xtables-to-1-file utility would only be useful occasionally.

Don

Link to comment
Share on other sites

Marc Wielage said:

Well, given that we can import scripts already, couldn't you just do it that way? On the other hand, I agree with you that cutting & pasting script steps would be handy -- even when you're in one file.

Yes, you're right - I should have said field definitions, not script steps. The point I was trying to make was it would be better to have a feature that would help make changes easier in general, rather than specifically for the upgrade period.

If I could go into define fields, do "select all", and paste them into the define fields dialog of another file (or the same one), then that's better than having an "import table" command, even though it accomplishes the same thing. I can easily imagine wanting to move a few fields around, but a feature to merge tables into a file seems like a one-shot kind of thing.

As for multiple files, it seems with FM7 it is much less important where the data really is stored - I'll definately be moving towards a single interface file that has a full graph, and moving scripts into it and combining them, I just don't see a big hurry to get my data in the same file also.

Personally, I'd like to see some performance comparisions of FMS hosting a system with a single 500-Meg file versus one composed of 10 50-Meg files, before putting in the effort. Before I head off in that direction I just want to be sure the destination is somewhere I want to be. wink.gif

FileMaker Version: Dev 7

Platform: Mac OS X Panther

Link to comment
Share on other sites

This topic is 7306 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.