remembering finds

[Heathbo]

This is what I'm trying to do:

I want to perform a find. Perform another find. Go back to the records the first find found.

I don't know if this is possible. If so could you please tell me how.

Thanks in advance.

[CobaltSky]

Hello Heathbo,

There are a number of methods that can be used to save a found set and which is best depends on a number of factors including whether your solution is multi-user, whether you want to be able to save more than one found set at a time, whether other users will need to access a saved found set, whether you want to be able to return to found sets after the database has been closed and re-opened, the size of found sets you will want to save, and so on.

However, that said, one of the most common methods in use is to set up a special layout which has only one field - the ID field for the table - on it, then run a script which goes to that layout and performs a 'Copy All Records' step, then goes to another layout and pastes into a field (eg a global text field). You will then require a relationship from the global field to the ID field.

Using this method, when you wish to re-instate the found set, you simply perform a 'Go to Related Record [show only related] command using the relationship between the global and the ID field.

Perhaps you might like to experiment with this to see if it suits your requirements - and if not, give us a little more detail to go on in suggesting an alternate method.

[Heathbo]

Thanks for replying.

I'm not quite sure I understand your common solution. Can you attach an example?

This is what I'm trying to do:

I have a database with over 300 records in it. Someone performs a find to narrow down the selection. After they find a record they want, with a script they can send it to another table to view all their selected records collectively. The way this script works is: it copies the record ID, then does a find for that ID, then imports that record into the other table. After the record import I want to go back to the 1st found set so they can continue to add records to the other table.

[bruceR]

You don't have to do any of this.

Open the record they want to view in another window. Use the new window command.

[CobaltSky]

BruceR wrote:

You don't have to do any of this.

Open the record they want to view in another window. Use the new window command.

Possibly, Bruce. As I said in my previous message, it depends on a number of factors, such as whether or not there is a requirement to return to a given found set after the database has been closed and re-opened - or to share multiple found sets between users etc etc.

However now that the requirements have been clarified, Heathbo, I wonder if you might like to consider using an alternative way to achieve what you have described, which does not require that the found set be saved at all.

I suggest that you create a global field called 'gTempKey' in the first table, set up a relationship from gTempKey to the primary key (ID) field of the second table and turn on the option to 'Allow creation of related records' for this relationship. Then create a script which runs along the lines of:

Set Field [ Table1::gTempKey; Table1::RecordID ]

Set Field [ Table2::DataField1; Table1::DataDield1 ]

Set Field [ Table2::DataField2; Table1::DataDield2 ]

Set Field [ Table2::DataField3; Table1::DataDield3 ]... etc

Add a further set field for each field that is to be copied ('imported') from table1 to table 2.

Then attach the script to a button and place it in the body area of the list view in table 1.

Clicking on the button in a given record row will create a duplicate of that record in table 2 without ever leaving the table 1 layout, without disturbing the table 1 found set and, importantly, without overwriting the contents of the user's clipboard.

[Heathbo]

Thank you, Thank you

That is so much easier and cleaner than what I was doing. It works perfectly. This may even work with another project I have. Can I use the same technique to send the ID of a record in one table to a portal in another table?

Thanks again

[CobaltSky]

Heathbo wrote:

Can I use the same technique to send the ID of a record in one table to a portal in another table?

Yes.

You can set a value into a global field in another table (even without a relationship between the two tables) and then switch to the other table and retrieve the value - bypassing the clipboard in the process.

[Heathbo]

It works great, the only problem I'm having is; what if I wanted multiple copies of the same record. When I run the script, if I try to put a copy of a record in table 2 that is already in there it won't transfer. This is really needed since this is done quite a bit.

Thanks again

[Heathbo]

Never mind I figured it out.

[Heathbo]

How do I transfer the data to a portal in another table. Considering the portal isn't a field that can be accessed in scripting. If its possible, what is the script I should use? Also, if the script is run again will it put the next data in the next portal row or will it replace the first one?

Thanks again

Heathbo

[CobaltSky]

How do I transfer the data to a portal in another table. Considering the portal isn't a field that can be accessed in scripting.

You can't place a value in a portal directly, it must be placed into a *field* within that portal (which will be a field from the related table to which the portal attaches).

Once the portal is set up with appropriate fields in it from the remote table, you will be able to use the Go To Field[ ] script command to place the cursor into a field in the portal, and the Go to Portal Row[ ] command to move up and down among the rows of the portal. You will also be able to use the Set Field[ ] command to set values into a field within the related table record that corresponds to the current portal row.

In other words, you have complete script control over the portal.

[Heathbo]

You can't place a value in a portal directly, it must be placed into a *field* within that portal (which will be a field from the related table to which the portal attaches).

Once the portal is set up with appropriate fields in it from the remote table, you will be able to use the Go To Field[ ] script command to place the cursor into a field in the portal, and the Go to Portal Row[ ] command to move up and down among the rows of the portal. You will also be able to use the Set Field[ ] command to set values into a field within the related table record that corresponds to the current portal row.

In other words, you have complete script control over the portal.

[CobaltSky]

Hi Heathbo,

Rather than selecting the field from the 'table with the portal' (by which I assume you mean the table occurrence that the layout where the portal resides is based on), go to the drop down list at the top of the Select Field... dialog and choose the table occurrence which is the one that the portal itself points to. You will then see a list of fields in the table that the portal is pointing to and you will be able to select the appropriate field/s from there.

When you do, you will notice that the field boxes have the field names in them preceded by a pair of colons. This indicates that the fields are related fields (from a table other than the one that the layout itself is based on).

HTH

[Heathbo]

I am not sure how your getting the colons. When I go to ScriptMaker and create a script with the Go To Field function in it I don't get the colons next to the field from the table I pulling the data from. Am I missing something? For example: I have two tables. Table 1 and Table 2. Table 2 has a portal with a field in it that accesses a field in Table 1. How do I write a script that will access the field in the portal in Table 2 and not the field in Table 1. It seems FileMaker would rather go to Table 1 and select that field than staying in Table 2 and selecting the field in the portal.

[CobaltSky]

I am not sure how your getting the colons.

The colons I was referring to appear before the field name *in the field box* on the layout in layout mode

How do I write a script that will access the field in the portal in Table 2 and not the field in Table 1. It seems FileMaker would rather go to Table 1 and select that field than staying in Table 2 and selecting the field in the portal.

It is all a matter of context. Specifically, the context that the script will be in at the point when the Go to Field [TableOne::AnyField] command is called.

By context I mean what layout the frontmost window is on. If it is a layout that is attached to table 2 and has a portal with the field from table one on it, the Go to Field[ ] command will go to that field in the portal. If the frontmost window happends to be on a layout which is attached to table 1 and has the field on it, the Go to Field[ ] command will go to that field on the layout and if the layout in the frontmost window happens to be oine which doesn't have the field on it at all, the Go to Field[ ] command will fail and return an error code.

Consequently, you can determine how the script step will behave by having your script explicitly manage context. Eg add a step which goes to the layout that has the portal on it prior to the Go to Field[ ] command, so that you always *know* that the step will go to the field where it appears in the portal.

Of course it gets a bit more complex if you have more than one copy of the field on the same layout (or more than one portal) but that is another story...

[Heathbo]

Ah, OK I got it working now. Thanks again. I have one more question, how do I set it up so when I run this script again it selects the next row in the portal and not the one it just put the data in?

[CobaltSky]

Well, Heathbo, there are a number of ways you might approach it depending on the logic of what you are doing, but I guess one way would be to have the script finish by storing the number of the row it acts on in a field (or a global field, depending on how you're using the database)

Set Field [ TheRowNoField; Get(PortalRowNumber) ]

and then start the script off with the steps:

Set Field [ TheRowNoField; TheRowNoField + 1 ]

Go to Field [ YourPortalField ]

Go to Portal Row [ TheRowNoField ]

[Heathbo]

Set Field [ TheRowNoField; Get(PortalRowNumber) ]

and then start the script off with the steps:

Set Field [ TheRowNoField; TheRowNoField + 1 ]

Go to Field [ YourPortalField ]

Go to Portal Row [ TheRowNoField ]

[CobaltSky]

The field we are calling TheRowNoField would probably be best defined as a global field - in which case it will not matter where it is located - it will be accessible without a relationship form anywhere on the graph.

If you have constructed the script along the lines we have been discussing and it is not working, then one possible reason is that the field you are writing is not accessible ( eg a non-global which is not related to the current table when the Set Field[ ] tries to write to it). That woudl cause the Set Field[ ] step to fail and would account for the script going back to the start of the portal each time.

[mse]

"Saved Searches - Making it easy to search, again and again and again"

at www.filemakermagazine.com