Script problem

#1

I have a master-detail layout where I cannot see all fields in the
detail. I need to write a script that moves to another layout based the
detail table /in such a way that i will be in the same detail record as
I was in the former layout.

I generel, I would have no problems with it. The master-detail is only
for technical reasons as there is only one master record with only one
field, the primary key. Usually, I would just show the detail table in
list view, select the right row and then go to the layout that will show
one record with 'all' fields. But this is not possible here as the
database shall be usable on an iPhone in FMTouch - which doesn't support
list view. Unless it is done through a dummy master table and the table
itself in a portal.

The fields in the detail table is primary key, foreign key [to dummy
table], a text field describing what is in the record - and a field that
can be very large with 'notes'.

I just don't see a command that will take the primary key in the detail
table and use that as an argument in statements that will open another
layout with the detail table in the record with that primary key.
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe

#2

Quote:

I just don't see a command that will take the primary key in the detail
table and use that as an argument in statements that will open another
layout with the detail table in the record with that primary key.
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe

store the unique ID (I hope you have created one)
goto the layout
perform find with the stored ID

--
Keep well / Hou je goed

Ursus

#3

"Ursus" <ursus.kirk (AT) ziggo (DOT) nl> wrote

Quote:

I just don't see a command that will take the primary key in the detail
table and use that as an argument in statements that will open another
layout with the detail table in the record with that primary key.

store the unique ID (I hope you have created one)
goto the layout
perform find with the stored ID

I haven't used newer version of FileMaker enough to know for sure, but in th
"good ol' days" you simply used the Go To Layout command and FileMaker kept
the same record displayed and the same overall Found Set (unless of course
you went to a different Table, which was in a different file in those days).

"Progress" does not always mean "better".

(

Helpful Harry

)

#4

Quote:

I haven't used newer version of FileMaker enough to know for sure, but in
th
"good ol' days" you simply used the Go To Layout command and FileMaker
kept
the same record displayed and the same overall Found Set (unless of course
you went to a different Table, which was in a different file in those
days).

"Progress" does not always mean "better".

(

Helpful Harry

)

Harry

Such is still true when the layouts belong to the same TableOccurrance.
Which is not the same as a table. One table might have many TO's. Each TO
keeps its own found set and current record. Therefore when switching from
layout also means switching from TO you have to include a clause which also
goes to the record you need. GoToRelated is appropriate when the records are
related, but when a table jas multi TO's these TO's often aren't related. a
store-and-find is in place there.
--
Keep well / Hou je goed

Ursus

#5

In article <b1ef6$4bb525da$535399fa$14137 (AT) cache3 (DOT) tilbu1.nb.home.nl>,
"Ursus" <ursus.kirk (AT) ziggo (DOT) nl> wrote:

Quote:

I haven't used newer version of FileMaker enough to know for sure, but in
the "good ol' days" you simply used the Go To Layout command and FileMaker
kept the same record displayed and the same overall Found Set (unless of
course you went to a different Table, which was in a different file in
those days).

"Progress" does not always mean "better".

(

Helpful Harry

)

Harry

Such is still true when the layouts belong to the same TableOccurrance.
Which is not the same as a table. One table might have many TO's. Each TO
keeps its own found set and current record. Therefore when switching from
layout also means switching from TO you have to include a clause which also
goes to the record you need. GoToRelated is appropriate when the records are
related, but when a table jas multi TO's these TO's often aren't related. a
store-and-find is in place there.

I vaguely knew that from readin various bits and pieces. It would almost
be easier to simply dulpicate the required Layout and set it to use the
same Table Occurrance - at least that way you still have the same Found
Set rather than just the one current record.

Helpful Harry

)

#6

Quote:

Harry

Such is still true when the layouts belong to the same TableOccurrance.
Which is not the same as a table. One table might have many TO's. Each TO
keeps its own found set and current record. Therefore when switching from
layout also means switching from TO you have to include a clause which
also
goes to the record you need. GoToRelated is appropriate when the records
are
related, but when a table jas multi TO's these TO's often aren't related.
a
store-and-find is in place there.

I vaguely knew that from readin various bits and pieces. It would almost
be easier to simply dulpicate the required Layout and set it to use the
same Table Occurrance - at least that way you still have the same Found
Set rather than just the one current record.

Helpful Harry

)

The OP might need to change the TO because he/she wants to show different
related items. But yes basically you are right.

--
Keep well / Hou je goed

Ursus

#7

Per Rønne wrote:

Quote:

I just don't see a command that will take the primary key in the detail
table and use that as an argument in statements that will open another
layout with the detail table in the record with that primary key.

If you are going from your single-record display table to your detail
table (which is what it sounds like to me), there is already a
relationship there...so you can just use the Go To Related Record step
based on the same relationship as you already use to display the detail
record in the display table. On this same step, you can specify which
layout you want to use for the detail record's context or display. You
can specify any layout based on that same underlying table (regardless
of table occurrence on the relation graph).

Ursus also provide a perfectly acceptable solution: to grab the detail
record's primary key/ID, go to the desired layout and perform a find for
that ID.

#8

Ursus <ursus.kirk (AT) ziggo (DOT) nl> wrote:

Quote:

I just don't see a command that will take the primary key in the detail
table and use that as an argument in statements that will open another
layout with the detail table in the record with that primary key.

store the unique ID (I hope you have created one)

I have.

And:

Set Variable[$n;Value:Notitser::#]

Quote:

goto the layout

Go to Layout["iNotitser" (Notitser)]

Quote:

perform find with the stored ID

But how?

Perform Find [] with $n doesn't seem to work.

Neither does:

Enter Browse Mode[]
Set Fiels [Notitser::#;$n]
Perform Find[]

I'm sorry for the late reply but my news server is rather unstable these
days.
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe

#9

Per Rønne <per (AT) RQNNE (DOT) invalid> wrote:

Quote:

I'm sorry for the late reply but my news server is rather unstable these
days.

It just began working again a couple of hours ago.
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe

#10

Ursus <ursus.kirk (AT) ziggo (DOT) nl> wrote:

Quote:

The OP might need to change the TO because he/she wants to show different
related items.

"Per" is a Scandinavian short form of "Peter"; I'm a "he" :-).
--
Per Erik Rønne
http://www.RQNNE.dk
Errare humanum est, sed in errore perseverare turpe