We have reset all users FileMaker related profile fields. Please take the opportunity to update your information,  this will provide background to members whom read your posts. Click here.

Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About TJ53

  • Rank

Profile Information

  • Gender
  1. Thank you! that´s what makes sense. I'm glad it was only a problem with the login configuration of my files
  2. OK I figured it out ... I had the interface file opened by default with an account, but I have set up the data file to asks for the login and password (when accessing from FM Pro). I have removed the auto-login for the interface file and now it works perfectly: one user can open two files now
  3. Hello, I'm testing FMS16 WebDirect with a two files solution (an interface file that loads a data file). When the inteface file opens, it doesn't load the data file. My FMS license has a limit of 1 user connection, that seems to be the issue. Does this means that a two files solution will use two connections per user that opens the solution?
  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. 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!
  6. 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!
  7. 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!
  8. 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!
  9. Mac Mini for FMS 15

    Thank you all for your insights. So my conclusion is: for very particular cases of small deployments (5 users), small and simple solutions (not processor intensive), and not scalable (Mac Mini not possible to upgrade), then a Mac Mini can do the job. But ... for FMS15, Mac platform is not the best choice for server hardware in terms of cost and scalability, so from now on PC hardware and Windows Server make more sense for FM Server 15 scalable deployments. I suppose the key words here are scalability (not possible with Mac Minis) and cost (Mac Pros are too expensive and for same investment a more powerful PC can do a better job).
  10. Mac Mini for FMS 15

    Thank you all, so my conclusion is that for FMS15 scalable deployments Mac Mini is no longer an option. The only Mac environment option would be the Mac Pro, that seems to be a waste of money and resources and still has some limitations (as Wim Decorte mentioned above). Therefore, it no longer makes sense using a Mac as FileMaker Server. From now on the recommended and cost-effective option is Windows Server.
  11. Mac Mini for FMS 15

    Thank you Josh, so it looks like it would be too risky going for the Mac Mini. So ... any general advice about what would be the least expensive hardware and OS server software option recommendable? this is for a small workgroup and they are very concerned about the cost of upgrading from 11 to 15 ... actually they may not even upgrade and stay on 11 if they can't afford the new machine plus the licenses for FM15.
  12. Mac Mini for FMS 15

    Thank you Steven, these are the specs of the current Mac Mini that has FMS11 installed (Josh Ormon asked for the specs so I posted them here). I don't pretend to install FMS15 here since this is obsolete, but to buy a new server for the upgrade. My question is, given those specs and the databases being performing reasonably well currently, would buying the newest Mac Mini for upgrading to FMS15 perform at least as well as currently? or should I just forget about buying Mac Mini and should spend more money and buy a Windows server? I know that Mac Minis are no longer recommended, but this is for just 5 users and 4 small databases that are not expected to grow.

Important Information

By using this site, you agree to our Guidelines.