Server Side Searching in FMSA 9?

[wplate]

I've read that new in FMS 9 is "Server-side searches and calculations provide faster access to results"

So I need to do anything special to enable searching by the server? We've had some horrendous query times with FileMaker 8.0 clients on our FMSA 8 server and I'm hoping to see these times drop with 9. I just wonder if I have to do something special/different in order to benefit.

[Genx]

I need to do anything special to enable searching by the server?

No.

[Vaughan]

"We've had some horrendous query times with FileMaker 8.0 clients on our FMSA 8 server and I'm hoping to see these times drop with 9."

Funny, compared with FMP 6 and earlier, find times have been orders-of-magnitude faster with 8.0.

What kind of finds are you doing?

Even with unstored fields, the finds are faster: the first find caches the resultm the subsequent times the finds are blazingly quick.

[wplate]

Good. I was afraid it might be like Server-Side Scripting/Web-Compatible scripting where only certain kinds of queries would invoke the new power, or maybe I would have to define my relationships in a new way or something.

I'll have to try some side-by-side tests and report back.

[Vaughan]

Well yes, a lot does depend on efficient data design.

I was reading recently that creating multi-predicate relationships that reference multiple stored and unstored fields (ie, some are stored) are much faster than basing the relationship on one unstored calculation field as had to be done in earlier versions.

I'm begining to think that FMP 7 and later really rewards efficient data design (normalised data, etc) with significantly better performance.

[wplate]

"We've had some horrendous query times with FileMaker 8.0 clients on our FMSA 8 server and I'm hoping to see these times drop with 9."

Funny, compared with FMP 6 and earlier, find times have been orders-of-magnitude faster with 8.0.

What kind of finds are you doing?

Even with unstored fields, the finds are faster: the first find caches the resultm the subsequent times the finds are blazingly quick.

My order-processing person occasionally searches for outstanding invoices, the script does a search for invoices with a balance due of more than 0 followed by a sort by due date.

When she was on a PPC-based iMac (FMP 8.0) sometimes the query would take 20 minutes. Now she's on a MacBook Pro (still FMP 8.0), she reports the queries take 5 minutes.

I don't believe a clock has ever been applied to these searches, but I can testify to experiencing the foreverness of the PPC-based search.

The searching client is accessing the server across the internet via a DSL connection.

[wplate]

Well yes, a lot does depend on efficient data design.

I was reading recently that creating multi-predicate relationships that reference multiple stored and unstored fields (ie, some are stored) are much faster than basing the relationship on one unstored calculation field as had to be done in earlier versions.

I'm begining to think that FMP 7 and later really rewards efficient data design (normalised data, etc) with significantly better performance.

I believe you, anything that is "efficient" has to be good, but otherwise your post is way beyond my ability to comprehend. But I gotta say that "multi-predicate relationships that reference multiple stored and unstored fields" sure sounds cool.

[Vaughan]

LOL.

Well, you know when you make a relationship and you match up the fields on both sides? With FMP 7 and later you can specify more than one set of fields to match on.

For instance, lets say you have a Company table, and it relates to a purchases table. Make a relationship based on CompaniID on both sides and it'll show all the company's purchases.

But say you want to display only those purchases before a certain date. Put a global date field in Companies, named "Certain Date". In the relationship, add another set of criteria to the relationship matching the Certain Date field in Companies to the Purchase Date field in Purchases, only match them with "<=". The relationship will now be:

Company Table ---- Purchases Table

CompanyID = CompanyID AND

Certain Date <= Purchase Date

Easy isn't it!

[Steven H. Blackwell]

No, and there really isn't a fundamental change here. Unless you fell into the bottomless black abyss known as the 8.0v2 update, many calculations were searched server side in earlier versions.

Somewhere on this Forum there is a lengthy paper I wrote on the subject of the 8.0v2 server side issue. FileMaker fixed this issue with the 8.0v3 updater, further refined in Server 8.0v4.

There is almost certainly something else going on with your Server deployment.

Steven