Jump to content

Adam S

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Adam S

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Hi, everyone. I was just about to post the question below and happened upon a solution just before clicking go. Though perhaps not traditional, I thought I'd post the question and resolution in case it's helpful to someone else searching in future. The quick summary is that an importing problem in FM 11 was solved by updating my ODBC driver. Here are the details: Just switching an old file from 8.5 to 11 today and hitting a small roadblock. The file includes a script with an import step pulling data from Postgres (not using ESS as it's not yet implemented for Postg
  2. Hi, Jason- Check out Scriptmaster for this (http://www.360works.com/scriptmaster/). The basic implementation is free. You add some files, build a plugin or just have the Scriptmaster file load first and close each time you launch, and then there are a bunch of extension utilities available. We've set it up to query rates when we click a button triggering a script with a "Show custom dialog" step pulling the info from FedEx. Jesse has been good at making changes that we've requested to fill out some features (such as adding a switch for residential vs. commercial). Note it does NO
  3. Matt- We're hoping that Filemaker will finally adopt ESS for Postgres. We know so many companies that are switching from MySQL to Postgres these days that maybe the odds are better for Filemaker 11 to at long last support it directly. It's been a really, really long wait and maybe there's a glimmer of hope at last. ActualTech's ODBC driver is great for at least some connectivity and their staff are helpful, but it's not a live link and updating from Postgres requires an import step and its resultant delay. If having Postgres and Filemaker speak directly via ESS is important to
  4. Jesse- Sent e-mail with the ScriptMaster file as requested. Just wanted to follow up here so we can post results for anyone else who might have a similar issue in future. Thank you.
  5. Just wanted to bump this and see if anyone can please help. Jesse- are you out there monitoring this by chance?
  6. Hi. We're running the latest Scriptmaster version in Filemaker and are trying to get FedEx Get Rates to work. Running from within the module itself for testing, we're getting the included test variables to return a result, as will our FedEx test environment credentials. With our real production credentials, however, we're getting zero as the result. For context, we just obtained the production credentials about an hour ago. We copied and pasted to avoid typos and we're pretty sure we've got the information in there correctly (we of course could be wrong). We're wonder
  7. It looks like this was an old post that didn't get answered, and it's a topic near to our hearts, so I'll go ahead and cap this topic off for posterity. Unfortunately, no, Filemaker, even at v. 10, does not yet support Postgres (PostgresQL) with its relatively new ESS feature. One can still hook in via ODBC using Actual's driver (and Actual staff have been great about helping with this). Well worth the price. Still, synchronizing by script and importing data back isn't the same as just having the data synced up, and we have been not-so-patiently waiting for Filemaker to add full ES
  8. Right. I was hopeful there was some elegant way to solve the puzzle without using a global in this way. So far I can't see a way for a portal to hold calculated values that will dynamically update in this way if those values hinge on the record being browsed in the parent table.
  9. Thanks, Comment. Our structure is approx. what you described, being Customers -< Order_Data -< Addresses. We have the portal set up showing any previous addresses that match the customer for a given, new order. It sounds like the only way to go so far, barring someone's magical idea, is as you described, having a script set a global in the addresses table to say "link to this specific order_data record now," base a relationship on that global, then have the comparison formula in addresses refer to that relationship. We have this set up (and working) using the order number fie
  10. Hoping someone might have a few minutes to help with this question now that July 4th is over perhaps? We're still stuck on this and would like to get the new system implemented before we train some new staff. Thanks!
  11. 1. Thanks to Bruce for helping us focus a bit on the orig. question. Other input is much appreciated, though. 2. I'm not the world's normalization expert, but the addresses really do belong in a separate table when going beyond a basic contact list. We began with a customer's main address (often billing) and their one alternative as part of the customers table. That works until they want to ship to a work address (now we're at three sets of address fields), send a gift to their sister (now we're a four), etc. The table size and efficiency starts to diminish. I so wish we'd started
  12. LaRetta- Hopefully it's workable but here's why you're seeing what you're seeing. This solution started with the Customers table storing addresses directly in the customer record where it shouldn't have (with two sets of address fields, buyer and shipping); the ShippingDest address fields there are legacy and can be ignored, please, as I forgot to remove them before posting. This originally matched a setup created in another database and this is, at last, our process of creating a proper, relational approach. The addresses table intentionally contains the name associated with a giv
  13. As requested, here's an attached sample (zipped) of three files with the relevant, related tables. They should all open with guest access. LaRetta and others, please let me know if there are any questions on these. Thanks! Relationship_Customer_Match_Example.zip
  14. I'll try and switch gears to see if I can create a thinned sample file; not sure how that will go, but will try ASAP. In the meantime.... The transfer holding fields for address are broken into separate component fields (first name, middle, last, street_address_1, street_address_2, etc.). There are two addresses received with each order, one for payer and one for ship-to. If they're deemed new by the user, they're created as real address records (in our addresses table) during the order transfer process. A typical field name would be order_data::transfer_shipto_address_street2, which
  15. Thanks, LaRetta. That might even have simplified another step in this process. Can I gently nudge this topic back to the original question and, if you or others have a moment, would you please chime in on that?
  • Create New...

Important Information

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