All Activity

This stream auto-updates   

  1. Today
  2. Yesterday
  3. Performance issues aside (and I try to avoid unstored calcs if I can, I prefer my logic in scripts), there is another factor to consider. If part of the business logic changes and you are using unstored calcs then by changing the calc you risk changing all the historic records. Which can be a huge problem if you don't think through that ahead of time.
  4. Thank you very much both. I assumed best practice was option 1, and that's how I've been working so far, but was just wondering about option 2. Yes, I am aware. That's why I rarely do development in live production systems, specially when doing scripting. In any case that's very valid point, thank you!
  5. +1 for comment's comments. As for a field definition being more easily accessible. Do you have any awareness of the risks of doing that? I suspect not; or you would not have made the statement. Though maybe you just don't have anybody using this system. What happens when you're defining a field while users are entering data? What can happen to the integrity of the file? You want users out of the system when doing this. Thus your timeslot for accessibility is extremely limited.
  6. Hey schotja, You need to post a method of contact. BTW, be sure to let us know when these positions that your posting get filled. Otherwise, we can only assume your Services Wanted posts are still open from Dec, Jan and Feb. If you are still needing to fill these positions, you might try and find a developer in your area to contract with here. TIA for your cooperation. Lee
  7. One could turn your argument around: suppose you are editing the script, and you want to make a change to the Set Field[] step; you would have to leave the script workspace and look for the calculation field in order to make the change there. I believe that if an action is scripted, it's good practice to place all the necessary logic within the script. And if you divide your scripts into logical parts and take care to comment each part, you should not have to look very hard in order to find what you're looking for.
  8. In case anyone comes here via Google as I did: FieldBounds coordinates are relative to the window. GetLayoutObjectAttribute(field,"bounds") coordinates are relative to the menubar, whether it's inside the window (as on Windows) or on top of the screen (as on Mac). To get the coordinates relative to the window, using getLayoutObjectAttribute ( objectName ; ''left'' )-get(windowLeft)) for the left edge coordinate and getLayoutObjectAttribute ( objectName ; ''top'' )-get(windowTop)-(get(windowHeight)-get (windowContentHeight))+16 for the top edge coordinate will get you very close on Mac.
  9. Thank you very comment for you insight. The main reason why I would consider going for option 2 (as long as there are no performance implications), even having to define an extra field, is because the unstored calculation field definition would be more easily accessible in case I needed to adjust the calculation. Otherwise I would have to go to the script workspace and search for the “Update invoice total amount” subscript in order to make a change in the calculation. On the other hand, I see going for option 2 looks a bit "strange" compared to how standard programming languages work, since in this case the logic would be part of the interface. Also could be confusing to have both fields in the table, and the unstored calculation field not showing in any layout, but only used in the update field script. It looks like the best practice is to go for option 1, and that’s how I’ve done it in the past. But I have to say that lately I’m tempted to go for option 2, just for having the calculation more quickly accessible in case I need to review!
  10. I don't think so - but all performance questions are best answered by performing an actual test. Sometimes the results can be surprising. Performance aside, if you're going to use a script to populate a stored field with the aggregate value, then you don't need the unstored calculation field - and there is no good reason for the script to depend on its existence. Note that there may be additional factors to consider here, for example record locking.
  11. NFC

    Greeting everyone, I was wonder if it possible to read NFC tags with WebDirect from Android device (NFC enable devices)
  12. Thank you! now let's say we have a list layout where the unstored calculation field "total_amount_uc" is showing for each invoice. Therefore, it would have to be evaluated for each invoice record, and therefore there would be a performance penalty. Now let's say that in order to improve performance, we create a number field called "total_amount_script". Then we create a script called "Update invoice total amount", that executes when an related invoice item amount is entered or modified (or an invoice item is deleted). Would there be a difference in performance of setting the "total_amount_script" in these two different ways in the script created for updating the number field? Option 1) Set Field [ Invoice::total_amount_script ; Sum(Invoice_Item::amount) ] Option 2) Set Field [ Invoice::total_amount_script ; Invoice::total_amount_uc ] Thanks in advance!
  13. See also:
  14. Unstored calculation are evaluated as needed. If the field is not shown on the layout, and not referenced in any way, it will not be evaluated.
  15. Let’s say we have two related tables: “Invoice” and “Invoice_Item”. We could create a calculation field in the “Invoice” table called “total_amount” with this formula: total_amount = Sum (Invoice_Item::amount) This field would have a negative impact in performance when appearing in the layout, since it would have to be defined as unstored, because it’s referencing a field from a related table. Now let’s suppose this field is not used for any scripts, tooltips, conditional format, etc … would the performance of the database be negatively affected ONLY when this field appeared in a layout? In other words, would adding an unstored calculation field to a table involve a performance penalty, even in the “unreal” case where this field didn’t appear in any layout, script, conditional format, etc.? thanks in advance!
  16. I can only guess (since you never explained what exactly your filtering does), but in general you would have the buttons set a global field instead of a variable, and instead of filtering the portals, you would filter the underlying relationship by adding the global field as a matchfield.
  17. Is there any difference in terms of performance between a calculation field (stored and indexed) and field defined as auto-enter calculated value (indexed)? For example, we have an “INVOICE” table, with a field called “date_invoice_sent”, and we’d like to have a boolean field called “is_sent”. The calculation would be “not IsEmpty(date_invoice_sent)” So we have two options here: - Calculation field (stored, number result). - Number field defined as “auto-enter / calculated value / do not replace … unchecked”. Would there be any difference in performance between the two options? thanks in advance!
  18. Well, then how do I do it, if not filtering, thru relationship? And yeah, you are right about 7 tabs. It didn't feel right, so I am going to do it with seven buttons.
  19. Last week
  20. Developed a project that i dont have time to manage updates / potential sales / email traffic. Potentially the project needs fmp go or some sort of web access eventually for some clients as well as various improvements to take advantage of newer fmp versions (currently fmp12) Prefer an intermediate developer to man any email inquiries / investigate and setup a way to issue licenses for a runtime / Pay commission on sales if there are alot of inquiries / pay hourly on actual fmp work. Am looking for a trustworthy USA based individual to partner in this endeavor! Regards,
  21. HA! I forgot to put that in there. I'll update this. Thanks! The work is all out of the office, not travel. Clients are all over the country (and sometimes outside of it), but it's almost all remote to their servers and things.
  22. This is an XSLT stylesheet to convert from FileMaker's fmpxmlresult to sitemap and vice-versa.
  23. See
  1. Load more activity