Does anybody know if it is possible to convert a table occurrence created by a
relationship to an actual table entity where it can be seen from the table's
tab within the Define Database screen?
Thanks.
--
POST BY: lark with PHP News Reader ;o)
On Oct 22, 7:47 am, lark
> Does anybody know if it is possible to convert a table occurrence created by a
> relationship to an actual table entity where it can be seen from the table's
> tab within the Define Database screen?
>
> Thanks.
> --
> POST BY: lark with PHP News Reader ;o)
You question doesn't make a whole lot of sense. You can't create a
table occurence in the relationship graph that doesn't already exist
as a table in the Define Database tab.
== Quote from Grip (grip@cybermesa.com)'s article
> On Oct 22, 7:47 am, lark
> > Does anybody know if it is possible to convert a table occurrence created by a
> > relationship to an actual table entity where it can be seen from the table's
> > tab within the Define Database screen?
> >
> > Thanks.
> > --
> > POST BY: lark with PHP News Reader ;o)
> You question doesn't make a whole lot of sense. You can't create a
> table occurence in the relationship graph that doesn't already exist
> as a table in the Define Database tab.
let me put it this way:
i have a table
i have several relationships that have created several table occurences in the
relationships tab. say for example i have table employee and then i also have
created a table occurance of this table in the relationships tab that is called
"employee of the month".
my question is if i can convert (somehow, i don't think it is) this occurance of
the table employee which is called "employee of the month" to a real table where i
can see it in the table tab within the Define Database screen?
does it makes sense?
--
POST BY: lark with PHP News Reader ;o)
On 2007-10-22 08:49:19 -0700, lark
> my question is if i can convert (somehow, i don't think it is) this
> occurance of
> the table employee which is called "employee of the month" to a real
> table where i
> can see it in the table tab within the Define Database screen?
You can copy and paste entire tables within the Table tab in Define
Databases. This is the only way to make a new table from an existing
table.
Confusing Table Occurances with Tables, however, will get you in a
world of hurt. ;)
Every TO on the graph, including the base occurance, is only a
representation of the table. It's not a "real" table. Those are seen
only on the Tables tab.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
In article <471cce14@news.bnb-lp.com>,
Lynn Allen
> On 2007-10-22 08:49:19 -0700, lark
>
> > my question is if i can convert (somehow, i don't think it is) this
> > occurance of
> > the table employee which is called "employee of the month" to a real
> > table where i
> > can see it in the table tab within the Define Database screen?
>
> You can copy and paste entire tables within the Table tab in Define
> Databases. This is the only way to make a new table from an existing
> table.
>
> Confusing Table Occurances with Tables, however, will get you in a
> world of hurt. ;)
>
> Every TO on the graph, including the base occurance, is only a
> representation of the table. It's not a "real" table. Those are seen
> only on the Tables tab.
To add to what Lynn said:
The only time what you are talking about MIGHT make sense is if the
table that is represented by the TO exists in a different FILE, and for
some reason you want to bring that TABLE into the local FILE and use it
instead of the table in the remote FILE.
== Quote from Bill (bbcollins@earthlink.net)'s article
> In article <471cce14@news.bnb-lp.com>,
> Lynn Allen
> > On 2007-10-22 08:49:19 -0700, lark
> >
> > > my question is if i can convert (somehow, i don't think it is) this
> > > occurance of
> > > the table employee which is called "employee of the month" to a real
> > > table where i
> > > can see it in the table tab within the Define Database screen?
> >
> > You can copy and paste entire tables within the Table tab in Define
> > Databases. This is the only way to make a new table from an existing
> > table.
> >
> > Confusing Table Occurances with Tables, however, will get you in a
> > world of hurt. ;)
> >
> > Every TO on the graph, including the base occurance, is only a
> > representation of the table. It's not a "real" table. Those are seen
> > only on the Tables tab.
> To add to what Lynn said:
> The only time what you are talking about MIGHT make sense is if the
> table that is represented by the TO exists in a different FILE, and for
> some reason you want to bring that TABLE into the local FILE and use it
> instead of the table in the remote FILE.
i understand the limitations regarding TO's. i understand how they are represented
as well. i have been using them successfully for a long time now; however, here's
a situation where i do want to convert a TO to a "real" table: over time some of
the global fields requirements for some of my records has changed; so, in order to
be able to accommodate this new requirement, i need to either add new fields to
the table or separate the TO from its original real table.
my understanding is that filemaker doesn't allow this at all; however, i was
wondering if somebody had found a back door way of doing this. there is a lot of
things that can be done in uncoventional ways.
does this make sense?
--
POST BY: lark with PHP News Reader ;o)
In article
lark
> == Quote from Bill (bbcollins@earthlink.net)'s article
> > In article <471cce14@news.bnb-lp.com>,
> > Lynn Allen
> > > On 2007-10-22 08:49:19 -0700, lark
> > >
> > > > my question is if i can convert (somehow, i don't think it is) this
> > > > occurance of
> > > > the table employee which is called "employee of the month" to a real
> > > > table where i
> > > > can see it in the table tab within the Define Database screen?
> > >
> > > You can copy and paste entire tables within the Table tab in Define
> > > Databases. This is the only way to make a new table from an existing
> > > table.
> > >
> > > Confusing Table Occurances with Tables, however, will get you in a
> > > world of hurt. ;)
> > >
> > > Every TO on the graph, including the base occurance, is only a
> > > representation of the table. It's not a "real" table. Those are seen
> > > only on the Tables tab.
> > To add to what Lynn said:
> > The only time what you are talking about MIGHT make sense is if the
> > table that is represented by the TO exists in a different FILE, and for
> > some reason you want to bring that TABLE into the local FILE and use it
> > instead of the table in the remote FILE.
>
> i understand the limitations regarding TO's. i understand how they are
> represented
> as well. i have been using them successfully for a long time now; however,
> here's
> a situation where i do want to convert a TO to a "real" table: over time some
> of
> the global fields requirements for some of my records has changed; so, in
> order to
> be able to accommodate this new requirement, i need to either add new fields
> to
> the table or separate the TO from its original real table.
>
> my understanding is that filemaker doesn't allow this at all; however, i was
> wondering if somebody had found a back door way of doing this. there is a lot
> of
> things that can be done in uncoventional ways.
>
> does this make sense?
> --
> POST BY: lark with PHP News Reader ;o)
Where is the table itself located? Can you not modify the table itself
to accomplish what you want?
== Quote from Bill (bbcollins@earthlink.net)'s article
> In article
> lark
> > == Quote from Bill (bbcollins@earthlink.net)'s article
> > > In article <471cce14@news.bnb-lp.com>,
> > > Lynn Allen
> > > > On 2007-10-22 08:49:19 -0700, lark
> > > >
> > > > > my question is if i can convert (somehow, i don't think it is) this
> > > > > occurance of
> > > > > the table employee which is called "employee of the month" to a real
> > > > > table where i
> > > > > can see it in the table tab within the Define Database screen?
> > > >
> > > > You can copy and paste entire tables within the Table tab in Define
> > > > Databases. This is the only way to make a new table from an existing
> > > > table.
> > > >
> > > > Confusing Table Occurances with Tables, however, will get you in a
> > > > world of hurt. ;)
> > > >
> > > > Every TO on the graph, including the base occurance, is only a
> > > > representation of the table. It's not a "real" table. Those are seen
> > > > only on the Tables tab.
> > > To add to what Lynn said:
> > > The only time what you are talking about MIGHT make sense is if the
> > > table that is represented by the TO exists in a different FILE, and for
> > > some reason you want to bring that TABLE into the local FILE and use it
> > > instead of the table in the remote FILE.
> >
> > i understand the limitations regarding TO's. i understand how they are
> > represented
> > as well. i have been using them successfully for a long time now; however,
> > here's
> > a situation where i do want to convert a TO to a "real" table: over time some
> > of
> > the global fields requirements for some of my records has changed; so, in
> > order to
> > be able to accommodate this new requirement, i need to either add new fields
> > to
> > the table or separate the TO from its original real table.
> >
> > my understanding is that filemaker doesn't allow this at all; however, i was
> > wondering if somebody had found a back door way of doing this. there is a lot
> > of
> > things that can be done in uncoventional ways.
> >
> > does this make sense?
> > --
> > POST BY: lark with PHP News Reader ;o)
> Where is the table itself located? Can you not modify the table itself
> to accomplish what you want?
the table itself is in the same file, i must have forgotten to mention that. and
yes, i can potentially modify the table to accomplish the same thing but that
would require changing a lot of layout which i am trying to avoid. i think i am
going to try to create real tables (NOT TOs) based on TOs and then update the
globals and then just use clip manager to move my fields from the TO fields to the
newly created fields (which should be the same).
--
POST BY: lark with PHP News Reader ;o)
On 2007-10-22 12:44:45 -0700, lark
>> Where is the table itself located? Can you not modify the table itself
>> to accomplish what you want?
>
> the table itself is in the same file, i must have forgotten to mention
> that. and
> yes, i can potentially modify the table to accomplish the same thing but that
> would require changing a lot of layout which i am trying to avoid. i think i am
> going to try to create real tables (NOT TOs) based on TOs and then update the
> globals and then just use clip manager to move my fields from the TO
> fields to the
> newly created fields (which should be the same).
Let us know how that works out, because it sounds like absolute
nonsense from here.
Either you want to make a new table, or you want to modify an existing
table. This is done through the Tables tab, or the Fields tab. In no
case does the graph come into it. If the fields are already there in a
TO, they are already there in a table. WHICH table becomes the question.
You can also just copy/paste fields from table to table directly in
FileMaker, you know. No need to use clip manager.
Once the table is created or modified, that's the time to add the TO to
the graph and hook it up to whatever layouts you want to. If you change
the TO of a layout, then you'll have to respecify all the fields on it
to point to the new TO.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
== Quote from Lynn Allen (lynn@NOT-semiotics.com)'s article
> On 2007-10-22 12:44:45 -0700, lark
> >> Where is the table itself located? Can you not modify the table itself
> >> to accomplish what you want?
> >
> > the table itself is in the same file, i must have forgotten to mention
> > that. and
> > yes, i can potentially modify the table to accomplish the same thing but that
> > would require changing a lot of layout which i am trying to avoid. i think i am
> > going to try to create real tables (NOT TOs) based on TOs and then update the
> > globals and then just use clip manager to move my fields from the TO
> > fields to the
> > newly created fields (which should be the same).
> Let us know how that works out, because it sounds like absolute
> nonsense from here.
> Either you want to make a new table, or you want to modify an existing
> table. This is done through the Tables tab, or the Fields tab. In no
> case does the graph come into it. If the fields are already there in a
> TO, they are already there in a table. WHICH table becomes the question.
> You can also just copy/paste fields from table to table directly in
> FileMaker, you know. No need to use clip manager.
> Once the table is created or modified, that's the time to add the TO to
> the graph and hook it up to whatever layouts you want to. If you change
> the TO of a layout, then you'll have to respecify all the fields on it
> to point to the new TO.
I converted my first TO to a real table that actually shows up on the left hand
side of the table tab. It wasn't very hard at all. What I did is this:
1-renamed the TO in question (the one i wanted to convert) in the relationships tab.
2-copied and pasted the table that the TO was based on and named it exactly as the
TO in 1
3-done with define/database screen
4-opened up the layout that the TO was being used in. all the fiels were
referencing the renamed table name mentioned in 1
5-select all and copied the layout to clip manager
6-changed all references of the TO to the table created in 2
7-using clip manager copied and pasted the new layout back into file manager
8-shazzam, all the fields had successfully converted to the new table.
this is really working out.
thanks everybody for input.
--
POST BY: lark with PHP News Reader ;o)
On Oct 22, 2:09 pm, lark
> == Quote from Lynn Allen (l...@NOT-semiotics.com)'s article
>
>
>
> > On 2007-10-22 12:44:45 -0700, lark
> > >> Where is the table itself located? Can you not modify the table itself
> > >> to accomplish what you want?
>
> > > the table itself is in the same file, i must have forgotten to mention
> > > that. and
> > > yes, i can potentially modify the table to accomplish the same thing but that
> > > would require changing a lot of layout which i am trying to avoid. i think i am
> > > going to try to create real tables (NOT TOs) based on TOs and then update the
> > > globals and then just use clip manager to move my fields from the TO
> > > fields to the
> > > newly created fields (which should be the same).
> > Let us know how that works out, because it sounds like absolute
> > nonsense from here.
> > Either you want to make a new table, or you want to modify an existing
> > table. This is done through the Tables tab, or the Fields tab. In no
> > case does the graph come into it. If the fields are already there in a
> > TO, they are already there in a table. WHICH table becomes the question.
> > You can also just copy/paste fields from table to table directly in
> > FileMaker, you know. No need to use clip manager.
> > Once the table is created or modified, that's the time to add the TO to
> > the graph and hook it up to whatever layouts you want to. If you change
> > the TO of a layout, then you'll have to respecify all the fields on it
> > to point to the new TO.
>
> I converted my first TO to a real table that actually shows up on the left hand
> side of the table tab. It wasn't very hard at all. What I did is this:
>
> 1-renamed the TO in question (the one i wanted to convert) in the relationships tab.
> 2-copied and pasted the table that the TO was based on and named it exactly as the
> TO in 1
> 3-done with define/database screen
> 4-opened up the layout that the TO was being used in. all the fiels were
> referencing the renamed table name mentioned in 1
> 5-select all and copied the layout to clip manager
> 6-changed all references of the TO to the table created in 2
> 7-using clip manager copied and pasted the new layout back into file manager
> 8-shazzam, all the fields had successfully converted to the new table.
>
> this is really working out.
>
> thanks everybody for input.
> --
> POST BY: lark with PHP News Reader ;o)
Glad it worked out. I've never used Clip Manager, but may start
looking into it as I need to convert some layouts to a different TO.
In my case, I'm combining tables rather than separating them. Don't
know how analogous your reference to an "Employee of the Month" is to
your actual situation, but it's possible a database is better off
without the extra tables if they're duplicating a lot of the same
fields.
In article <%j8Ti.56$%Z2.13@nlpi068.nbdc.sbc.com>,
lark
> == Quote from Lynn Allen (lynn@NOT-semiotics.com)'s article
> > On 2007-10-22 12:44:45 -0700, lark
> > >> Where is the table itself located? Can you not modify the table itself
> > >> to accomplish what you want?
> > >
> > > the table itself is in the same file, i must have forgotten to mention
> > > that. and
> > > yes, i can potentially modify the table to accomplish the same thing but
> > > that
> > > would require changing a lot of layout which i am trying to avoid. i
> > > think i am
> > > going to try to create real tables (NOT TOs) based on TOs and then update
> > > the
> > > globals and then just use clip manager to move my fields from the TO
> > > fields to the
> > > newly created fields (which should be the same).
> > Let us know how that works out, because it sounds like absolute
> > nonsense from here.
> > Either you want to make a new table, or you want to modify an existing
> > table. This is done through the Tables tab, or the Fields tab. In no
> > case does the graph come into it. If the fields are already there in a
> > TO, they are already there in a table. WHICH table becomes the question.
> > You can also just copy/paste fields from table to table directly in
> > FileMaker, you know. No need to use clip manager.
> > Once the table is created or modified, that's the time to add the TO to
> > the graph and hook it up to whatever layouts you want to. If you change
> > the TO of a layout, then you'll have to respecify all the fields on it
> > to point to the new TO.
>
>
> I converted my first TO to a real table that actually shows up on the left
> hand
> side of the table tab. It wasn't very hard at all. What I did is this:
>
> 1-renamed the TO in question (the one i wanted to convert) in the
> relationships tab.
> 2-copied and pasted the table that the TO was based on and named it exactly
> as the
> TO in 1
> 3-done with define/database screen
> 4-opened up the layout that the TO was being used in. all the fiels were
> referencing the renamed table name mentioned in 1
> 5-select all and copied the layout to clip manager
> 6-changed all references of the TO to the table created in 2
> 7-using clip manager copied and pasted the new layout back into file manager
> 8-shazzam, all the fields had successfully converted to the new table.
>
> this is really working out.
>
> thanks everybody for input.
> --
> POST BY: lark with PHP News Reader ;o)
The mechanics of what you did are straightforward. The reason for doing
it still is most unclear.
Seems like you now have the same table structure in two different
tables, and will end up with duplication of the data between the two
different tables. This is a serious error in database design, because
you then have two separate sets of the same data to maintain, which is
very difficult, time-consuming and prone to error. As time goes on, the
two sets of dtd will progressively differ from each other in ways that
are hard to detect, and you won't know which is right. It violates a
very basic reason for using a relational database in the first place.
The basic reason for using a relational database is to enter and store
data in one place, and then then use the same data in many places.
You seem to have violated this basic purpose by creating two separate
tables to hold the same kind of data.
You said earlier that you did not want to modify the original table
because that would make you have to change the existing layouts that are
based on that table. Nonsense. Nothing forces you to change existing
layouts.
From all you have told us, it seems to me that you have done a very
silly and pointless thing.
== Quote from Bill (bbcollins@earthlink.net)'s article
> In article <%j8Ti.56$%Z2.13@nlpi068.nbdc.sbc.com>,
> lark
> > == Quote from Lynn Allen (lynn@NOT-semiotics.com)'s article
> > > On 2007-10-22 12:44:45 -0700, lark
> > > >> Where is the table itself located? Can you not modify the table itself
> > > >> to accomplish what you want?
> > > >
> > > > the table itself is in the same file, i must have forgotten to mention
> > > > that. and
> > > > yes, i can potentially modify the table to accomplish the same thing but
> > > > that
> > > > would require changing a lot of layout which i am trying to avoid. i
> > > > think i am
> > > > going to try to create real tables (NOT TOs) based on TOs and then update
> > > > the
> > > > globals and then just use clip manager to move my fields from the TO
> > > > fields to the
> > > > newly created fields (which should be the same).
> > > Let us know how that works out, because it sounds like absolute
> > > nonsense from here.
> > > Either you want to make a new table, or you want to modify an existing
> > > table. This is done through the Tables tab, or the Fields tab. In no
> > > case does the graph come into it. If the fields are already there in a
> > > TO, they are already there in a table. WHICH table becomes the question.
> > > You can also just copy/paste fields from table to table directly in
> > > FileMaker, you know. No need to use clip manager.
> > > Once the table is created or modified, that's the time to add the TO to
> > > the graph and hook it up to whatever layouts you want to. If you change
> > > the TO of a layout, then you'll have to respecify all the fields on it
> > > to point to the new TO.
> >
> >
> > I converted my first TO to a real table that actually shows up on the left
> > hand
> > side of the table tab. It wasn't very hard at all. What I did is this:
> >
> > 1-renamed the TO in question (the one i wanted to convert) in the
> > relationships tab.
> > 2-copied and pasted the table that the TO was based on and named it exactly
> > as the
> > TO in 1
> > 3-done with define/database screen
> > 4-opened up the layout that the TO was being used in. all the fiels were
> > referencing the renamed table name mentioned in 1
> > 5-select all and copied the layout to clip manager
> > 6-changed all references of the TO to the table created in 2
> > 7-using clip manager copied and pasted the new layout back into file manager
> > 8-shazzam, all the fields had successfully converted to the new table.
> >
> > this is really working out.
> >
> > thanks everybody for input.
> > --
> > POST BY: lark with PHP News Reader ;o)
> The mechanics of what you did are straightforward. The reason for doing
> it still is most unclear.
> Seems like you now have the same table structure in two different
> tables, and will end up with duplication of the data between the two
> different tables. This is a serious error in database design, because
> you then have two separate sets of the same data to maintain, which is
> very difficult, time-consuming and prone to error. As time goes on, the
> two sets of dtd will progressively differ from each other in ways that
> are hard to detect, and you won't know which is right. It violates a
> very basic reason for using a relational database in the first place.
> The basic reason for using a relational database is to enter and store
> data in one place, and then then use the same data in many places.
> You seem to have violated this basic purpose by creating two separate
> tables to hold the same kind of data.
> You said earlier that you did not want to modify the original table
> because that would make you have to change the existing layouts that are
> based on that table. Nonsense. Nothing forces you to change existing
> layouts.
> From all you have told us, it seems to me that you have done a very
> silly and pointless thing.
there is no reason to be impolite anywhere.
however, as i'd mentioned before my purpose in separating was so that i can
maintain two different sets of globals one for each group of people. i suggest
going back and reading all the posts before taking a dive in the middle of
everything.
besides all of this and what is most important is that i am satisfied with the
help i received in this. but i have to say, your editorial is very reflective.
--
POST BY: lark with PHP News Reader ;o)
On 2007-10-23 12:19:13 -0700, lark
> however, as i'd mentioned before my purpose in separating was so that i can
> maintain two different sets of globals one for each group of people. i suggest
> going back and reading all the posts before taking a dive in the middle of
> everything.
But there's no need to do any such thing. All people in one table. Mark
one group with a field that says "Employee of Month" or better yet is a
number field with a value list of "1", make it a check box. Name it
EmpOfMonthFlag or some such. Mark only those records to which this
status applies.
Now put both different types of globals in the single table. Name them
appropriately. Why is that so hard to do? Making separate tables to
hold slightly different sets of globals is really the wrong data
structure. It would be my LAST consideration in how to manage globals.
For that matter, most of my useful globals live in a separate table
anyway, since one no longer needs relationships to access them.
Variables take the place of many operative globals in running scripts,
too. The only current need for globals *in a data table* is to filter
portals or otherwise create a dynamic relationship link.
You're going to find, down the line, that creating this separate table
for this specific purpose is going to turn and bite you in your tender
bits. Someone is going to need to email or snail mail the entire group,
or have them in a combined report. Someone is going to need to have a
record in both groups. Then you are in the position of having to update
a single person's record in two tables. Then some user is going to want
to see the same child data from each of two different kinds of parent
records, and you're maintaining duplicate layouts, TOs and scripting to
allow them to look in two different places for the same data.
Bad data structure is bad data structure, said most politely. You asked
for what you thought you wanted, and didn't want to listen when we told
you what you needed instead.
Sometimes people who come to this newsgroup for advice need to listen
beyond the specific problem they THINK they need to solve.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
In article
lark
> == Quote from Bill (bbcollins@earthlink.net)'s article
> > In article <%j8Ti.56$%Z2.13@nlpi068.nbdc.sbc.com>,
> > lark
> > > == Quote from Lynn Allen (lynn@NOT-semiotics.com)'s article
> > > > On 2007-10-22 12:44:45 -0700, lark
> > > > >> Where is the table itself located? Can you not modify the table
> > > > >> itself
> > > > >> to accomplish what you want?
> > > > >
> > > > > the table itself is in the same file, i must have forgotten to
> > > > > mention
> > > > > that. and
> > > > > yes, i can potentially modify the table to accomplish the same thing
> > > > > but
> > > > > that
> > > > > would require changing a lot of layout which i am trying to avoid. i
> > > > > think i am
> > > > > going to try to create real tables (NOT TOs) based on TOs and then
> > > > > update
> > > > > the
> > > > > globals and then just use clip manager to move my fields from the TO
> > > > > fields to the
> > > > > newly created fields (which should be the same).
> > > > Let us know how that works out, because it sounds like absolute
> > > > nonsense from here.
> > > > Either you want to make a new table, or you want to modify an existing
> > > > table. This is done through the Tables tab, or the Fields tab. In no
> > > > case does the graph come into it. If the fields are already there in a
> > > > TO, they are already there in a table. WHICH table becomes the
> > > > question.
> > > > You can also just copy/paste fields from table to table directly in
> > > > FileMaker, you know. No need to use clip manager.
> > > > Once the table is created or modified, that's the time to add the TO to
> > > > the graph and hook it up to whatever layouts you want to. If you change
> > > > the TO of a layout, then you'll have to respecify all the fields on it
> > > > to point to the new TO.
> > >
> > >
> > > I converted my first TO to a real table that actually shows up on the
> > > left
> > > hand
> > > side of the table tab. It wasn't very hard at all. What I did is this:
> > >
> > > 1-renamed the TO in question (the one i wanted to convert) in the
> > > relationships tab.
> > > 2-copied and pasted the table that the TO was based on and named it
> > > exactly
> > > as the
> > > TO in 1
> > > 3-done with define/database screen
> > > 4-opened up the layout that the TO was being used in. all the fiels were
> > > referencing the renamed table name mentioned in 1
> > > 5-select all and copied the layout to clip manager
> > > 6-changed all references of the TO to the table created in 2
> > > 7-using clip manager copied and pasted the new layout back into file
> > > manager
> > > 8-shazzam, all the fields had successfully converted to the new table.
> > >
> > > this is really working out.
> > >
> > > thanks everybody for input.
> > > --
> > > POST BY: lark with PHP News Reader ;o)
> > The mechanics of what you did are straightforward. The reason for doing
> > it still is most unclear.
> > Seems like you now have the same table structure in two different
> > tables, and will end up with duplication of the data between the two
> > different tables. This is a serious error in database design, because
> > you then have two separate sets of the same data to maintain, which is
> > very difficult, time-consuming and prone to error. As time goes on, the
> > two sets of dtd will progressively differ from each other in ways that
> > are hard to detect, and you won't know which is right. It violates a
> > very basic reason for using a relational database in the first place.
> > The basic reason for using a relational database is to enter and store
> > data in one place, and then then use the same data in many places.
> > You seem to have violated this basic purpose by creating two separate
> > tables to hold the same kind of data.
> > You said earlier that you did not want to modify the original table
> > because that would make you have to change the existing layouts that are
> > based on that table. Nonsense. Nothing forces you to change existing
> > layouts.
> > From all you have told us, it seems to me that you have done a very
> > silly and pointless thing.
>
> there is no reason to be impolite anywhere.
>
> however, as i'd mentioned before my purpose in separating was so that i can
> maintain two different sets of globals one for each group of people. i
> suggest
> going back and reading all the posts before taking a dive in the middle of
> everything.
>
> besides all of this and what is most important is that i am satisfied with
> the
> help i received in this. but i have to say, your editorial is very
> reflective.
> --
> POST BY: lark with PHP News Reader ;o)
Lark: It is not a good idea to use two separate tables to distinguish
between two sets of people. All people should be in the same table.
My impression is that you do not really understand the basic concepts
behind tables and relationships in Filemaker. People on this group can
be very helpful if you ask for it, OR you should spend some time with
the manual or with a book.
>> however, as i'd mentioned before my purpose in separating was so that i
>> can
>> maintain two different sets of globals one for each group of people. i
>> suggest
>> going back and reading all the posts before taking a dive in the middle
>> of
>> everything.
>>
>> besides all of this and what is most important is that i am satisfied
>> with
>> the
>> help i received in this. but i have to say, your editorial is very
>> reflective.
>> --
>> POST BY: lark with PHP News Reader ;o)
>
> Lark: It is not a good idea to use two separate tables to distinguish
> between two sets of people. All people should be in the same table.
>
> My impression is that you do not really understand the basic concepts
> behind tables and relationships in Filemaker. People on this group can
> be very helpful if you ask for it, OR you should spend some time with
> the manual or with a book.
I have followed the thread. If Lark thinks he has solved it, let him. The
group has done enough to warn him and show him other ways. Perhaps his
solution will work for him, most probably he will find problems with it as
time goes on. Who knows.
Keep well, Ursus