Jump to content

Tim Falconer

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tim Falconer

  • Rank
    member
  1. Hi folks, This question seems too simple, and I can figure out a number of ways to do it, but I want to know what's <good> and <right>... I've got a main "orders" table, that is a typical orders-with-line-items kinda thing. Happens to be called "Job". I've got an "address book" table, also very typical. Happens to be called "Contacts". I have a join table between these, because a Job can have many Contacts - "sold to", "ship to" "carrier", etc. And obviously a Contact can have many jobs, and many roles - sometimes "sold to" is the same as "ship to", sometimes it
  2. Good to know, Vaughan, would you care to elaborate or point me at some relevant article on alternative methods for structuring TO's and their relationships in FMP? I'm very interested in this topic.
  3. Ha! So it is, Lee! I noted the date but not the year. So I guess I was no help at all... c'est la vie!
  4. In each line in the portal, there is an entry field for "Crate". It's a drop-down list, consisting of the numbers 1 through 10. The "Add to Crate" script reads the selected value... if the shipping manager has not previously selected "4" for that Shipping Order, then Crate 4 is a new crate.
  5. Thank you all so much. I've "+1'd" each of your comments but that does not come near to expressing my gratitude. And I've been lurking here for a few months, and have already learned much from each of you by reading other threads. Thanks so much! tzf
  6. Thanks so much, both of you. This is very helpful. I don't know whether that statement is meant to be ironic, but if I could ask, without sounding like a total idiot, is it always a not(good) idea, or only sometimes? I guess I really don't care though - by which I mean: my goal is not to learn every intricacy at this point, but to learn the basic best practices at my level. It appears that I've found the best practices for a newbie here, but part of being a newbie is that you may not recognise the good stuff when you see it (or write it). So, thank you both, again, for your
  7. Thank you again for helping. The second ERD is correct, and all of those relationships are shown correctly. Every time the shipping manager presses the "add to crate" button, it creates a record in ShippedItems. But it should only create a new record in Crates when needed. thanks, tzf (off-topic, what software do you use to create these neat ERD's?)
  8. Thank you, Comment. The conditions are restated further down, "If Parent Field A..." etc. In set terms, call "parent field A = child field A" set X, and call "parent field B = child field B" set Y, The set that does not cause a new record is (X intersect Y), and the set that causes a new record is (not(X intersect Y)). But maybe that's not any clearer at all! In the real world, it's actually pretty simple: We're packing parts into crates. Parent Field A is the Shipping Order (i.e. the KP, a get(UUID)-generated string) from which the parts are being selected. The parts ar
  9. I'm somewhat of a novice myself but maybe I can help. Are you familiar with One-To-Many Relationships, Many-to-Many Relationships, and Join Tables? If not, the FileMaker Pro Training Series, Module 3, is a great place to start. Googling "Join Tables" brings up three great articles at the top, including one by Dwayne Wright, who's taught me a ton of things via his blog. In fact, in his article on Join Tables one example he lists is: "Phone Number, linked by clients, leads and vendors". That sounds a lot like your question. Please let me know whether this is helpful to you, or if you n
  10. I'm on a roll tonight... I hope I'm not overstaying my welcome here , and also that this question is not a "tl;dr". A friend had a glance at one of my scripts and expressed concern at the number of variables I was using in a script to write values into my "Shipping Line Items" record (maybe 10 variables, all local). At some point, she had said "Lookups are useful where they are useful, but using variables is OK where it's appropriate." It appears that maybe I took some undue liberties with this... In this case, the source data is in one of two portals at the top of the layout. T
  11. John, Thank you kindly for your response- quite informative. Sorry I didn't respond earlier, been working on other things... Also, thanks for the pointer on the EULA! Thanks, tzf
  12. Hi there again! Here's a little puzzle from a relative novice (me): I have a parent table and a child table in which I want to create new child records when and ONLY when either <one> OR <both> of TWO fields is unique. Multi-Criteria relationships don't do that... or is there something I'm not seeing? I've experimented, with the multi-criteria being "Parent Field A=Child Field A" AND "Parent Field B=Child Field B", via a portal, when the first field in the child record is made non-empty and exited, a new record is created, regardless of whether the child field was a match
  13. Hi there! This may seem like a totally obvious question, but I've read the internet, and it says that "Allow Creation..." is for use, basically, only with portals. But what if the related table, where you want to make a new record, is not one with any fields on the layout? Can you use the relationship to create new records via a script, or is that just another one of those "don't try that, it's stupid" kinda things? I'm thinking it <is>. Is there no way to use the "Allow Creation..." trick to create records via a script? I mean, other than having the script "Set Field" (o
×
×
  • Create New...

Important Information

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