I spend too much time in the scripting forum and have tried to use scripts to solve a problem that a portal would solve.. However, I don't understand portals very well and the docs from FM stink...

I have a collection of records which are input by several users. The final user's job is to review these records and add additional info . Currently, the final user clicks on each of these records (which contain multiple fields such as job #, company, due dates, equipment etc.) and adds info to the fiieds which are assigned to him.

Would it be appropriate to have these records with multiple fields be contained in a portal so that I could have a layout in which the final user could scroll to a specific record, select it and add the appropriate info and then move along to the next job by scrolling etc. without having to go to various layouts...

I understand this is vague.. but I am trying to eliminate the process of going to layout from layout for each record to change data.

thanks....?

Yes, a portal can solve the problem for you.

First of all, you need to identify some characteristic of all the records that is in common. This can be the job number if it's convenient and if each record has the same job number as all the other records. If no single field is identical to all of the records that you want your users to be able to navigate through, then you'll need to somehow create one. Perhaps the name of the person who needs to go over the records combined with the fact that they haven't yet gone over them can be concatenated into a single field ("Chuck0" which would change to "Chuck1" after it's been approved). I'll call this field NameStatus

Once you have this field, you can create a global field that has whatever value the records share before they are approved. With the example I'm building thus far, it would probably be a concatenation of the logged in user's name and a 0, something like Status( CurrentUserName ) & "0". I'll call this field UserNameZero.

Create a relationship from the file you are in to the file with the records you want to browse using the NameStatus as the local match field and the UserNameZero as the foreign match field. Place a portal into this relationship on the layout with fields that you want visible in the portal. I'll call the relationship ForeignFile_UserNameZero_NameStatus.

Create another field, this time global. It should be of the same type as the ID field of the records you want to browse, so if you use a text field as the ID field, this should be a global text field. Create a relationship between the local global field and the foreign ID field. I'll call this field gRecordID.

Create a script, which I'll call Select Job, and make set it to:

Set Field [ gRecordID, RelatedFile_UserNameZero_NameStatus::RecordID ]

Attach this script to the portal. Place fields that you want to be able to edit on the same layout as the portal. When the user clicks one of the portal rows, the information for that row will show up in the related fields.

Let me know if I wasn't clear on anything here.

Chuck

Sounds like a portal isn't what you want.

What you seem to need is a list layout, containing only those fields necessary for the final step. If you need other fields to show, so that the person can get the info necessary to enter the "final" data, set the tab order so that they're "out of the loop".

Now your final person can see a list containing all (and only) the info he/she needs, and enter data efficiently.

In a sense this is true... I am currently using a list view. However, I want to have a list view in which I can select a record from this list and in the same layout have additional fields to add content based upon the info from a record in the list view . I am currently clicking on a button next to a record whcih will bring me out of the list view to a new layout with the record details and the aditional fields. I fill this info out and go back to the list view and repeat this process for all records in the list view.Thus I thought about a portal (even though I have never used portals).

c