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

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

Recommended Posts

Posted

When writing a script (lets say to find all records with a reminder date of today), is there any advantage to using one of the two methods below over the other? I could use:

Enter Find Mode

Set Field [History::Reminder Date; "//"]

Perform Find

or, I could just use

Perform Find and Specify the Find Request.

Is there any instance when using one method would be preferred over the other?

Thank you.

Posted

Excellent question! I like to compare and contrast techniques to determine which method works best in which situation. While these are fairly simple examples, they can still you a lot about the advantages and disadvantages of different approaches.

The most noticeable difference is, one script is longer. In this case, you won't notice much difference in speed but more steps usually means slower as well as more difficult to read. However, in this particular case, reading the restored requests requires a double-click to see the requests while you can read the longer script without ever clicking anything.

I would also suggest that the Perform Find [Restore] is a more cumbersome interface to work with. There is a lot more clicking than with a Set Field. Then again, you can pack a lot more find criteria and requests into a single Perform Find whereas a Set Field approach would require a step for each piece of criteria.

There are definitely instances where you would use one technique over another. For example, you can use a script variable with Set Field. You might set a variable in browse mode and then want to transfer the data to find mode. You can't do that with a Perform Find [Restore]. In fact, you can include any kind of calculation formula in a Set Field, something I wish Perform Find had an option for. For instance, you might want to set a date range based on a user provided value in some global fields. You might show a custom dialog asking the user for some dates and then create the date range criteria for them.

The only way you will truly understand when to use one approach over the other is through experience. I have an exercise in my scripting class where I try to teach this thought process. I use a very simple example of scripting the finding of all the records that have the same value in a field (like the new Find Matching Records feature in FileMaker 8). There are half a dozen examples covered in the exercise, all aimed at comparing and contrasting each technique. Which technique works best in this scenario versus another is always being asked? While I can't share the entire exercise with you, I will attach the file we use in class so you can get a flavor for what I am talking about. The file works much better with the exercise guiding yout through it but I still think the file will help make my point.

FINDSIM.FP7.zip

Posted

Set Field [History::Reminder Date; "//"]

For some reason, I would feel more secure using Get ( CurrentDate ). // feels so ... text-like and not a true date. I know, I know ... I've read it in FM Help as well, but IIRC I've read it isn't always safe also!? I am not 100% sure. I suppose it would be okay in a find...

Posted

Thank you both. Your points are well taken. I had considered Get(CurrentDate), yet became a bit concerned realizing the person may miss a day at work. Thus, any reminder(s) due on their day off would be missed the following day. For this reason, I'm using <=// with a flag. This should ensure all reminders due today or earlier with the flag not set will be found. Seems to be working okay.

This topic is 6769 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.