So... cool! I'm excited about the new release!

But what exactly are "tables"? Are they related at all to the View as Table view? What is the benefit of having "multiple tables per record"?

Version: Developer v6

Platform: Mac OS 9

OK -

what we formally new as datbases are now Tables, and a database is now a set of tables.

You can have more than 1 table per database. An example might be a contact database.

1 table for the contact information (name, address etc)

1 table for the contact's numbers (phone, fax, email etc)

1 table for activities with that contact

Yet you only have a single database.

HTH

If you have ever used MS Access all information is stored in tables (similar to MS Excel) you have to create anew table (which is advisable for faster searches)...however Access is so cumbersome and slow compared to FMP...so it seems version 7 combines the best of Access with the ALREADY best FMP...

Let's say you were doing a classroom grade book...it would look something like this...

Table 1: Bio info (Name, address, phone)

Table 2: Assignments

Table 3: Attendance

Table 4: Grades by semester

Similar to andygaunt's exampleabovebut I was taught to keep all the biographical info together (combine contact info with contact numbers)..

The problem with access once you make the tables you have to set up relationships where FMP keeps all the info together...

I am very new to databases but I have been taking workshops on Access at work (last one is tomorrow) and found FMP to be MUCH more user friendly...MSstill lives in the dark ages...

Here is a different example on tables using FileMaker Pro 6 and below structure.

File 1 = Contact_List.fp5 (this your regular average FMP Database)

File 2 = Houses_4_Sale.fp5 (this your regular average FMP Database)

Now before, in order create a "Relational Database Suite" you would have to define a key in File 1 that matches a key in File 2.

"Tables" in the "Database World" is basically what I have listed above.

Table 1 = File 1 (Contact_List.fp5)

Table 2 = File 2 (Houses_4_Sale.fp5)

What FileMaker Pro 7 is saying is:

1 FileMaker Pro 7 Database = Millions of "Tables".

Does this help?

This is a lot more complex than it appears on the surface. Multiple tables and multiple windows means multiple found sets. Script and calculation context and focus are important. And these changes require considerable work to "grok".

Steven

Absolutely Steven.

Now with the possibility to;

1. do a find

2. return the found set (if greater than 1) to another window in list view.

3. keep the original window on the data entry layout

4. click a record in the list and have it focus on that record in the data entry window (and highlight the chosen record in the list view window).

The possibilities become a lot wider yet the complexity of the database becomes greater.

Now more than ever do I state.

Work out your designs and process flows on paper first. It is so key in the development process and now more than ever with FileMaker Pro 7.

I totally agree with you Andy and Steven!

This is WAY more complex now. So as Andy stated, WORK OUT YOUR PROCESSES ON PAPER FIRST!!!

Trust me, it is worth the time to do.

Excited to poke around multi-table file setup, and I *love* the multi-criteria relations -- will save much concat definition work.

Frustration: My files have been converted, but their relationships are all still file-to-file. I see how to *create* a secondary table (and its fields) in my central file, and import into table from another file. But I've got dozens of related files, and I don't want to have to replicate all my field definitions before I get single-file benefits. I know there will be tweaking to do, but it would be nice not to have to do what surely almost every FM7 adopter will have to do, and which FM must "know" how to do...

So: is there no way to get an FM7 file to "inhale" a related file wholesale (with its relations, which FM7 already parses) so that it becomes a related table in the same file? Do I have to go and define all my related fields from scratch and then import? Can't be...

Version: v7.x

Platform: Mac OS X Jaguar

Sorry this is not possible.

But you might want to really look at this structure. You may not want to put all your eggs in one basket There is compelling reason to keep some files and relate to them.

In this way you may be able to separate your data from your database.

here is a basic example of separate data and interface files

Version: v7.x

Platform: Mac OS X Panther

Archive.zip

Well, not at the minute anyway -

But in the Tech brief migration pdf http://www.filemaker.com/downloads/pdf/techbrief_fm7_migration.pdf it lists the following statement on page 26

Table Consolidation Tools

Hmmm if this can be done programatically then I would like to speculate this ....

if I have a "Shrink Wrap" solution and I make a few modifications maybe add a few fields

a few calculations and maybe a relationship or two.

It would be great if there were a tool that would create an UPDATER so that I can

send my clients a updater or they can download one and upgrade their solution.

Did I miss something in my rapid perusal of this set of threads?

Do you mean I can have a single 'file/database' (Let's call it MyJunk.fp7) with multiple related tables and also a second 'file/database' related to MyJunk.fp7 or some of the tables in it?

I'd love to look at your attachment, Stephen, but FMP in their wisdom have stuffed up the interface to get a trial download.

It is good to see that FMP have finally adopted the nomenclature used by the rest of the world. A Database is a collection, or set, of data, not a component of the collection.

I have a question for the Filemaker whizzes out there. This may actually need a separate post, so tell me if I should.

I am the owner of a graphic design firm who has recently taken on doing contract work for a local marketing company. We currently use a filemaker database to track all of our clients. I would like devise a simple solution for making proofs available online to customers through Filemaker 7. From the mucking around I have done at this point this looks possible.

We currently have a server running OS X 10.3 with a small website being hosted specifically for serving client proofs. We currently drop our proofs in folders for the clients and then provide a URL for them to download or view the proof in their browser. This works, but requires a lot of work to check what version we are posting and then send the appropriate URL via email.

The ideal solution would be to have a database open on the server, which is available via the web. This database would allow a customer to log in and view all of their proofs with the same username and password each time.

For the back-end, it would be nice to simply add an image to the database under the customers record (which I understand can now be done easily with a link to the file rather than embedding in the database) and that be available to the customer when they log in.

My delima is how to structure the database so that customers only have access to their records and not everyone else's records. The permissions structure seems to be very thorough in FM7 but I am unsure of how to structure the DB with the new Tables capability. It would seem that each customer should have a table but there is not way to create a table and then duplicate that table as we add customers. IT appears as though we would have to create each new table from scratch. If this were possible I would create a table and then assign privileges to the individual tables.

Please realize I am not a DB guru, so I am not the most experienced. I do understand relational DB ideas for the most part, but I am unsure about this structuring idea.

I ask someone here in the office that has some experience with databases and her suggestion was to create tables for each of the sections with a key field residing in the first table: Customer(key), customer info(key relationship), customer proofs(key relationship), etc. But then I am in a quandary as to how I would limit the customer to only the record or view that shows their info in each of the tables.

I am I approaching this from the wrong perspective?

I hope all of this makes sense and any help would be appreciated. Please keep in mind that we are a small design firm with limited resources, thus hiring someone to do this at this time is not feasible (though I would certainly like to if I could )

Thanks again for the help.

Jamie Meredith

i4-Design.net

"So: is there no way to get an FM7 file to "inhale" a related file wholesale (with its relations, which FM7 already parses) so that it becomes a related table in the same file?"

Check out the new tool being offered to consolidate files into tables by New Millennium:

http://www.newmillennium.com

Steven

In addition to considering Stephen's sage advice regarding separating data layers from interface & business layers you will most likely want to spend some time considering which fields are actually appropriate for consolidation into a FM7 solution. You'll be surprised how many "FM6 thinking" fields can be left behind.

-Colleen

Thanks for the tip about Millenium's conversion/consolidation solution. The web page mentions a Windows'-only release on March 16th, but no word on timing for the Mac version.

Anyone else bewildered at the lack of convertibility between tables and separate files? Given that there are advantages to each -- AND that we're all experimenting with revisions to our FM6 brains , it seems that convertibility in both directions ought to be included, at least at the Developer level.

"The web page mentions a Windows'-only release on March 16th, but no word on timing for the Mac version. "

When hunting for ducks, one must go where the ducks are.

Steven

So far I understood that it is (at present) not possible to import a related file as a table.

So I created a new table by hand with all fields etc. and tried to import the data from the related file. Not possible! It seems that you can import data only into the first table of a database. I am shocked. What do they think at Filemaker Inc ? This renders the whole table thing useless. Or am I missing something.

Any help would be appreciated.

Version: v7.x

Platform: Mac OS X Panther

tscho,

I had no trouble importing from an existing file to a new (non-primary) table. Notice that when you create a table and populate it with fields, there will immediately be a new "layout", which is named after the table (and which shows 0 records at first). Go into that layout first, and then perform the import. Fields in your external file will be lined up (in your import dialog) against the fields in the new table, rather than against the fields in the main table.

ESpringer said:

Notice that when you create a table and populate it with fields, there will immediately be a new "layout", which is named after the table (and which shows 0 records at first). Go into that layout first, and then perform the import.

Thanks. I didn't notice that the import-table depends on the layout I am looking at. Strange User Interface (why is there no simple popup for the target table in the import window?). Anyway it seems I have to re-learn some basics ... and change some habits

tscho

Version: v7.x

Platform: Mac OS X Panther

ok...so here is the question once again...

When do you put all of your files into one database...or when do you put all of your tables into one file...should I keep them seperate? Is there a good reason why I should do that or flip it..is there a good reason why I should put all of them into one?

Help...

That you have to be _in_ the target table before you import IS like filemaker. I mean, everything about it is so context sensitive. I am glad they have taken some of that out of scripting. BUT, I took my first real hard look at tables/files today, and it really IS hard to grasp at first. I mean, I understood the difference between what FM calls a table and a file and the use of these terms in other databases, but the whole relationship between LAYOUTS and tables and FILES, OH MY! For some reason, I could not manage to get two views on the same layout which I thought was supposed to be easy. Surely this does not involve file references?

Anyway, It's weird that fmp6 was such a minor upgrade and 7 is so major. IMHO, but then, I didn't even bother with v6.

Old Advance Man said:

"The web page mentions a Windows'-only release on March 16th, but no word on timing for the Mac version. "

When hunting for ducks, one must go where the ducks are.

Steven

If you want to kill the ducks, yah, but if you just want ducks, there must be a better way!