Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 6354 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted (edited)

Interresting topic, Doug, thanks for letting this discussion spread to some other challenges...

As you say, Michael, if this "find process" becomes a daily routine task, the delay becomes problematical. If not, let the user wait for an answer as long as they don't get the beachball.

Even if the replace field content method would have demonstrated to be quicker, could it really be used in the real life ? Each find would result in a change in the modification log for each record, as first reason I can find for not using it. Plus the problems known in network situation involving this command.

For this same reason, indexing a previously unstored calculation also brings a modification to the record.

My idea is that there is a reason to have this result unstored. Whatever the method to display the result ( an aggregate cal or a summary field from a table occurrence of the child table ), what we see is the result of a relation. What if the relation was dynamic enough to filter the child records from a date range.

ex :

Identify those customer owing more than 1,000 $ in a filtered set of child invoices from may to june only.

Again, if this search is routinely performed, then, it has to be scripted and optimized so that the result is shown quicker. If not, let the user go take a coffee and let us wait for a filemaker version in the future where the search engine will really be performant enough to get the expected result that fast.

By experience, I use aggregate tables to store these aggregate results. For Products for example, the inventory is indexed but the result is not stored in the product table ( in order to prevent record locking when an updating script is triggered to pull the new inventory levels ) but in a Inventory table where each product has its own record.

One could consider the product record is modified anytime the inventory level change. I don't so I can't accept to have my "log" changed on that record anytime a sale is made.

And my so loved repeating fields to store any aggregate calculation for any of my customers for the last 12 months in an aggregate table.

Repeating fields still are quicker than relation.

Booooohh, nobody understands me :P

Edited by Guest
Posted

Maybe. What I meant was a calculation field in Parent (result is Number) =

Case ( Sum ( Child::Value ) > gThreshold ; ParentID )

then match this to ParentID of a second TO of Parent.

To do the "find", show all records and GTRR [related only ; match found set]. I realize this may be a third-generation bastard of Ugo, but the family resemblance is there...

No comment on the bastard thing :P

But...

Just drop the calculation

Case ( Sum ( Child::Value ) > gThreshold ; ParentID )

in an empty layout

go to that layout

Copy All Records

Paste back into a global

Go to related from that global to the parent ID

Who said tricks from FileMaker 4 cannot be used anymore :

Posted

He must be sick or maybe the planets alligned

NO not at all! My problem is that advisors can't stand the chance, of delivering the cute and clever in replies, without the anxiety

....that such methods might be memorized by a newbe or two who can't be skilled enough to see if his/her solution is normalized enough ...newbes who feels utterly accomplished when making bysantine scriptings or pulls the database as such out of it's realm.

A fair share of the questions goes like "why can't it be more spread sheet'ish" ...because the known metaphor is used to understand a new one! This is why I feel repeaters should be tutored by cautions!

--sd

Posted

Who said tricks from FileMaker 4 cannot be used anymore

I tried that. My test file has 20k parent and 60k children records. Searching on unstored takes about 29 seconds the first time, 5 seconds on subsequent searches. Your method takes 9 seconds (copying all those records...). So it's neither here nor there. But the real issue is that the criteria needs to be hard-coded into the calc (please don't bring up Evaluate).

All in all, I agree with what you said in the post before that - even if I don't understand you. :P

Posted

Nice to see you back

It's me who should say so, I havn't made excursions to neither outer space locations or similar! It you who are returning...

My reservation is as usual, if reasoning is made to fit believes creationist'icly or submissively like St. Pauls letter to the Romans dictates, is it not likely to produce the best kind of engineering, be it in Filemaker or similar tools where the "questioning" is an urged disipline.

--sd

Posted (edited)

even if I don't understand you. :P

Not a problem. I too don't understand Soren's "Romans letter to St Paul dictates" but I still like the readings from Copenhagen :

Edited by Guest
Posted

For those who wish to poke into this Paul business:

http://www.anthonyflood.com/sellerspowersthatbe.htm

...perhaps isn't as much what he believes, as the way someone uses it. Similar to repeaters, plugins or global fields.

--sd

Posted

Thank you so much for posting this file! I have been stuck with the poor options of a popup menu or a dropdown list when I have a value list using field contents from over 1000 records in another table. Mine runs over a network with FMS so the timing of keystrokes when trying to use the autoenter in the value list can be very frustrating depending on network traffic etc.

This looks like a great alternative, but I really wanted a 'real time updating' filter like I've seen in non-FMP databases (excuse my beginner terminology).

To do this, I tried a script that keeps comitting the global filter field and then going back to it so that the portal appears to display the related record 'as you type'.

I've attached my attempt. Can any of you pro's suggest a change or improvement as it beeps at me sometimes (maybe my keystroke happens at the wrong time during the script loop)

TIA

Phil

StudentExample2.fp7.zip

This topic is 6354 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.