new to FM7: tables? what the hell are they?....

#11

I understand the whole "multiple tables" in one DB thing. What about if
you have a field in your "main" DB that a sequential serial number is
automatically entered when a new record is created. Can you have another
related table within that DB creating records without making that field 's
serial number increase?

thanks,

Meryl
gullings (AT) socket (DOT) net

#12

In article <118iv7oq2bqv1b4 (AT) corp (DOT) supernews.com>, gullings (AT) socket (DOT) net
says...

Quote:

I understand the whole "multiple tables" in one DB thing. What about if
you have a field in your "main" DB

There is no "main" table. All tables are equal.

Quote:

that a sequential serial number is
automatically entered when a new record is created. Can you have another
related table within that DB creating records without making that field 's
serial number increase?

Yes!

Tables in the same file, tables in a different file... same difference.

#13

lynn (AT) NOT-semiotics (DOT) com (Lynn allen) hat geschrieben:

Quote:

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.
snip
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.

I tried this and I ran into a problem when I wanted to switch from one
interface to another using the "go to related record" script step. If
I'm not mistaken, this is not possible as the relation can't lead to
an interface, since the record is in the data file. All I can do is
choose a layout in the same interface file.

There are three ways to go, at least that's what I came up with until
now:

a) Stay in the UI file and add the required layout. In the end, there
will be just one interface file for all the needs of a certain user or
division. This sucks because I'll have the same layouts on different
places, I will need to rewrite scripts attached to buttons after I
copied a layout, and the UI files will have a large number of layouts
and scripts.

b) write a script in both interface files to pass the record ID via a
global field and search for the related record in the other UI file
using find mode.

c) give up on data separation and work the way I did in FMP 6.

I'll try b). What is your solution?
--
http://clk.ch

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

new to FM7: tables? what the hell are they?....

comp.databases.filemaker comp.databases.filemaker

Re: new to FM7: tables? what the hell are they?....another question - 05-17-2005 , 12:10 AM

Re: new to FM7: tables? what the hell are they?....another question - 05-17-2005 , 04:36 AM

Re: new to FM7: tables? what the hell are they?.... - 06-15-2005 , 02:38 AM