save found set

[hpw]

my solution is shared through a fm server and there are 10 people working on it. for acquisition purposes some of the users need to put together an appropriate set, searching and narrowing the search, etc. After they found the set they want to work with, they will work on it e.g. during two weeks and after that they will start with another set.

Is there a way to store temporarily a found set? Of course I can't add a field everytime someone starts a new task.

What I thought of as a simple and more or less useful solution: simply put together the set, then as a first thing, one adds a specific expression in the log with (replace field content), so afterwards one only needs to search for that specific expression to get the set. It's not really satisfying however....

hans

[Brian C]

I suppose the first question that needs to be asked is this:

Do you want to store the results of the search, or do you want to store the search criteria?

If you store the results of the search, no new records or records that may have been modified to fit the new criteria will ever be included in your found set. So you will have a snapshot in time so to speak.

If you store the search criteria, you will be able to find all records that fit your search criteria including new records or modified records that have been added/changed after the time of the initial creation of the search.

[hpw]

ok, of course the latter seems to be a much better option.

I don't know about the implication of the two options.

However, for our daily work at this moment it's working fine to work with a snapshot.

So if there is an easy way for storing the search criteria I'm more than happy. But as I said: we can live with just storing the results of a search.

Thanks,

Hans

[Brian C]

There are ways of doing both, but dynamically storing the search criteria and being able to dynamically restore it is a lot more complex to do and to explain.

I have provided an example file to show you how this can be done using Copy All Records to store the found set

Restoring the found set requires a relationship which links the IDMultikey to the ID in order to perform the GTRR script stept to locate the stored record set.

Keep in mind that the copy all records script step must only be used on a layout with only the id field on it. If other fields are added, copy all records will grab the values from those fields as well.

FindCopyAll.zip

Edited July 25, 2007 by Guest
Updated Uploaded File

[hpw]

i'm not sure I understand this solution. Let me explain my situation:

there are, say, 10 people working with this shared database. some of them are working with the same set of records during some weeks. afterwards they probably will put together another set based on different criteria to work on...

during the time they work on a certain set they should be able to always get back to the set of records in question. somehow they should be able to define temprorary "work lists" and get back to them. Important would be that they could do that themselves, create such work lists, clear them again etc.

thanks for any support.

it seems i'm a bit lost right now...sorry

Hans

[hpw]

ok, step by step i'm starting to understand.

one challenge i still see: we have various users and they could probably work with various worklists (saved found sets) each.

- and these people shouldn't need to have lots of knowledge about the interior of the db

thanks

hans

[Inky Phil]

How many records are likely to be in each found set, 10, 10,000 or 10,000,000?

Also is it possible that more than one user will be working with a record at once or once chosen by a user is that record then 'allocated' and so can then be locked to changes by all other users?

Phil

[hpw]

Hi

Well overall - at this moment - our contact db has 3500 contacts.

But even with a growing number of contacts, the sets to be handled will be between 50 and 1500 I suppose.

But these contact can't be locked for other users.

I just don't know why it is so complicated to create temporary groups and even more: why I can't think of how to do it...

hans

[Brian C]

To store your found sets you need to create a new table to place the multikeys into. Each multikey should exist in a separate record. If you are only dealing with 1 found set at a time, you only have one record to deal with which keeps things easier for retrieval.

So once you have this temporary table - you can then automate the process of "saving the found set" so that it will store the multikey in this new table in a new or a preexisting record.

If you want you can add a time/date stamp to the record and a description so that you will be able to identify it.

As for restoring the found set you will need to either allow user to pick what found set they want, or you can use a field in the table to mark which found set is the current default set to perform a find on.

This may seem complex, but if you want to store search criteria it gets rougher. :)

[hpw]

thanks an awful lot! really! after studying your file, I thought it would work like you described in your last post.

I'm really grateful for your help!

hans

[hpw]

now i'm getting bold: would it be possible to let FM show a dialogue popup where the user can give a name to the found set to be stored under?

thanks

hans

[mr_vodka]

sure why not. This is the way I have it so that my users can group records together and name it whatever they want. You can have them enter it into a global field, and as part of creating the records in the table, I have an auto-entry of using the global value.

Also you are gong to want to check for errors such as the global field being empty, invalid, or already existing.

Then you can have the users be able to load a grouped set of records by using a value list which will only display their own records based on their own list names.

[hpw]

Well, I understood the solution of Brian C exactly. everything makes sense, but when I implement it, it doesn't work.

First problem: The Script "Store find via Copy" does copy the ID numbers of the found set. That's ok. But somehow it doesn't paste it into the field on the other table.

Second problem: When I paste the number (as I wrote above: the IDs wer copied by the script) manually through left mouse key and "paste" into the IDMultikey-field, the ID numbers appear in the IDMultikey-field, but also in the ID-field where automatically a serialnumber should enter.

I don't get it...the two fields of the table FindTest are not related with each other and the ID-field is defined as a "autoenter serialnumber" field.

thanks for your help

hans

[Vaughan]

I avoid copy/paste: it's layout dependent, and it kills whatever the user has on their clipboard. Besides there are much better ways.

Instead, loop through the found set of records and generate a list in variable. Then use Set Field. It's not a lot slower than Copy All.

Heck, maybe even the List() function might do it without looping through the records. It'd probably be fastest of all.

[Søren Dyhr]

Heck, maybe even the List() function might do it without looping through the records. It'd probably be fastest of all

I'm wondering what you mean by this, as far as I know doesn't List( come yet with found set option like we have it in GTRR??

What still seems to be needed is a CF containing GetNthRecord( ...preferably tail-recursive to make it cope with larger found sets.

--sd

[Brian C]

I know the copy all records destroys the clipboard - but it is so darn fast it is hard for me to ignore. I deal with huge found sets - in some cases half a million records...

If the clipboard is truly an issue - you can solve this to some extent by storing the clipboard contents in a global text field prior to using it. After you run your processes you can restore the clipboard. Granted this does not help if the clipboard is not text data but it will solve most issues.

As for getting the paste to work:

- your target field must exist on the layout

If you are just using the paste script command - you can specify the field that the data will be pasted into.

If you want to make it more generic so that the script will not have to be tied to a specific table, you can also make use of objects:

- your target field must have an object name assigned to it (use the object info palette to name the field with an object name

- you must use the go to object script command to make sure the insertion point is inside the field prior to issuing the paste command

I am still looking into the suggestions that Søren has brought up. Some of it shows promise but I am not convinced it will be fast enough for my own needs. I will try to look at this in more detail tonight and post my thoughts on it.

[Brian C]

After reviewing the technique mentioned by Søren it will not fit my solution, but it may fit yours:

To summarize:

- The GetNthRecord used in a custom function which makes use of the recursion technique can be used in a calculation field with no need for a script. It is very fast. If tail recursion is used you can obtain up to 50,000 records very quickly.

- Copy All Records technique is the fastest and is not limited by the number of records in the found set, but it marries the script to two layouts and destroys the contents of the clipboard unless it is saved ahead of time.

- Variable loop is the slowest of the solutions, but it requires no special layouts and is not limited by the number of records in the found set.

Here is the link to the example that Søren pointed me towards:

http://www.filemakerpros.com/GetNthRecordTAIL.zip

As a footnote it is good to know that using global fields is slower than using variables in v8 or v9 of FMP.

It is also important to note that using Form View is faster than using List View if you freeze the window while you use the "Go To Next Record/Request" in a looping script.

[Brian C]

One more thing. Comment pointed out to me that you can use a container field to store any kind of data. So a global container field would be a better choice if you want to preserve the contents of the clipboard.

[Søren Dyhr]

However if you should be forced to thread the narrow path of CF'ing, is there other ways than tail recursions to circumvent the iteration max of non tailed... remember there is a slight slowdown when tailing:

http://www.clevelandconsulting.com/support/viewtopic.php?t=1264&highlight=10000

But if it's in this approach is faster, I can't tell. But what I this afternoon found time to scrutinized was the fact that scripted replace not any longer needs to have the approached field shown on the layout in order to work.

This means that found sets ID's actually can be gathered by scripting like the above shown. It works splendid on releative simple gatherings, but gets tiresom with larger sets.

--sd