Creating an entity ... layout with portals

[PatriciaW]

I've asked this question in different forms before and never got a satisfactory answer. If anyone has a suggestion I would appreciate it because my problem cannot be unique.

I have a layout which contains fields from a single TO and a portal which contains related records (it is a one to many relationship of client and client phone numbers.) The user wants me to pre-load data into two of the portal rows.

Now I would like to automate this as much as possible. The user wants to tab through all of the fields including the portal rows. I have found that if I invoke a script to pre-load the data into the portals, it triggers the validation rules on the main TO. If I pause in the script for the user to enter the data, then the user can start entering data into the portal rows before I have pre-loaded the data.

I recollect that one possibility was to enter data into a TO that does not have validation rules and then move the data to the real tables when data entry has completed. But that seems a lot of work for something that ought to be simple. I just want to defer validation until all of the data on the form has been entered. Any suggestions?

[Fenton]

At the bottom of the script step Commit Records is a checkbox to "Skip data entry validations."

[PatriciaW]

I've tried things like that ... but the problem (as far as I can determine) is that when I start to enter data into the portal (based on a different TO) it triggers the insert into the first TO and I cannot prevent that from insisting on validating the data.

[Rob 7 Collins]

There is some confusion here that is surely getting in the way.

A table, itself, is like a spreadsheet ... it is a graph of information. Information (data) therefore is stored here.

A table occurance is like a table view ... it is a representation of a table, tied to layouts and their presentation of data. Nothing is stored here.

A layout is a user interface with normal gui elements ... these elements are tied to a table through a TO. Nothing is stored here, but data is entered here.

That data is given to the table for storage.

... if you skip validation and it is still validating, ensure that a user can override the validation in the field definitions.

[PatriciaW]

I'm not sure I see why you think I am confused although I might have used the wrong terminology. The user does not want the ability to override the validation, but even if he did, FM would still present dialog windows to ask the user if he wanted to leave the leave the invalid data in the record.

I would also like to question your definition of a layout as being tied to a TO. In my case, the layout includes two TOs, which is causing the problem.

[Rob 7 Collins]

I'm not sure I see why you think I am confused although I might have used the wrong terminology. The user does not want the ability to override the validation, but even if he did, FM would still present dialog windows to ask the user if he wanted to leave the leave the invalid data in the record.

I didn't mean you are confused, I meant I am confused! ... You wrote TO so much that it starts geting a little unclear. And you talked about TOs in a very unusual way -- I'm still not very clear on just what the problem is, exactly.

Data isn't in one TO or another TO. Data is in one table. So, are you getting validation erros with tblHansel when you enter data into tblGretel? Apparently, somehow, tblHansel has at least a field who's validation is based on tblGretel. (?) You'd be able to avoid this by relaxing the condition for the culprit validations on tblHansel.

I would also like to question your definition of a layout as being tied to a TO. In my case, the layout includes two TOs, which is causing the problem.

I undertand where you are coming from; there is a strong logic to holding that a layout is representative to an entire "tree of related tables". But the context from which you view that tree is always one and only one table occurance; namely the one you define under "Show records from" in the Layout Setup.

A portal has its own context, very like this. A related field without a portal, also, has its own context (you select the TO, then the field, ...efffectively just like a portal).

Actually, thinking of it that way, I've another thought. Is your script running from the context of the layout, and operating on the the portal records while on that same layout? If so, that's the problem. Work on the portal records from their own layout. You can set the found set to reflect only the related records if you use the "Go to Related Record" step.

[PatriciaW]

Okay ... I do understand the confusion and I'll TRY to be clearer in my use of the terminology. (I've been learning FileMaker as I have been converting this application and haven't had any formal training.)

My layout is based on a TO - Client (stored in a file called ClientData - since I have separated my UI and data into different files.) I have a portal based on the ClientPH TO (based on a table which contains the phone numbers for this client.) The TOs are related via a common field.

When the user creates a new client, he uses a layout which is based on the Client TO, and has a portal based on ClientPH.

He asked me to preload text into the first two rows of phone numbers in the portal.

I used a script based on Client and I wanted to create the new record and also initialize these two fields in the two rows in the portal. So my script created the Client record, and then invoked the script to add the two portal rows. But as soon as the main script invoked the portal script, it triggerred (I'm sure this isn't the correct term) the validation on the Client record. So the user got a whole bunch of messages about the mandatory fields before he had a chance to enter any data.

I tried putting a pause into the script before I called the "portal" script, but that meant that the layout didn't show the two values in the portal and there was nothing to prevent the user from clicking on the portal and entering data, even though that was not what was desired ... it is this conflict that I have been unable to resolve. (The user wants all of the info on the same layout so a separate layout is not desirable.)

You also mentioned "Go to Related Record". Here is a source of real confusion for me. The existing application which I upgraded from FM6 did use some GTRR commands, but I discovered these didn't work once I separated my UI and data, because (please correct me if this is wrong) GTRR will only work on a table ... i.e. that the layout and the table have to be in the same file. (I did post a question about this long time ago and my fears were confirmed ... possibly in error.)

[Rob 7 Collins]

You also mentioned "Go to Related Record". Here is a source of real confusion for me. The existing application which I upgraded from FM6 did use some GTRR commands, but I discovered these didn't work once I separated my UI and data, because (please correct me if this is wrong) GTRR will only work on a table ... i.e. that the layout and the table have to be in the same file. (I did post a question about this long time ago and my fears were confirmed ... possibly in error.)

GTRR, and every other script step I think, will only operate on layouts in the file the script is run... I've not had a chance to get a feel for that issue, thank god.

You can use a script in your Client file, to call a script located in the file you want to operate on, and the GTRR called from that second script should work on data in it's file.

...

About the seperate layouts thing: By default, when I'm making databases in FileMaker, I create a "system" layout for every table. It has all the fields in the table. And the user never, ever sees it: I remove it from the layouts view in the status menu (using "Layouts"->"Set Layout Order" dialog), and no navigation takes the user to it. Then, when I need to make a change, like in your case, I'll roll up something like this:

#### foobar script

#

# Creates default client phone numbers (not really what you want)

#

# Called from layout: Client

#

# Script Parameters: 

#    First Call from Client: empty

#    Regular Call/ Recursion: [my Client's key field]

##

If [ IsEmpty ( Get ( ScriptParameter ) ) ]

  # Relaunch the script with the key value

  Perform Script ["foobar script" ; Parameter: GetAsText ( Client::keyfield ) ]

Else

  Go to Layout [ "sysClientPH" (ClientPH) ]

  New Record

  Set Field [ ClientPH::ClientKeyField ; GetAsNumber ( Get ( ScriptParameter ) ) ]

  Set Field [ ClientPH::PhoneNumber ; "1-800-SEXY-LAD" ]

  Commit Records [ no dialog ]

  Go to Layout [ original layout ]

End If

So, this way I can traverse to a different view and only work with the data I'm interested in, and then return to the original view so the user never sees the screen change...

But if the problem is the layout and data are in different files, the error you are getting might be related to that fact and where your script is. You might have to call a script in the other file, to actually work with the data.

[SlimJim]

Looking back at your first post and subsequent explanations it seems that you are trying to script the creation of three new records, one in your main Client table and two related records in your phone number table. However, you want to create the records with only partial filling in of mandatory data. I think deferring of validation on the main table is not possible in this scenario (if I'm wrong someone please correct this) because as soon as you begin to create the related records the main data has to be committed in order for the relationship to be set.

Now one thing you want to avoid is the user entering data into the portal rows without the pre-loaded data in place. So there arises the question of how the pre-loaded data gets into place. If your user completes the client data sufficiently for a clean validation and then enters data into the first portal row (via the tab order) then a new record will be created in the phone number table so this seems to be the place to pre-load the data, via auto-enter on the appropriate fields in the phone number record - is this possible? The match field will be created by the relationship, what about the other data?

No doubt you have considered this method, but just in case you haven't, I present it to you.