Just bought FM7 (yesterday) after merrily using earlier versions for
years. I'm not a total beginner - I've done quite a bit of scripting,
working with relationships, self-joins, lookups, and so on. I'd say I'm
probably an intermediate user.

Are tables an entirely new concept in FM7? I was unnerved to download
FileMaker Business Tracker and find *one* file. I was ready to dive
under the hood and find a series of related files with associated
scripts.

What the hell is going on?... Can anyone tell me in a few lines what
tables are about - or is that a contradiction in terms?

TIA,

Hugh

Tables aren't really a new concept; just the fact that you can have
more than one in a single Filemaker file.

So instead of relating your Invoice file to the Customer file, you can
have both an Invoice table and Customer table in a single file.

A table stores information about an Entity. This is all part of
Relational Database theory, which you can read more about here:
http://en.wikipedia.org/wiki/Relational_database

In article <1115742646.627658.175310 (AT) o13g2000cwo (DOT) googlegroups.com>,
hugh.nagle (AT) gmail (DOT) com says...
In a few lines:

Filemaker5/6 files each were one table, with some associated layouts and
scripts.

In its simplest form Filemaker7 files can be considered to be able to
hold multiple FM5/6 "files". An FM7 table is roughly equivalent to the
fields defined and collected in a single FM5/6 file.

You can define relationships between tables within a file, or between
tables in different files.

In pre-7, a file contained one table, which is the term used in just about
every other database platform.

A table is an ordered arrangement of entities, arranged in a column
('field') and row ('record') grid, in which various attributes about the
entity are held in the columns. In other words, in, say, a Customers file
(pre-7), the entity is the customer, and the other fields hold information
about the customer, such as address, phone, etc. In addition, tables need
primary and foreign keys to allow them to be associated with other tables.

In 7, the tables can be, but do not have to be, consolidated within one
file.

--
John Weinshel
Datagrace
Vashon Island, WA
(206) 463-1634
Associate Member, Filemaker Solutions Alliance
Certified for Filemaker 7




<hugh.nagle (AT) gmail (DOT) com> wrote

John Weinshel <john (AT) datagrace (DOT) biz> wrote:

Free will is a bitch. I don't know what to do now.

More tables in one file must be more comfortable, since you can manage
accounts and privileges in one place. On the other hand, the file will
be heavier.

What are the pros and cons, if performance and stability is what you are
after?
--
http://clk.ch

In article <1gwdzpf.1lfiuxp1ws8nf6N%clk (AT) freesurf (DOT) ch>,
clk (AT) freesurf (DOT) ch (Christoph L. Kaufmann) wrote:

The advantages of multiple tables in one file are significant.

Easy to set up and manage relationships and layouts.
Easy to add relationships and layouts later.
Easy to manage accounts and privileges.
Easy to move a file to another computer without worrying about
relationships breaking. This is especially helpful if you develop a
solution on one computer, then move it to another computer for use.
Easy to set up and use network sharing and web publishing.

I can not think of any real disadvantages.

The relationship diagram in FMP 7 is much easier to use then the
text-based relationship definitions of earlier versions.

Some people advocate setting up two files, one to hold the data tables,
and one to hold the user interface. The data file would have minimal
interface elements (layouts, etc.). The interface file would have table
occurrences of all the tables need for the user, but not the data tables
themselves, and would have all the layouts and scripts the user needs.
The advantage to this approach is that the developer can modify the user
interface off-line without affecting the data file. This is commonly
known as the "data separation model."

Bill

--
To send e-mail, remove .invalid

B Collins <bbcollins (AT) earthlink (DOT) net.invalid> wrote:

Agreed.

The one file will be big. Say I have three huge tables and 50 users:

Table A, used bei (all) 50 users
Table B, used by 25 users. They use table A at the same time.
Table C, used by 10 users. They use table A and table B at the same
time.

With a separate file for each table, the 15 users who work with table A
only would not open the other files. And the files would be smaller.

I wonder what is preferable for stability and speed.

[data separation model]
And re-import the data from the old file. I like this approach. I'm
afraid that most modifications include field definitions, though.
--
http://clk.ch

B Collins <bbcollins (AT) earthlink (DOT) net.invalid> wrote:

Really? How about having to re-import 30 tables every time you tweak one
layout?
Define "easier". Yes, in some ways it is much more intuitive. It
lets you envision the context you need to create to flow data from one
table to another. For some people the visual presentation is better
than a list view.

Organization, on the other hand, is much tougher. Best practices are
still evolving and are very idiosyncratic to each developer. Consistent
naming becomes critical as Table Occurances proliferate.
Data separation is much easier than it has ever been. In fact, unless
you're building a vertical market solution for release to the general
public, using a single file is nuts. Divide the data files as makes
sense for future file size, so those tables that grow immense can have
their own files, and those that are more reasonably sized can share a
file. Divide them based on module and purpose...so all contacts tables
are in one file, all purchasing and inventory tables are in another, and
so on. Then build one or more interface files to use the data.

Once the files are more mature, you'd be surprised how little you need
to change the data files. Even using the separation approach, I've found
my need to have "interface management" fields in the data files reduced
about 90% from FM 6. No calculated multi-keys, no filtering fields, etc.

You can build in a bunch of extra straightforward data fields and just
use them later, renaming as needed during upgrades. Then switch out the
interface file, where NO importing is required at all.

We're now planning the rebuild of an extremely complex 6 solution with
48 files. We figure we're going to reduce it to about 15 data files,
probably 55 tables, and perhaps 4-6 interface files. We'll build
separate interface files for sales, purchasing and warehouse,
operations, and admin. What a great way to manage security...the sales
folks won't even have a CLUE about functions they're not allowed to
access.

As for the difficulty of managing accounts & privileges, if you use
internal FM authenticated accounts, yes, the multi-file approach sucks.
But, if you use external authentication, you solve all those problems.
It becomes the responsibility of the network admin to assign & change
groups & passwords. Any custom-built solution of sufficient complexity
is probably going to be deployed in a situation where such a network
admin is available. Heck, in one fairly small solution I deployed on OS
X, setting up the groups & users on the server itself was a piece of
cake. Now, I don't have to worry about passwords at all.

If you're selling a solution on the open market where users are
downloading, upgrading, etc. independent of the developer's support, one
file makes a lot of sense. For custom solutions that may grow
substantially in size and are easily set up for external authentication,
separate data files, with one or several tables in each, and one or more
interface files, makes much more sense.

Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting

In article <1gwe4k8.jrobfq9ers14N%lynn (AT) NOT-semiotics (DOT) com>,
lynn (AT) NOT-semiotics (DOT) com (Lynn allen) wrote:

My response here was in comparison to different files having different
data tables, in the manner of FMP 6 and earlier. That was the question
that the OP asked. I was not arguing against the data separation model.
In fact I speak of the data separation model favorably later in my
response. The OP probably had not even thought of the data separation
model.

Sorry my response was not clear to those who had not read the OP's
question.

Bill

--
To send e-mail, remove .invalid

Thanks a lot to you all for your replies. I'm certainly not as "heavy
duty" as some of you guys but I've learned a lot from what you've been
saying.

Thanks again,

Hugh