working with one line in a multiline key -trying again

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Michael Bystroem - 22 Nov 2003 12:30 GMT

I didn't get a response on this the first time. I'm hoping this is not
so tricky after all. What I need is a mechanism to be able to get a
*specific line* out of a multiline key, so I can work on one specific
related record without a portal if I want starting out from the
mutliline key. Am I assuming right this is possible? Some hints on how
to do it would be very welcome.

My design is a mix of multiline key relations and joining tables.
Sometimes when I'm in a parent database I can get several records from
the opposite parent with this Multiline key, which is very useful for
portals and such.

But what if I also need to work on *one* of those keys and display one
record at a time (each one on a copy of the layout)? How can I get to
the third line in a multiline key and utilize it for adding and
displaying records in the opposite parent? I find multiline keys are
mostly for *showing records*. Correct?

Is the population of the multiline key best made in the join table
as a calculation on related records and their constructed multiline key,
that I can refer to now and then from the parent when
relations are added or removed, so I can index the relationship in the
parent? Or are there other more useful ways that I'm not seeing at the
moment?

Reply to this Message

John Weinshel - 22 Nov 2003 14:15 GMT

When I read your earlier post, and it is true now, I did not understand what
you meant by 'the opposite parent'.

Signature

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

> I didn't get a response on this the first time. I'm hoping this is not
> so tricky after all. What I need is a mechanism to be able to get a
[quoted text clipped - 20 lines]
> parent? Or are there other more useful ways that I'm not seeing at the
> moment?

Reply to this Message

Michael Bystroem - 23 Nov 2003 04:23 GMT

> When I read your earlier post, and it is true now, I did not understand what
> you meant by 'the opposite parent'.

OK, with "opposite parent" I mean that, in a 3 database scheme of db
Parent1, db Join and db Parent2, the latter is that "opposite parent"
and vice versa, depending on from where you start. That one and the
first Parent1 both lend their primary keys "ID" to Join. Both Parent1
and Parent2 records have then a one to many relation to the Join table.

So the multiline keys are built in, say Parent1, by going to related
record (Parent1:ID to Join::Par1_ID relation). looping trough all
related records and assigning the Join::Par2_ID field to a variable,
which content is copied to multiline key field of the current record in
Parent1.

This makes it possible to see fields from Parent2, as well as edit them.
New records in Join, binding the both parents together, is scripted and
add new empty fields from Parent2 to write into.

Now, If I have multiple layouts in Parent1, I may want to show only one
hit from Parent2 at a time instead of every related record in a Portal
and instead navigate to the other by shifting layout with a button, all
while staying in the same record of Parent1. This may be for constraints
on the size of the layout or for some other reason.

The problem I see with Multiline keys, is a I lose the control on what
specific record I want to see, if I don't use a portal. with which I can
see all.

What I need is the mechanism to get to the next related record of
Parent2, while maintaining editability of fields. Something akin to
using the multiline key field as an array.

In pseduospeak.
Set vMulti to "1"
Perform Script "Nav":
Go to line vMulti of MultiKey
Set vMultiOne to vMulti

vMultiOne have its own relationship to Parent2. So when I need to get to
the next record of Parent2 and press a button, I can perhaps activate
script like:

Set vMulti to "2"
Perform Script "Nav" (See above)

Or perhaps some kind of filter in a oneline portal is better?

Was that more clear?

Reply to this Message

Shadenfroh - 23 Nov 2003 05:40 GMT

"So the multiline keys are built in, say Parent1, by going to related
record (Parent1:ID to Join::Par1_ID relation). looping trough all
related records and assigning the Join::Par2_ID field to a variable,
which content is copied to multiline key field of the current record in
Parent1."

Just a quick note. Instead of looping through the related records, you could
set up a value list in Parent1 called "r_Par2" which is from field
Join::Par2. In Parent1, you can then set your multi-line key to
"ValueListItems ( status ( currentfilename ) , "r_Par2" ).

Signature

Shadenfroh
shadenfroh@yahoo.com

> > When I read your earlier post, and it is true now, I did not understand what
> > you meant by 'the opposite parent'.
[quoted text clipped - 45 lines]
>
> Was that more clear?

Reply to this Message

Michael Bystroem - 23 Nov 2003 11:25 GMT

> Just a quick note. Instead of looping through the related records, you could
> set up a value list in Parent1 called "r_Par2" which is from field
> Join::Par2. In Parent1, you can then set your multi-line key to
> "ValueListItems ( status ( currentfilename ) , "r_Par2" ).

Ah, thanks. I forgot about that method. But the value list need of
course to be constructed out of related records on the Par1_ID field.
So I'd need a selfrelationship on that field as a selection mechanism.
Correct?

Reply to this Message

Shadenfroh - 23 Nov 2003 05:55 GMT

Three fields:
Multiline - a text field with your multiline key
RowNum - a numeric field with the row number of the single key you want
SingleLine - a calculation as follows:

Middle( MultiLine & "?" ,
Position( MultiLine & "?" , "?" , 1 , RowNum - 1 ) + 1 ,
Position( MultiLine & "?" , "?" , 1 , RowNum ) - Position( MultiLine & "?" ,
"?" , 1 , RowNum - 1 ) - 1 )

Incidentally: I use multiline keys extensively in my solutions. In fact,
unless the relationship itself has a value (such as "role" for the
relationship betwen a person and a given project), I don't have a join db.
The one thing you can't do (easily) is add records in a portal. For that, my
scripts use a portal on a hidden layout, where they add keys to multiline
key fields on either side of the relationship as necessary, rather than just
populating the foreign key automatically.

Signature

Shadenfroh
shadenfroh@yahoo.com

Reply to this Message

Michael Bystroem - 23 Nov 2003 11:25 GMT

> Three fields:
> Multiline - a text field with your multiline key
> RowNum - a numeric field with the row number of the single key you want
> SingleLine - a calculation as follows:

OK, I'll try this later today. Thanks.

> For that, my
> scripts use a portal on a hidden layout, where they add keys to multiline
> key fields on either side of the relationship as necessary, rather than just
> populating the foreign key automatically.

Care to scetch out the general addscript ideas? You just add new keys to
the end of the multiline key field? What about removing keys?

I thought removing lines to be too problematic that I found it better to
just repopulate the multiline field after any change. I don't have that
many records so I can get away with it. Maybe there are an equally
simple script to do that as well?

Shadenfroh, thanks for reaching out.

Reply to this Message

John Weinshel - 23 Nov 2003 19:31 GMT

While the explanation of the two parents makes the model clearer, I think I
will understand better what you want if you can give a real life example. So
far as I follow, Shadenfroh is giving you excellent advice-- I also tend to
Set a (gobal) text field to the ValueListItmes() function (and yes, the VL
will be populated by related values), and that global becomes my left side
(multiline) key in a relationship to what I think you are calling the other
parent.

In fact, this kind of design can give you keys to wherever you want to go.
As you note, the join file will contain, as foreign keys, the primary keys
of the two files being joined, which means you can use this structure to
grab the primary keys in 'parent 2' for a group in parent 1, i.e, all the
teachers for a given group of students, even if some students have the same
teacher more than once.

The loop and the value list, however, will produce results that are useful
in slightly different ways. The VL will eliminate duplicates, and the loop
will include them (unless it is designed not to). Where the loop's result
(the global text field) will still provide, effectively, the same left-hand
key as the VL, it also provides an actual list which might be useful in
other ways, such as looking for multiple intersections. Shadenfroh's
suggestion to parse the list is a good way ('walking a list') to extract
that sort of data when you need it.

I don't see where portals are an issue here-- portals are just a graphical
device to display related values, and the real work is performed by the
career diplomats, not the political apointees, i.e., the relationships
themselves.

Signature

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

> > Three fields:
> > Multiline - a text field with your multiline key
[quoted text clipped - 16 lines]
>
> Shadenfroh, thanks for reaching out.

Reply to this Message

Michael Bystroem - 30 Nov 2003 19:24 GMT

> So far as I follow, Shadenfroh is giving you excellent advice

I think so too.

> The loop and the value list, however, will produce results that are useful
> in slightly different ways. The VL will eliminate duplicates, and the loop
> will include them (unless it is designed not to). Where the loop's result
> (the global text field) will still provide, effectively, the same left-hand
> key as the VL, it also provides an actual list which might be useful in
> other ways, such as looking for multiple intersections.

Thanks for pointing that out.

>Shadenfroh's
> suggestion to parse the list is a good way ('walking a list') to extract
> that sort of data when you need it.

Yes, I've already adapted it to another (Phonelist) problem I had, which
I also didn't get much response on. So it was a very useful technique I
think.

> I don't see where portals are an issue here--

They're not. Not portals and displaying data from more than one related
record is the issue.

> I think I
> will understand better what you want if you can give a real life example.

I'll try that a little later when I hit the limits again (probably
soon). Thanks for responding, John. Much appreciated.

Reply to this Message