Look-ups (as opposed to "looked-up")

Look-ups (as opposed to "looked-up")

Post by Jack Lo » Tue, 25 Mar 2003 23:59:57



First of all, apologies in advance for the "newbie" aspect of this
question, and thanks in advance for all replies anyone might
contemplate offering me.

I'm an experienced Oracle programmer who was recently asked (by a
small non-profit organization) to review and perhaps replace a
FileMaker DB with a better Filemaker or other DB. (I'll be doing this
on a pro-bono basis.) For reasons most readers here will instantly
understand, I did not contemplate replacing FileMaker with Oracle.
<smile> Deciding whether Access, 3D or some other PC program might be
a better choice is a bit more difficult, however, I ultimately figured
that redesigning the existing FM database makes the most sense if I
can manage it with a reasonably small time investment.

I upgraded their FM program to v6 and began analysing the existing DB.
It appears to be completely flat-file with contributions (for example)
recorded by FM's "repeating field" capability. Since this hard-codes a
30 contribution limit (if I understand this feature properly), it
doesn't seem like a good solution to me.

I split the DB into two tables--one for contributor info, and another
for contributions. I created a relationship between the two based on
contributor ID, and I was pleased to see how easy it was to display
the contributor name on the contributors.db layout via a calculated
field. The next step was to enable the office staff to enter a
contribution in the newly independent contributions table by looking
up the name of the contributor in order to find the contributor
ID--sort of the reverse of what I had accomplished via the calculated
field. As near as I can tell, there is no way to do this via FM's
native functionality--so the reason for this message is to make sure
that I'm not erring here and perhaps discover commonly used solutions.

I can see an "easy" solution here--open the contributor database in a
new window and instruct the staff to copy and paste the ID from one DB
to the other. I'm guessing that I can also do this programmatically
using FM's scripting language.

Any help--and perhaps even better a source of sample code, would be
deeply appreciated.

Thanks again,

--Jack Love

 
 
 

Look-ups (as opposed to "looked-up")

Post by Jack Lov » Wed, 26 Mar 2003 00:12:25


Oops. Sorry to reply to my own message, but I goofed below and I'd like
to avert non-productive responses. Below where I speak of successfully
creating a relationship and displaying a calculated field, I should have
said "contributions.db" rather than contributors.db. It wouldn't be much
of a trick to display a calcualted name field on the latter. :-)

--Jack Love


> First of all, apologies in advance for the "newbie" aspect of this
> question, and thanks in advance for all replies anyone might
> contemplate offering me.

> I'm an experienced Oracle programmer who was recently asked (by a
> small non-profit organization) to review and perhaps replace a
> FileMaker DB with a better Filemaker or other DB. (I'll be doing this
> on a pro-bono basis.) For reasons most readers here will instantly
> understand, I did not contemplate replacing FileMaker with Oracle.
> <smile> Deciding whether Access, 3D or some other PC program might be
> a better choice is a bit more difficult, however, I ultimately figured
> that redesigning the existing FM database makes the most sense if I
> can manage it with a reasonably small time investment.

> I upgraded their FM program to v6 and began analysing the existing DB.
> It appears to be completely flat-file with contributions (for example)
> recorded by FM's "repeating field" capability. Since this hard-codes a
> 30 contribution limit (if I understand this feature properly), it
> doesn't seem like a good solution to me.

> I split the DB into two tables--one for contributor info, and another
> for contributions. I created a relationship between the two based on
> contributor ID, and I was pleased to see how easy it was to display
> the contributor name on the contributors.db layout via a calculated
> field. The next step was to enable the office staff to enter a
> contribution in the newly independent contributions table by looking
> up the name of the contributor in order to find the contributor
> ID--sort of the reverse of what I had accomplished via the calculated
> field. As near as I can tell, there is no way to do this via FM's
> native functionality--so the reason for this message is to make sure
> that I'm not erring here and perhaps discover commonly used solutions.

> I can see an "easy" solution here--open the contributor database in a
> new window and instruct the staff to copy and paste the ID from one DB
> to the other. I'm guessing that I can also do this programmatically
> using FM's scripting language.

> Any help--and perhaps even better a source of sample code, would be
> deeply appreciated.

> Thanks again,

> --Jack Love


 
 
 

Look-ups (as opposed to "looked-up")

Post by John Weinshe » Wed, 26 Mar 2003 00:58:57


Yes, there is a way to enter data into, and create new records in the child
file from the parent file, but it won't work if the foreign key is a
calculation (and contributor id is probably not a calc).

In the 'Edit Relationship' page where you set the attributes for the
relationship, enable 'Allow creation of related records', and then use the
portal tool (in Layout mode) to draw a portal on a layout in the parent
file. The portal tool will prompt you for the relationship name, how many
portal rows, and a few checkboxes. These are all easy to change later.

Now place a field, using the field tool, in the portal. You will be prompted
for the name of the field and, usually, the available list of fields will be
drawn from the related file. Put in a field for the dollar amount, and also
the contributor id and name (you'll remove them later-- this is for
testing).

In the 'contributions.fp5', make certain the contributor name is defined as
a lookup from the parent file ('contributors.fp5'?), using a 'backwards'
relationship still based on the contributor id.

Now enter a valid (i.e., data type number) value into the amount field in
the portal in contributors. The id and name should auto-enter.

'Allow creation of related records' adds an empty, enterable portal row to
the bottom (always) of the portal; entering a valid value into any field in
the portal will create a new record in the child file with the correct
foreign key. A lookup in the child file based on the same key will execute
at record creation. As you can understand, this function will break
(although the relationship and its portal will still work) if the foreign
key is calculated.

The portal is also the most obvious way to display multiple donations from
the same contributor.
--
John Weinshel
Datagrace
Vashon Island, WA
(206) 463-1634
Associate Member, Filemaker Solutions Alliance


> Oops. Sorry to reply to my own message, but I goofed below and I'd like
> to avert non-productive responses. Below where I speak of successfully
> creating a relationship and displaying a calculated field, I should have
> said "contributions.db" rather than contributors.db. It wouldn't be much
> of a trick to display a calcualted name field on the latter. :-)

> --Jack Love


> > First of all, apologies in advance for the "newbie" aspect of this
> > question, and thanks in advance for all replies anyone might
> > contemplate offering me.

> > I'm an experienced Oracle programmer who was recently asked (by a
> > small non-profit organization) to review and perhaps replace a
> > FileMaker DB with a better Filemaker or other DB. (I'll be doing this
> > on a pro-bono basis.) For reasons most readers here will instantly
> > understand, I did not contemplate replacing FileMaker with Oracle.
> > <smile> Deciding whether Access, 3D or some other PC program might be
> > a better choice is a bit more difficult, however, I ultimately figured
> > that redesigning the existing FM database makes the most sense if I
> > can manage it with a reasonably small time investment.

> > I upgraded their FM program to v6 and began analysing the existing DB.
> > It appears to be completely flat-file with contributions (for example)
> > recorded by FM's "repeating field" capability. Since this hard-codes a
> > 30 contribution limit (if I understand this feature properly), it
> > doesn't seem like a good solution to me.

> > I split the DB into two tables--one for contributor info, and another
> > for contributions. I created a relationship between the two based on
> > contributor ID, and I was pleased to see how easy it was to display
> > the contributor name on the contributors.db layout via a calculated
> > field. The next step was to enable the office staff to enter a
> > contribution in the newly independent contributions table by looking
> > up the name of the contributor in order to find the contributor
> > ID--sort of the reverse of what I had accomplished via the calculated
> > field. As near as I can tell, there is no way to do this via FM's
> > native functionality--so the reason for this message is to make sure
> > that I'm not erring here and perhaps discover commonly used solutions.

> > I can see an "easy" solution here--open the contributor database in a
> > new window and instruct the staff to copy and paste the ID from one DB
> > to the other. I'm guessing that I can also do this programmatically
> > using FM's scripting language.

> > Any help--and perhaps even better a source of sample code, would be
> > deeply appreciated.

> > Thanks again,

> > --Jack Love

 
 
 

Look-ups (as opposed to "looked-up")

Post by Lynn all » Wed, 26 Mar 2003 03:02:11



> I can see an "easy" solution here--open the contributor database in a
> new window and instruct the staff to copy and paste the ID from one DB
> to the other. I'm guessing that I can also do this programmatically
> using FM's scripting language.

John Weinshel gave you an excellent "how to" on creating a portal in the
parent file and entering records through the portal. Filemaker will
auto-enter the key data in the child file when such a record is created
by entry of any data in a portal from the parent. It's one of the better
features of Filemaker. :)

Quote:

> Any help--and perhaps even better a source of sample code, would be
> deeply appreciated.

As for sample code, your installation of Version 6 for the client should
have included a large number of "template" files, which are generally
VERY simple files. Look for one called "Time Billing" in the Filemaker
Templates folder installed with the rest of the application.  This has a
parent and child file setup with a portal allowing creation of related
records. Enjoy. :)

--
Lynn Allen              Allen & Allen Semiotics
FSA Associate           Filemaker Consulting & Training

 
 
 

Look-ups (as opposed to "looked-up")

Post by Jack Lov » Wed, 26 Mar 2003 04:23:24


Thanks to Lynn and John. I'm still a little fuzzy on part of this (looks
like I'll be creating my first FM "portal", but I'll try both of your
suggestions this evening.

--Jack Love



>>I can see an "easy" solution here--open the contributor database in a
>>new window and instruct the staff to copy and paste the ID from one DB
>>to the other. I'm guessing that I can also do this programmatically
>>using FM's scripting language.

> John Weinshel gave you an excellent "how to" on creating a portal in the
> parent file and entering records through the portal. Filemaker will
> auto-enter the key data in the child file when such a record is created
> by entry of any data in a portal from the parent. It's one of the better
> features of Filemaker. :)

>>Any help--and perhaps even better a source of sample code, would be
>>deeply appreciated.

> As for sample code, your installation of Version 6 for the client should
> have included a large number of "template" files, which are generally
> VERY simple files. Look for one called "Time Billing" in the Filemaker
> Templates folder installed with the rest of the application.  This has a
> parent and child file setup with a portal allowing creation of related
> records. Enjoy. :)

 
 
 

Look-ups (as opposed to "looked-up")

Post by Jack Lov » Wed, 26 Mar 2003 04:36:14



> Yes, there is a way to enter data into, and create new records in the child
> file from the parent file, but it won't work if the foreign key is a
> calculation (and contributor id is probably not a calc).

Correct. In the contributor.fp5 I have a non-stored autocalc field that
concatenates last name, comma, first name and I had hoped to be able to
do the reverse lookup on that field to the contribution.fp5, but I kept
receiving error messages that I think amounted to "you can't get there
from here." But contributor_id is just an ordinary serially generated
number, primary key to the one table and foreign to contributions.fp5

Quote:> In the 'contributions.fp5', make certain the contributor name is defined as
> a lookup from the parent file ('contributors.fp5'?), using a 'backwards'
> relationship still based on the contributor id.

[snip]

I think I followed the rest of your post, but I didn't quite get the use
of "backwards" in the paragraph above. I used the term "reverse" myself,
so I'm hoping we're referring to the same thing. Is "backwards
relationship" anything that's referred to in FM literature (help
screens, etc), or is it something that most FM programmers would recognize?

(The terminology when moving from one product to another is probably the
most exasperating part of the learning process. In the Oracle universe,
a "lookup" is generally the opposite of what it is in FM, although this
is specific to the few of us who program with Oracle Forms. The DB
itself couldn't care less about lookups in either direction. But in
Oracle Forms, a "lookup" is usually a list of values from a related file
that allows the user to choose the correct foreign key.)

Thanks again for the help.

--Jack Love

 
 
 

Look-ups (as opposed to "looked-up")

Post by John Weinshe » Wed, 26 Mar 2003 05:13:32


Yes-- by 'backwards', I meant using the same keys on both sides-- the
cotributor id-- from contributions to contributor. If you create, in
contributions, a data entry (i.e., not calculated) text field, defined to
lookup up that concatenation from contributors across the 'backwards'
relationship, it should work. There's probably no good reason not to store
that concatenation-- the only downside is some extra storage-- and you can
search and sort on it much faster if it's stored.

'Backwards' is more shop talk than technical term. And I pity the Oracle or
any other SQL developer trying to find your bearings in this world, where
the form and tables are smooshed together. But that smooshing produces cool
devices like the portal, which you can build in an instant.

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



> > Yes, there is a way to enter data into, and create new records in the
child
> > file from the parent file, but it won't work if the foreign key is a
> > calculation (and contributor id is probably not a calc).

> Correct. In the contributor.fp5 I have a non-stored autocalc field that
> concatenates last name, comma, first name and I had hoped to be able to
> do the reverse lookup on that field to the contribution.fp5, but I kept
> receiving error messages that I think amounted to "you can't get there
> from here." But contributor_id is just an ordinary serially generated
> number, primary key to the one table and foreign to contributions.fp5

> > In the 'contributions.fp5', make certain the contributor name is defined
as
> > a lookup from the parent file ('contributors.fp5'?), using a 'backwards'
> > relationship still based on the contributor id.

> [snip]

> I think I followed the rest of your post, but I didn't quite get the use
> of "backwards" in the paragraph above. I used the term "reverse" myself,
> so I'm hoping we're referring to the same thing. Is "backwards
> relationship" anything that's referred to in FM literature (help
> screens, etc), or is it something that most FM programmers would
recognize?

> (The terminology when moving from one product to another is probably the
> most exasperating part of the learning process. In the Oracle universe,
> a "lookup" is generally the opposite of what it is in FM, although this
> is specific to the few of us who program with Oracle Forms. The DB
> itself couldn't care less about lookups in either direction. But in
> Oracle Forms, a "lookup" is usually a list of values from a related file
> that allows the user to choose the correct foreign key.)

> Thanks again for the help.

> --Jack Love

 
 
 

Look-ups (as opposed to "looked-up")

Post by Riley Wau » Wed, 26 Mar 2003 07:20:29


Jack,

You might save yourself a lot of time (on the front end) and provide
your non-profit org a great DB by looking at the FREE www.ebase.org/
EBASE solution.  It is a very comprehensive solution for managing
fundrasing, members, etc. in a non-profit organization.  Download it
and look at it.  Set up can be very time consuming (teaching someone
in the organization to work with it), but if they have been using some
Filemaker they may be more adaptable than some.


> Thanks to Lynn and John. I'm still a little fuzzy on part of this (looks
> like I'll be creating my first FM "portal", but I'll try both of your
> suggestions this evening.

> --Jack Love



> >>I can see an "easy" solution here--open the contributor database in a
> >>new window and instruct the staff to copy and paste the ID from one DB
> >>to the other. I'm guessing that I can also do this programmatically
> >>using FM's scripting language.

> > John Weinshel gave you an excellent "how to" on creating a portal in the
> > parent file and entering records through the portal. Filemaker will
> > auto-enter the key data in the child file when such a record is created
> > by entry of any data in a portal from the parent. It's one of the better
> > features of Filemaker. :)

> >>Any help--and perhaps even better a source of sample code, would be
> >>deeply appreciated.

> > As for sample code, your installation of Version 6 for the client should
> > have included a large number of "template" files, which are generally
> > VERY simple files. Look for one called "Time Billing" in the Filemaker
> > Templates folder installed with the rest of the application.  This has a
> > parent and child file setup with a portal allowing creation of related
> > records. Enjoy. :)

 
 
 

Look-ups (as opposed to "looked-up")

Post by Jack Lov » Thu, 27 Mar 2003 07:07:05


Thanks again. I only had the FM help files to go by, so I found my
portal creation a little tricky. I spent an hour at the bookstore at
lunch today, and I think I have a better idea of what I need to do now. :-)

The Oracle Forms approach is just a little different. When all is said
and done, I think you'd find it looks just like one of your portals. One
difference might be that the default behavior of Forms only displays the
"portal" if the user activiates it. If the user knows the key field
(contributor_id, etc), s/he just enters it. If not, the user invokes the
"look up" which invokes the portal-looking window on the screen. When a
match is found, the ID is copied into the appropriate field.

I'm having a lot of fun with FM. Looking forward to testing Ebase which
someone informed me about via email.

--Jack Love


> Yes-- by 'backwards', I meant using the same keys on both sides-- the
> cotributor id-- from contributions to contributor. If you create, in
> contributions, a data entry (i.e., not calculated) text field, defined to
> lookup up that concatenation from contributors across the 'backwards'
> relationship, it should work. There's probably no good reason not to store
> that concatenation-- the only downside is some extra storage-- and you can
> search and sort on it much faster if it's stored.

> 'Backwards' is more shop talk than technical term. And I pity the Oracle or
> any other SQL developer trying to find your bearings in this world, where
> the form and tables are smooshed together. But that smooshing produces cool
> devices like the portal, which you can build in an instant.

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

 
 
 

Look-ups (as opposed to "looked-up")

Post by Jack Lov » Thu, 27 Mar 2003 07:08:52


I've downloaded it--hope the code is visible so I can learn from it. Of
course part of me is involved in this for the fun of bringing up a new
application, but if Ebase is better for my org than whatever I'd have
time to create, I'll use it with many thanks.

--Jack Love


> Jack,

> You might save yourself a lot of time (on the front end) and provide
> your non-profit org a great DB by looking at the FREE www.ebase.org/
> EBASE solution.  It is a very comprehensive solution for managing
> fundrasing, members, etc. in a non-profit organization.  Download it
> and look at it.  Set up can be very time consuming (teaching someone
> in the organization to work with it), but if they have been using some
> Filemaker they may be more adaptable than some.

 
 
 

Look-ups (as opposed to "looked-up")

Post by John Weinshe » Thu, 27 Mar 2003 07:42:50


Although I admit I've not looked for a while, I've never been a great fan of
Ebase, and you may find it dampens, rather than whets, your appetite.

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


> Thanks again. I only had the FM help files to go by, so I found my
> portal creation a little tricky. I spent an hour at the bookstore at
> lunch today, and I think I have a better idea of what I need to do now.
:-)

> The Oracle Forms approach is just a little different. When all is said
> and done, I think you'd find it looks just like one of your portals. One
> difference might be that the default behavior of Forms only displays the
> "portal" if the user activiates it. If the user knows the key field
> (contributor_id, etc), s/he just enters it. If not, the user invokes the
> "look up" which invokes the portal-looking window on the screen. When a
> match is found, the ID is copied into the appropriate field.

> I'm having a lot of fun with FM. Looking forward to testing Ebase which
> someone informed me about via email.

> --Jack Love


> > Yes-- by 'backwards', I meant using the same keys on both sides-- the
> > cotributor id-- from contributions to contributor. If you create, in
> > contributions, a data entry (i.e., not calculated) text field, defined
to
> > lookup up that concatenation from contributors across the 'backwards'
> > relationship, it should work. There's probably no good reason not to
store
> > that concatenation-- the only downside is some extra storage-- and you
can
> > search and sort on it much faster if it's stored.

> > 'Backwards' is more shop talk than technical term. And I pity the Oracle
or
> > any other SQL developer trying to find your bearings in this world,
where
> > the form and tables are smooshed together. But that smooshing produces
cool
> > devices like the portal, which you can build in an instant.

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

 
 
 

Look-ups (as opposed to "looked-up")

Post by Greg Dembe » Thu, 27 Mar 2003 09:55:19


I looked at Ebase recently, and still agree with John.  One general
problem with Ebase is that in its effort to be flexible enough to meet the
needs of many different kinds of organizations, it is big and clumsy and
bloated and slow and trying to customize it if you are a knowledgeable
Filemaker developer, but not an EBay "expert", is no fun at all.  To share
EBase among even only TWO users REQUIRES $999 Filemaker Server, which kind
of defeats the purpose of it being a "free" solution for cash-strapped
non-profit orgs.

I'll be curious what you think of it.

Greg



>Although I admit I've not looked for a while, I've never been a great fan of
>Ebase, and you may find it dampens, rather than whets, your appetite.

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



>> Thanks again. I only had the FM help files to go by, so I found my
>> portal creation a little tricky. I spent an hour at the bookstore at
>> lunch today, and I think I have a better idea of what I need to do now.
>:-)

>> The Oracle Forms approach is just a little different. When all is said
>> and done, I think you'd find it looks just like one of your portals. One
>> difference might be that the default behavior of Forms only displays the
>> "portal" if the user activiates it. If the user knows the key field
>> (contributor_id, etc), s/he just enters it. If not, the user invokes the
>> "look up" which invokes the portal-looking window on the screen. When a
>> match is found, the ID is copied into the appropriate field.

>> I'm having a lot of fun with FM. Looking forward to testing Ebase which
>> someone informed me about via email.

>> --Jack Love


>> > Yes-- by 'backwards', I meant using the same keys on both sides-- the
>> > cotributor id-- from contributions to contributor. If you create, in
>> > contributions, a data entry (i.e., not calculated) text field, defined
>to
>> > lookup up that concatenation from contributors across the 'backwards'
>> > relationship, it should work. There's probably no good reason not to
>store
>> > that concatenation-- the only downside is some extra storage-- and you
>can
>> > search and sort on it much faster if it's stored.

>> > 'Backwards' is more shop talk than technical term. And I pity the Oracle
>or
>> > any other SQL developer trying to find your bearings in this world,
>where
>> > the form and tables are smooshed together. But that smooshing produces
>cool
>> > devices like the portal, which you can build in an instant.

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

--
 
 
 

Look-ups (as opposed to "looked-up")

Post by Jack Lov » Sat, 29 Mar 2003 04:20:30


This is a follow-up to my earlier conversation with John, and I'm posting it
to the group in the hopes that the conversation will be deemed useful to
others. And of course I'm hopeful that John will continue to donate his
experise. :-)

I'm pleased to report that was able to successfully implement the
suggested solution. I created a portal to the child table on the parent
layout that created the necessary child record, and this was indeed the
functionality that I was hoping to achieve. After I did this, I realized
that I could just go on adding more fields from the child table to the
portal so that I wouldn't need to go back to the child table layout at
all--the result looks exactly like a simple master/detail relationship.

While this works perfectly well in this situation, it made me wonder
what happens if there are multiple foreign-key relationships rather than
just one. (I understand that there are good solutions for more simple
look-up/pop list situations.) For example, suppose you are creating a
music library database and the main catalog entry has a parent table
driving the performer field, and another parent table driving the
publisher field, and a third parent table driving author (lyricist,
composer) field. Would you still try to do this with multiple portals on
a single layout, or would you try something else (such as a separate
layout for each master/detail relationship)? Last question (for now
<smile>)--can you use another portal in the detail area to create a
master/detail/detail relationship?

Thanks in advance,

--Jack Love

 
 
 

Look-ups (as opposed to "looked-up")

Post by Lynn all » Sat, 29 Mar 2003 05:56:56



> While this works perfectly well in this situation, it made me wonder
> what happens if there are multiple foreign-key relationships rather than
> just one. (I understand that there are good solutions for more simple
> look-up/pop list situations.) For example, suppose you are creating a
> music library database and the main catalog entry has a parent table
> driving the performer field, and another parent table driving the
> publisher field, and a third parent table driving author (lyricist,
> composer) field. Would you still try to do this with multiple portals on
> a single layout, or would you try something else (such as a separate
> layout for each master/detail relationship)? Last question (for now
> <smile>)--can you use another portal in the detail area to create a
> master/detail/detail relationship?

Where there is more than one parent, the child file becomes more in the
nature of a join file, which FM does not create on the fly, as I
understand certain other systems do.

In the case of the example above, where the parent might be album (old
tech, huh?) or CD, I would have a table of publishers, authors and
performers (they might be a single table or might be different), and to
specify a single song record, would use pulldowns to select the
appropriate selections for each song in the publisher, author and
performer fields.  For small universes of reference, a separate table
isn't necessary where value lists alone could suffice.

Thus, the input continues to be simple, from the primary parent file
into the child file, using the other reference files as sources for
additional keys without actually moving to those files. When selection
from a pulldown list or menu becomes unwieldy, there are techniques for
presenting reference data through filtered portals and selecting and
transferring key data which work really well.  Think of an purchase
order system where parts specified for a job appear in one portal on the
PO parent record and are transferred to a Purchase Order Line items
portal with the click of a button.

Any FM file can sustain multiple relationships (in either direction) to
multiple other files. The schema of relationships can become extremely
complex, particularly when you get into relationships based on compound
keys, multi-line relationships (which can become many to many without
join files or works for Go To Related SET operations) and filtered
relationships. The more you learn about how FM relationships work, the
more powerful become the features you can incorporate.
--
Lynn Allen              Allen & Allen Semiotics
FSA Associate           Filemaker Consulting & Training

 
 
 

Look-ups (as opposed to "looked-up")

Post by Jack Lov » Sat, 29 Mar 2003 07:19:05




>>While this works perfectly well in this situation, it made me wonder
>>what happens if there are multiple foreign-key relationships rather than
>>just one. (I understand that there are good solutions for more simple
>>look-up/pop list situations.) For example, suppose you are creating a
>>music library database and the main catalog entry has a parent table
>>driving the performer field, and another parent table driving the
>>publisher field, and a third parent table driving author (lyricist,
>>composer) field. Would you still try to do this with multiple portals on
>>a single layout, or would you try something else (such as a separate
>>layout for each master/detail relationship)? Last question (for now
>><smile>)--can you use another portal in the detail area to create a
>>master/detail/detail relationship?

> Where there is more than one parent, the child file becomes more in the
> nature of a join file, which FM does not create on the fly, as I
> understand certain other systems do.

I'm not sure I understand what you mean here...

Quote:> In the case of the example above, where the parent might be album (old
> tech, huh?) or CD, I would have a table of publishers, authors and
> performers (they might be a single table or might be different), and to
> specify a single song record, would use pulldowns to select the
> appropriate selections for each song in the publisher, author and
> performer fields.  For small universes of reference, a separate table
> isn't necessary where value lists alone could suffice.

What is the mechanism for the "pulldown" you're referring to? I agree
that in some cases you can manage a single table that could catch
publishers, authors, other artists, etc (most likely by using some
categorization attributes), but I don't see how to organize the screen
to make it easy for a user to retrieve the ID number for those artists
and see the name displayed.

Thanks for replying,

--Jack Love

 
 
 

1. SQL 7 and concurrent look-ups

On a 500mhz PIII (256 megs of RAM), how many concurrent connections could be
made?

I know that's tough to answer (as queries very in complexity), but I'm
looking for a ballpark figure.

I can say this will be used in a web environment.

Thanks,


2. Problems with Data Pipelining

3. look ups

4. US-NC-PL/SQL SKILLS NEEDED IN CHARLOTTE, NC

5. Look ups

6. write rejected rows from flat file

7. Problems with look-ups

8. Look-ups on two fields

9. Help for Look Ups

10. Slow Database look ups

11. Can I do "reverse look-ups" with DB2?

12. Soundex and "look-alike" searches