Jump to content

HiredGun79

Members
  • Posts

    38
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

HiredGun79's Achievements

Contributor

Contributor (5/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Ok, I'll work on that first method. . If anyone else out there has a more elegant solution - let me know! This manual find scripting is not very cool. . Wish you could put field data into find requests without directly using a layout. . . Thanks for the response.
  2. Ok, that didn't work - It seems as though the first and last locations are being sorted in the location table. . I guess the way that filemaker sees the related locations is just as being related, not related through the stop table. . so when I put in last, it's finding the last location record that's related to the day. . which, after a while, there could be hundreds of locations related to a day. Go on back up to my first post and let me know if that's a valid solution (awkward as hell though) Thanks for the response.
  3. Will that work when I'm getting the name out of a distant table? I want the info displayed from the Day point of view. . I want to display info from the Location table, they're joined by Stops. . So I want to set this. . day::first_stop --> stop_table --> location::name So I should make first_stop = location::name and last_stop to Last ( location::name ) Is that right? How do I specify sorting in this context?
  4. No, that's not the primary key. . I have a unique, auto enter serial number. . . And I have a foreign key for each record in the stop table that is from the "day" table. . so I can relate to do lists and calendar stuff to each day as well. . . So in the stop table, there are stops from each day, probably all mixed up. . the stops that have the same foreign key is the subset that I'm looking at. . I want to determine the first and last location of all related records to a given day. . This way, I can store each stop location in a seperate, "location" table and avoid data entry redundance. So the stop table has two foreign keys. . . the "day" key and the "location" key. In other words, it's a join table. . .
  5. Will that return the primary key of the first and last stop off the stop table? Wait, I just tried it - that returns the actual number value of the stop. . That's cool, but what I'm really trying to do is get the location of the first and last stop. . . For instance, you have a name for the each stop, first stop, Mr. Pink, second stop, Mr. Orange, third stop, Mr. White. I want first_stop and last_stop to be Mr. Pink and Mr. White. . Sorry I didn't phrase my question correctly. . .
  6. This'll work, I just have to go back and add a script step to update the local key whenever it's possible that a customer will be added or removed from an order. . . I bit more tedious than a simple calc field, but it's a solution nonetheless. Thanks again for the discussion and I'll see you all on the boards.
  7. Hello, Say you have a paper route database. You have a related database that has the current day's itinerary. Each stop is identified with a stop number. How would you write a script to place the first stop and the last stop in two other records, first_stop and last_stop? To rephrase that, the record with the first stop number (always going to be 1) goes in first_stop, and the record with the last stop number (could be 10, 20, 62. . ) in last_stop. I think it's possible to go to a layout, enter find mode, go to the stop layout, find all stops related to the day we're looking at, sort them by stop number ascending, take the first record and put in record first_stop, go to record (last), put that in last_stop. Is there an easier way to do this? Thanks!
  8. Ahh, THE local key. . . Man, I was dense. . thought you all meant like "the key field of the calculation" as in the important field. . not THE key field. . Let me give this a shot. . . Thanks
  9. Ok, I cannot get this thing to work. . Here's the original file I posted, but with an order table added with two fields, order_id and customer_id. . . I also have added a script called "Update Potential Customer" in the script menu. . There I have placed the set field (keyfield, keyfield). . so it's easy to run that script to test to see if it's working.. . I must be doing something incorrect. Thanks again for all the help! filtered_portal_help_v2.fp7.zip
  10. Ok, let me add that to the choose customer script. . . that should do the trick. brb.
  11. Ok, I created a new customer with the potential_customer field being simply the If - Count statement. . Initially, it worked terrific - The potential customer set to "Yes" - just as it is supposed to. . . Then I add that customer to an order. . Unfortunately, the potential_customer field does not change to "No" like it did when it was an unstored calc. Here are the field settings for potential_customer. . . "Indexed, Auto-Enter Calculation replaces existing value, Evaluate Always, By Value List, Allow Override" So I know I have it replacing existing value, like you said earlier. . . still not getting me the result I require. Thanks for the many posts, you're helping me out a lot!
  12. I apologize for being so obtuse. . How would I set the key field to itself to force a refresh? I'd like the potential_customer field to refresh every time a related order record is changed. . either by the count or the IsEmpty. . Would that use the evaluate calculation?
  13. Yes, I have it replacing existing value. . . at what point does an auto enter calculation "refresh" ? For the 700+ customers already in the database the potential_customer field has no value - when I create a new customer, the potential_customer has a value of 1, yes, which makes sense because a newly created customer wouldn't be related to any orders. . .
  14. Well. . that would work, if the only time the potential customer flag changed is when the customer record is created. . . However. . the nature of that calculation needs to be unstored to remain accurate. . . That is unless I am not using auto-enter correctly. . . The way I have it set now, it only evaluates the calculation and inserts correct potential customer information is when a customer is created. . At that point, it's clear that the customer would not be on an order since it was just created. . so it makes all new customers potential. . once the customer is added to an order and ceases to be potential, the potential_customer field does not reflect the change. . . Is there a way to force the auto-enter to update? Is there another work around? Thanks again for your patience and help. I really appreciate it.
  15. Ok, let me give that a shot. . . brb with results.
×
×
  • Create New...

Important Information

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