I am trying to sort records in FM Pro 8.5 with Applescript. I have 2 dbs, in one of them user choses fields which contents are actually names of fields in the second db (report db). Based on their choices and order of sorting, I want the applescript to do the sort.

The command is:

sort by {field SortField01, field SortField01} in order {descending, ascending}

The syntax is OK, but the sorting done in FM is not in the order specified, it goes only by the first parameter for all the fields, which is wrong. I need different sorting orders for different fields.

I can't figure the way around this.

Someone said that this is a problem and FM knows about it, but maybe someone here found some wizard way to solve it.

Anyone?

sort by {field SortField01, field SortField01} in order {descending, ascending}

Why are you sorting twice by the same field, shouldn't it be:

sort by {field SortField01, field SortField02} in order {descending, ascending}

Next issue is why not doing it natively instead:

http://www.filemakerpros.com/LessSort.sit

...and let applescript get you to the correct object??

--sd

It was totally my error. The step should be saying:

sort by {field SortField01, field SortField02} in order {descending, ascending}

Also, I saw your file and it's not really helpful for my project, because I have reports based on sub summarizing fields, and by choosing some or all of them you can get different reports for the same found set of records. That is the purpose of having the first db, so the user can choose them from a list of available fields.

Edited April 3, 200718 yr by Guest

Yes portalized subsummaries are quite difficult to make - possible though. But you might have ignored the filemaker native use of GetField( and Evaluate( ...there is a cool example of such a technique in the fm7 version of "Special Edition...." p. 387... where the above graph is from - it's on p. 398... in the fm8 version

The globals are defining which of the original fields is used for which coloumn, the use of Evaluate( is due to occational translation of calculations results you might wish to show in a coloumn.

The question is then which of the methods are best, you're bound to involve some scripting to get into previewmode anyway ...I might perhaps have investigated if I could reproduce your apparent bug, but oftentimes is Applescript better suited for interacting with other application, rather than piggybaging the inner mechanics of filemaker, the time it takes to get the syntax straightend by trial and error - outweights the time it takes the time to structure things properly in fm-native tools, it is indeed prejudicial of me ...but I've spend hours and hours of my clients time to nail these pesky syntax issues, which of course could be me being daft as a brush???

If you have been drilled with other more SQL'ish tools, does it however take some to get used to the utilization of calc'fields, and even longer to make it your virtue - knowing when and why to apply them. Reserve these applescript approches for cgi'ing or such, there is as far as I can say nothing where Applescript does something better than a proper structured solution made with native tools - when it's core database dealings.

--sd