FM 7 Find/Sort issues

[jfgeiger]

Firstly, I tried searching on here, but honestly, it's a miserable setup to find anything, so sorry about the possible double post...

I'm trying to search a timecard table that includes a timecard number, producer(name) and a date weekending field.

My script selects all records, sorts by date/name, then goes into find mode.

After typing a name to search for, it displays the results.

The problem is, that the results will only be displayed in ascending timecard number order.

This will happen no matter how a sort the records before the find. Unsorting the records will produce the same result.

1. Is it possible to pre-sort the records before entering find mode, keeping them in the proper order post sort?

2. If not, is it possible to setup a script that will trigger post find to sort the records automatically? (I do not want to make the users click a button to perform the sort, as they are used to just hitting the enter key after entering the search criteria.)

Thank you.

[Neverland]

jfgeiger -

I am assuming that your database is in Timecard order when it is unsorted, or in other words timecard order = creation order.

Why not have a script something like...

<<< stuff leading up to find >>>

Enter Find Mode [Pause]

Perform Find []

Sort Records [Restore; No Dialog]

<<< stuff to do after >>>

This way they can still hit the ENTER / RETURN button and the records will be sorted based on the found set.

SR

[Mike D.]

I don't think your script needs to sort before doing the find. Why not have the script sort the records after the doing the find?

Mike

[-Queue-]

It doesn't make sense to sort before finding either. As soon as you Perform Find, your found set may be completely different, so that a previous sort has no meaning to the currently browsed records. Sort after your find, as suggested.

[jfgeiger]

<<< stuff leading up to find >>>

Enter Find Mode [Pause]

Perform Find []

Sort Records [Restore; No Dialog]

<<< stuff to do after >>>

With this code, they have to hit enter/return twice. First to unpause the script, and again to submit the request. So that doesn't really work.

Secondly, using this same code, the sort does not execute. (Or it does, and just doesn't sort like it is supposed to.)

It's rather frustrating, since I can't seem to see what's happening or why.

Each time it ends up sorting in ascending timecard order. (which would be creation order, but I need descending date order, or at worst descending creation order (which *should* be the same as desc date order)

If I run a sort by hand directly after doing the search, it will work properly.

(as for sorting before finding... it would seem to make sense from a human point of view, since the find would just create a subset of records while retaining their order... computers I guess don't see it that way)

[-Queue-]

It doesn't necessarily create a subset of the same records, however. You could perform two different finds consecutively that result in entirely different subsets of the whole file. You would have to resort anyway to include the 'new' records after the find. Plus, sorting all of the current records would be a waste of time if the result of the next find was only a few records. It makes more sense to leave them 'sorted' in the default creation order, which doesn't require any extra time, and then allow the user or a script to determine what the new sort order should be.

Why do you say the code snippet requires two Returns? It only pauses to allow criteria entry, then performs the find and continues. Only one Return is necessary.

Go into your script and look at what the sort order is. It will be the last sort performed before the script was created. You can manually adjust it in the script step to sort differently.

[jfgeiger]

Well, I did this same thing this morning, and it failed. Multiple times. (Why else would I post again?)

I did it just now and it worked.

I dunno if it's a buggy type issue with FM7server/developer (I'm using the trial of server) or something else strange. (I've also had issues where the script can't update a global field, but 10 minutes later, it could...)

Anyway, thank you for all the help. I wish things would work properly the first time.