Jump to content

LaRetta

Members
  • Content Count

    10,991
  • Joined

  • Last visited

  • Days Won

    151

LaRetta last won the day on October 20

LaRetta had the most liked content!

Community Reputation

506 Excellent

8 Followers

About LaRetta

  • Rank
    Lifelong FM Student

Profile Information

  • Title
    Developer
  • Industry
    Software
  • Gender
    Not Telling
  • Location
    Everywhere

FileMaker Experience

  • FM Application
    18

Platform Environment

  • OS Platform
    Mac
  • OS Version
    High Sierra

Recent Profile Visitors

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

  1. Hi Peter, Credits should be applied, not only after the fact but in the subsequent month - the month the adjustment is made and should never be back-dated. So once a month is CLOSED OUT, it should NEVER be allowed to be changed and records should be frozen to stop all modification to those financial records (such as using a closed date and restricting modification from Security). For the current month, you can even write static but you'd have to tightly control all edits in a transaction fashion. Here is one of many links about transactional handling of invoices: https://www.geistinteractive.com/page/2/?cat=-1 So every month-end, static totals can be written to a table and so can weekly totals (like on a Sunday). Then the current week's entries can be totalled quickly; the combination providing your results. As Wim says, as record counts increase in your LineItems tables, all reporting of invoices will continue to decline in speed if you don't switch to a method of transactional 'static' recording of values and if you ever attempt to run it on mobile without this in place, it'll become unusable. I would never use eSQL() in a calculation field. As for your current needs in resolving your SQL, you couldn't be in better hands.
  2. The problem with using layout-level restrictions on values which must be correct, is that forgetting and placing the field once on a layout with entry to field left ON, and inconsistent data will result. A stored calculation provides safety from this accidental field placement and as Michael says, can be copied because the field can be entered. It'll also allow scrolling.
  3. Hi 1FilemakerMan, If the same User exists as different records in this new table then you did not follow Comment's suggestion of: "You can create such table by importing the user IDs into another table where the UserID field is validated as Unique, Validate always." Can you attach your file? Added: You did NOT import the User ID field and set it to unique, validate always.
  4. I'm struggling to see it as well, Wim. Is there any way you could create an example of it breaking - when using AE serial, for example?
  5. Hi Wim! Can you explain this a bit more? How might users collide if creating multiple records? Do you mean because the file was numbering the records or did you have an additional concern?
  6. A great developer once told me, "Know thy Mod() function, when thou cometh to date calculations." 😀 Hi Barbara! No, I haven't perfected it yet either. Michael and possibly Ray Cologon are the only two who've mastered it to that degree. Nice to see you again!
  7. Hi Rudy, Another option is to use a tool such as Base Elements. A tool such as this is invaluable.
  8. Hi Greg! Comment is correct - no surprise there - that the records should all be in a single table. And since, if a task is not complete, you want it to 'move forward' ... why not have a COMPLETED button and anything not completed and less than or equal to today would be found daily when you sign in. You can then reassign their dates as you wish according to Comment's suggestions. 🙂 I should also mention that the COMPLETED can simply be a dateCompleted if you need to track when you complete a task. It doesn't need to be a boolean 1. The point is, a person will need to decide when a task is complete. Anything NOT complete should automatically be considered to have 'moved forward' without changing its due date at all.
  9. Are you SURE you don't have two layouts named Inventory" BTW, how many layouts do you have (in layout mode, how many total 'records' are listed?
  10. Disable the Go To Object[] in your script and then save the script. Does it work for you then?
  11. Are you really on version 13? Added: And if you use a custom function, you'll need to provide it in the file and refer to that in your script parameter so we can see what you are ACTUALLY doing. 🙂
  12. It sounds like there is a script trigger on the field (or layout with mode change) which attempts to take the value and extend the search.
  13. I've been unable to answer or check your file until now but it looks good. You have an appropriate and logical structure (considering everything that has been discussed and from what I can tell in the file itself). How are you doing on it - any additional questions? I believe that Michael (Comment) covered everything you've asked so far, right? Have you generated any reports yet?🙂
  14. I would suggest keeping the multi-table structure. As suggested by OlgerDiekstra, there is no need for the SurveyMoment table otherwise your structure looks correct; this is the standard structure for a survey-type solution. With the right structure, you can tie all the answers to a survey to the exact same time. I suggest that you not change your structure to attempt to solve a display issue; rather, the other way around. With the proper structure (as you have it), display is simpler. BTW, I suggest you add a Patient table as well. You have come to the right forum to seek help in working through your needs. I'll also review your file tonight and provide additional input.
  15. Hi Rick, Using repeating fields is the number one mistake made by those new to database design. Number two mistake is using several fields (each containing like items) as you described (Equip1, Equip2). Using separate tables all within the same file is the simplest solution and I second Comment's suggestion ... switch now. If you do not, you will later wish you did and it will become much more difficult. Once you use tables, you will begin to understand the POWER of relational design. Welcome to FMForums! It will also help if you complete your profile, particularly your FileMaker version and OS. 🙂
×
×
  • Create New...

Important Information

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