Jump to content

doughemi

Members
  • Content count

    961
  • Joined

  • Last visited

  • Days Won

    30

doughemi last won the day on December 17 2015

doughemi had the most liked content!

Community Reputation

82 Excellent

About doughemi

  • Rank
    lifetime learner

Profile Information

  • Gender
    Not Telling

FileMaker Experience

  • Skill Level
    Intermediate
  • FM Application
    14 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    OS X 10.11.6 El Capitan

Recent Profile Visitors

8,541 profile views
  1. Button Script to Display Tab

    You did not name your tab in the Inspector, and then substitute that name for "Tab Name" in the script.
  2. Can't upload new solution to server

    Your first problem sounds like a permissions problem. See http://help.filemaker.com/app/answers/detail/a_id/11957/~/uploading-database-files-to-filemaker-server . For your second problem, try a different browser. I have a similar problem with Safari:
  3. Protected: How to avoid collisions using UUIDs

    How does one get a password?
  4. Take a look at the Magic Key Technique.
  5. The original calc should be changed to PeriodPos = Position( MaxString; "."; 1; PeriodCount ) to make it work. As comment said, we need more information to understand how it applies to your current problem (if it indeed does). Why the number 1880? Is it arbitrary, or does it have some significance?
  6. Single email to multiple recipients

    Did you check "Perform without dialog" in the script editor?
  7. I explained that: Each join table record is a record of one part owned by one customer. Without it, how do you record that customer #1 owns both part 123ZYX and part 456PQR? And then buys 2 pieces of 098WTF? (hint- you can't and you can't without modifying the structure, or "schema" of your database. But you could with proper structure.)
  8. Is every part number sold to one and only one customer? Does every customer own one and only one part? One and only one unit of a given part number? Will this absolutely always be true? IF your answer to all of these questions is yes, then do it your way. If it turns out you're wrong, you will have to rebuild your structure to accommodate multiple parts and/or customers each and every time they occur. If you have a "something"(customer, part, inspection) it is called an entity. If that entity has a one-to-one correspondence with another "something", the second entity can be assumed to be an attribute of the first and can be a field in the first table. If you have an entity that can apply to more than one instance of another, it is a one-to-many relationship and the two should be in separate tables. If you have two entities that have multiple relationships with each other (which is the usual case with customers and products--many products can be sold to many customers), then the separate tables for each entity should be connected with a join table. Just create a new Value list showing all values from Customers::ID and Customers::Name to use with the dropdown.
  9. There are any number of ways: A script run by a New Part button on a Customers layout which stores the customer number in a variable and then creates a new record in the CustomerPartsJoin table and enters the fk. A dropdown list on a CustomerPartsJoin layout that shows customer names but also populates the fk field with the customer number. A manual or scripted or partially-scripted method that mimics the way you assign a new part to a customer now. to name a few.
  10. Here is a diagram of the organization of your solution. A layout of the Inspections table can display a field (such as rev_number) in the Revisions table through the chained relationships between the tables (with the intervening CustomerPartsJoin table). If you put the field in a portal, you can view more than one record, but in this case, you only need to see one record. A portal is not required. Sorting the relationship as mentioned before will cause only the latest record to be that one record. Note that if you someday want to view a report of all the revisions of a part, all you need to do is add a relationship between Parts and a new TO of Revisions.
  11. Revisions should be put in their own table, and related to the Parts table by Part ID. Sort the relationship by Revisions::date, descending. If you place fields from Revisions on a Parts table layout, only fields from the latest revision record will be seen.
  12. Creating an Application

    You must compile a runtime on the platform that will use the runtime. However, you are allowed to use your registration key on more than one computer as long as you do not run the application on both of them simultaneously. The .fmp12 file you create on the Mac can be opened on the Win box after you install FileMaker on the Win. You then can compile the runtime.
  13. Set Field By Name using a variable

    The first recommendation is to correct your structure. Then you won't need set field by name, and a lot of other gyrations. There should be 3 tables: Customers, Product, and Transactions. Transactions is a join table related to Customers by Customers::ID = Transactions::CustomerID and to Product by Product::ID = Transactions::ProductID. Each record in Transactions is one purchase of one item by one customer (e.g. Customer 1234 bought 6 suits (id 9876) on 3/21/17. If the customer also bought sports coats on that date, that purchase would be a separate record. Now you can easily make reports on product sold, customer purchases (per year or per product), customer visits, and most everything else about the business.
  14. The OR rule states that if any input is true, the output is true; otherwise the output is false. The AND rule states that if all inputs are true, the output is true; otherwise the output is false. Your expression is therefore true OR (true AND false) = true OR (false) = true. If you are not getting a 1 output, then your input expressions do not reflect the actual conditions you are modeling.
  15. Hide tab when get account = username

    Try not(Get(AccountName) = "matt" or Get(AccountName) = "kristen" or Get(AccountName) = "haley") Get(AccounName) ≠ "matt" is true whenever the account is anyone's but Matt's. Combined with the other statements, your calculation is always true; therefore you always hide the tab.
×

Important Information

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