 | |
#1
 
| |||
| |||
|
tables in FM7 -
09-13-2005
, 02:37 PM
#2
| |||
| |||
|
|
pretty new to FM7, so I am trying to understand how everything works and clean up a couple of DBs that we have converted. Is it possible to create a new table and move fields to that table to organize the information differently/more functionally as FM7 offers? I had created a database in version 5 that has now been converted to 7. In order to organize fields, I created 'false' fields as dividers to identify field groupings. I believe that separate tables for the field groupings is more graceful. Thoughts/Suggestions? |
If you mean different groups of field definitions, I don't see the
point. The database designer sees the field definitions, and then only
when there is a need to add, delete or change field definitions. Users
do not see the field definitions in the ordinary course of using the
database. The designer can cause the fields to be listed in various
different orders in the field definition window to make his job easier.
This has no effect on the user of the database.
If you mean putting different fields on different layouts, that can all
be done with a single table. You just make new layouts that hold the
fields of interest, in a functionally logical way from the standpoint of
the user. This is common practice for various purposes. You could do
this in earlier versions of FileMaker, at least as far back as FMP 3 and
maybe earlier.
As for deciding what tables to have, think about what entities you want
to record data about. An entity might be a person, or an invoice, or a
product, or a letter. Then create a table for each kind of entity, then
define fields in that table to hold the various kinds of data about that
entity.
As a simple example, if the entity is a person, you might define a table
named Person, then have fields for first and last name, address, city,
state, zip code, phone number, etc.
You would normally put in the same table fields for data that has a
one-to-one relationship to the main entity of that table. For example,
there is a one-to-one relationship between a person and his name, so
those fields would go in one table.
If there is a one-to-many relationship between a kind of entity and data
about it, then you might want to have multiple related tables. For
example, a person might have several phone numbers. You might want to
have one table for persons and another table for phone numbers, with a
relationship between them, so that all the phone numbers for one person
are related to that person.
This applies also to a many-to-many situation. An example would be
Students and Classes. Each student can take many classes, and each class
can have many students. You would have a table for Students, a table for
Classes, and a table for Class Registration. Students and Classes would
be related to Registration. The Student table would have the data unique
to the student -- name, address, birthdate, etc. The Classes table would
have the data unique to each class -- Title, location, day, time, etc.
The registration table would have a record for each assignment of a
student to a class.
Hope this helps.
Bill
--
For email, remove invalid.
#3
| |||
| |||
|
|
In article <1126640256.128198.58320 (AT) o13g2000cwo (DOT) googlegroups.com>, "Steven Bitaxi" <sbitaxi (AT) yorku (DOT) ca> wrote: pretty new to FM7, so I am trying to understand how everything works and clean up a couple of DBs that we have converted. Is it possible to create a new table and move fields to that table to organize the information differently/more functionally as FM7 offers? I had created a database in version 5 that has now been converted to 7. In order to organize fields, I created 'false' fields as dividers to identify field groupings. I believe that separate tables for the field groupings is more graceful. Thoughts/Suggestions? Not sure what you mean by field groupings or field organization. If you mean different groups of field definitions, I don't see the point. The database designer sees the field definitions, and then only when there is a need to add, delete or change field definitions. Users do not see the field definitions in the ordinary course of using the database. The designer can cause the fields to be listed in various different orders in the field definition window to make his job easier. This has no effect on the user of the database. If you mean putting different fields on different layouts, that can all be done with a single table. You just make new layouts that hold the fields of interest, in a functionally logical way from the standpoint of the user. This is common practice for various purposes. You could do this in earlier versions of FileMaker, at least as far back as FMP 3 and maybe earlier. As for deciding what tables to have, think about what entities you want to record data about. An entity might be a person, or an invoice, or a product, or a letter. Then create a table for each kind of entity, then define fields in that table to hold the various kinds of data about that entity. As a simple example, if the entity is a person, you might define a table named Person, then have fields for first and last name, address, city, state, zip code, phone number, etc. You would normally put in the same table fields for data that has a one-to-one relationship to the main entity of that table. For example, there is a one-to-one relationship between a person and his name, so those fields would go in one table. If there is a one-to-many relationship between a kind of entity and data about it, then you might want to have multiple related tables. For example, a person might have several phone numbers. You might want to have one table for persons and another table for phone numbers, with a relationship between them, so that all the phone numbers for one person are related to that person. This applies also to a many-to-many situation. An example would be Students and Classes. Each student can take many classes, and each class can have many students. You would have a table for Students, a table for Classes, and a table for Class Registration. Students and Classes would be related to Registration. The Student table would have the data unique to the student -- name, address, birthdate, etc. The Classes table would have the data unique to each class -- Title, location, day, time, etc. The registration table would have a record for each assignment of a student to a class. Hope this helps. Bill -- For email, remove invalid. |
Hi Bill,
It does help, though it doesn't quite answer the question I had. My own
fault, I was not that clear in my message. The information that you
provided helps immensely with understanding the structure inherent in
FM7.
Older versions of Filemaker did not allow multiple tables in one file.
Essentially, to have a new table, we created a new database with that
data and related one to the other. Contact.FP5 to Phone.FP5 (One to
Many respectively)
FM7 now allows us to have these tables in one file, which is great. Now
I want to take advantage of this without rebuilding the database from
the ground up.
I would like to transfer fields from one file into a different file.
Fields from Phone.FP7 into a Phone Table in Contact.FP7
Is there a way to do that without creating the fields manually and
importing the data? Yes phone is easy, and what I really want to do is
with a larger data set, but this works as an example.
This is also true within ONE file. Contact.FP7 currently has several
fields that I would prefer to have in a separate table in Contact.FP7
just to organize them by the function they perform in the DB. I created
dummy fields named "- Contact Info -" which organizes all the fields
related to the contact, "- DB Administration -" which is separates the
record ID, created/modified date fields. I would love to be able to
move them to a separate table without doing any really aggressive
restructuring (like building a new DB).
Is this more clear? Essentially, I am the developer. Self-taught and
supported by great services like this group.
Your experience is appreciated.
S
I am the developer, a self-taught one admittedly
#4
| |||
| |||
|
|
I would like to transfer fields from one file into a different file. Fields from Phone.FP7 into a Phone Table in Contact.FP7 Is there a way to do that without creating the fields manually and importing the data? Yes phone is easy, and what I really want to do is with a larger data set, but this works as an example. |
of tables from one file to another by copying/pasting. You can also
copy/paste scripts or script steps.
However, this does not transfer data, only structure. You'll still have
to do a onetime import to get the data in. You'll also have to rebuild
your relationships in the new graph. Those do not transfer, being so
different in structure.
In FM7, your option is FMRobot, a product of NewMillennium
(www.nmci.com) but it's far cheaper to upgrade to FM8A.
FM8 may also have the copy/paste of tables, I haven't installed mine,
only the Advanced.
Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting
#5
| |||
| |||
|
|
Steven Bitaxi <sbitaxi (AT) yorku (DOT) ca> wrote: I would like to transfer fields from one file into a different file. Fields from Phone.FP7 into a Phone Table in Contact.FP7 Is there a way to do that without creating the fields manually and importing the data? Yes phone is easy, and what I really want to do is with a larger data set, but this works as an example. In FM8 Advanced you can do such a thing, moving complete tables or parts of tables from one file to another by copying/pasting. You can also copy/paste scripts or script steps. However, this does not transfer data, only structure. You'll still have to do a onetime import to get the data in. You'll also have to rebuild your relationships in the new graph. Those do not transfer, being so different in structure. In FM7, your option is FMRobot, a product of NewMillennium (www.nmci.com) but it's far cheaper to upgrade to FM8A. FM8 may also have the copy/paste of tables, I haven't installed mine, only the Advanced. |
Howard Schlossberg (818) 883-2846
FM Pro Solutions Los Angeles, California
FileMaker 7 Certified Developer
Associate Member, FileMaker Solutions Alliance
#6
| |||
| |||
|
|
In FM8 (not sure if this is only in FM Advanced or if it is also available in the standard FM Pro version), you also have the option *while importing data* of importing into a new table, which is an option at the very bottom of the 'target' selection drop-down. |
have had the opportunity to use the cute new calendar drop down. At
last!!
Lynn Allen
--
Allen & Allen Semiotics www.semiotics.com
FSA Associate Filemaker Design & Consulting
#7
| |||
| |||
|
|
Bill wrote: In article <1126640256.128198.58320 (AT) o13g2000cwo (DOT) googlegroups.com>, "Steven Bitaxi" <sbitaxi (AT) yorku (DOT) ca> wrote: pretty new to FM7, so I am trying to understand how everything works and clean up a couple of DBs that we have converted. Is it possible to create a new table and move fields to that table to organize the information differently/more functionally as FM7 offers? I had created a database in version 5 that has now been converted to 7. In order to organize fields, I created 'false' fields as dividers to identify field groupings. I believe that separate tables for the field groupings is more graceful. Thoughts/Suggestions? Not sure what you mean by field groupings or field organization. If you mean different groups of field definitions, I don't see the point. The database designer sees the field definitions, and then only when there is a need to add, delete or change field definitions. Users do not see the field definitions in the ordinary course of using the database. The designer can cause the fields to be listed in various different orders in the field definition window to make his job easier. This has no effect on the user of the database. If you mean putting different fields on different layouts, that can all be done with a single table. You just make new layouts that hold the fields of interest, in a functionally logical way from the standpoint of the user. This is common practice for various purposes. You could do this in earlier versions of FileMaker, at least as far back as FMP 3 and maybe earlier. As for deciding what tables to have, think about what entities you want to record data about. An entity might be a person, or an invoice, or a product, or a letter. Then create a table for each kind of entity, then define fields in that table to hold the various kinds of data about that entity. As a simple example, if the entity is a person, you might define a table named Person, then have fields for first and last name, address, city, state, zip code, phone number, etc. You would normally put in the same table fields for data that has a one-to-one relationship to the main entity of that table. For example, there is a one-to-one relationship between a person and his name, so those fields would go in one table. If there is a one-to-many relationship between a kind of entity and data about it, then you might want to have multiple related tables. For example, a person might have several phone numbers. You might want to have one table for persons and another table for phone numbers, with a relationship between them, so that all the phone numbers for one person are related to that person. This applies also to a many-to-many situation. An example would be Students and Classes. Each student can take many classes, and each class can have many students. You would have a table for Students, a table for Classes, and a table for Class Registration. Students and Classes would be related to Registration. The Student table would have the data unique to the student -- name, address, birthdate, etc. The Classes table would have the data unique to each class -- Title, location, day, time, etc. The registration table would have a record for each assignment of a student to a class. Hope this helps. Bill -- For email, remove invalid. Hi Bill, It does help, though it doesn't quite answer the question I had. My own fault, I was not that clear in my message. The information that you provided helps immensely with understanding the structure inherent in FM7. Older versions of Filemaker did not allow multiple tables in one file. Essentially, to have a new table, we created a new database with that data and related one to the other. Contact.FP5 to Phone.FP5 (One to Many respectively) FM7 now allows us to have these tables in one file, which is great. Now I want to take advantage of this without rebuilding the database from the ground up. I would like to transfer fields from one file into a different file. Fields from Phone.FP7 into a Phone Table in Contact.FP7 Is there a way to do that without creating the fields manually and importing the data? Yes phone is easy, and what I really want to do is with a larger data set, but this works as an example. This is also true within ONE file. Contact.FP7 currently has several fields that I would prefer to have in a separate table in Contact.FP7 just to organize them by the function they perform in the DB. I created dummy fields named "- Contact Info -" which organizes all the fields related to the contact, "- DB Administration -" which is separates the record ID, created/modified date fields. I would love to be able to move them to a separate table without doing any really aggressive restructuring (like building a new DB). Is this more clear? Essentially, I am the developer. Self-taught and supported by great services like this group. Your experience is appreciated. S I am the developer, a self-taught one admittedly |
enable you to import table structure from one file to another. I'm
waiting for my copy of FM 8 Advanced right now. One reason I ordered it
is to be able to do just that, as well as to build stand-alone Runtime
solutions.
If you create a solution using FM 8 Advanced, it will be usable by FMP
7, provided you do not include features in the solution that are FM 8
only.
You can get an upgrade copy of FM 8 Advanced based on upgrading from FMP
7. The upgrade price is lower than the full price.
Without FM 8 Advanced, I think you have to build the single-file
solution by hand.
Bill Collins
--
For email, remove invalid.
#8
| |||
| |||
|
|
I would like to transfer fields from one file into a different file. Fields from Phone.FP7 into a Phone Table in Contact.FP7 Is there a way to do that without creating the fields manually and importing the data? |
them into another file. If your fields are mostly data entry fields
this will be useful, however you will need to update fields referencing
table occurrences. This may seem easy for calc fields but what about
lookups, auto-enters, validations etc. this is still quite a bit of
work.
Quote:
|
This is also true within ONE file. Contact.FP7 currently has several fields that I would prefer to have in a separate table in Contact.FP7 just to organize them by the function they perform in the DB. I created dummy fields named "- Contact Info -" which organizes all the fields related to the contact, "- DB Administration -" which is separates the record ID, created/modified date fields. I would love to be able to move them to a separate table without doing any really aggressive restructuring (like building a new DB). |
date etc. out of the CONTACT table since these must remain where they
are to calculate properly.
Having said this it almost sounds like there is no real reason to
upgrade to FM7. I find the real power of FM7 in the ability to link
table occurrences through multiple levels eg.
Client - Job - Invoice Item - Invoice - Payments
Aside from the normal data entry fields in these files, the only fields
added to job are the "ID Client", in Inv Item the "ID Job" and "ID
Inv".
Now being at the Invoice level you can pull the client name.
Quote:
|
From Client you can sum up the payments made and determine how much that client still owes on all invoices. |
calculation was only 1 table away.
Therefore to really take advantage of FM7 / 8 you have to rewrite from
scratch. Copying the data entry fields is useful but you'll probably
end up breaking them into multiple tables just because you now can.
#9
| |||
| |||
|
|
From what I have seen of 8, it would have been nice if the office had upgraded a little further. |
been.
S
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.