Stephen.S. Posted May 15, 2006 Posted May 15, 2006 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.
John Mark Osborne Posted May 15, 2006 Posted May 15, 2006 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
LaRetta Posted May 15, 2006 Posted May 15, 2006 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...
Stephen.S. Posted May 15, 2006 Author Posted May 15, 2006 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.
John Mark Osborne Posted May 15, 2006 Posted May 15, 2006 I haven't had any trouble with the reserved "//" characters and haven't heard from anyone who has before. I'd be interested in hearing fom folks who have and haven't had trouble. Thanks.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now