Wim Decorte

Moderators
  • Content count

    5,097
  • Joined

  • Last visited

  • Days Won

    119

Wim Decorte last won the day on February 17

Wim Decorte had the most liked content!

Community Reputation

406 Excellent

4 Followers

About Wim Decorte

  • Rank
    member
  • Birthday 12/17/1968

Profile Information

  • Gender
    Male
  • Location
    Toronto

Contact Methods

  • Website URL
    www.soliantconsulting.com

FIleMaker Profile

  • FM Application
    15 Advanced
  • Platform
    Cross Platform
  • Skill Level
    Expert
  • Certification
    7
    8
    9
    10
    11
    12
    13
    14
    15
  • Membership
    TechNet
    FileMaker Business Alliance
    FIleMaker Platinum Member
  • Title
    Sr. Technical Architect
  1. If you are worried about there are many options. The easiest is to create a sparse bundle disk image and install FMP15 on that disk. That keeps everything related to that app on that disk image If you don't like iFM15 just throw away the disk image and there will be no interference with other apps preferences. That's a whole other discussion. That argument is really all about your perception of the value. Given that FM12 was released in April of 2012 and we're now almost 5 years later. The 260GBP translates to roughly 50GBP per year for software cost. If the solution / data is not worth it then I would look for a development platform that is cheaper. Spending 50GBP yearly on average for a platform that runs your business doesn't strike me as "squeezing as much juice out of its users".
  2. You can use the "?" placeholder for the IN clause and have all the benefit of having FM automatically quote for the right data type etc. Only caveat is that you need as many ?s as there are elements for the IN list. So doing something like this: WHERE a.PartNo IN (?,?,?,?) will work if you then pass in 4 elements to your ExecuteSQL() parameters. To make this entirely dynamic, all you need to do is create a script to create the SQL syntax and use Evaluate() to execute the ExecuteSQL(). Or a recursive custom function to do this. I prefer a script since I don't use ExecuteSQL() anywhere but in scripts.
  3. Windows Server 2003: surely your clients are not on that anymore!? It was end of life in July of 2015, that's coming up to two years ago. That's a dangerous place to be in for a server...
  4. Any plugins installed in FM (even if you don't use them in that file)? There could be some more clues in the complete crash log but in the end it may very well be that you are running an unsupported config.
  5. The next test is to try it again with a brand new file but in another account on the same machine. Sometimes these crashes are caused by something in your account's profile.
  6. As a total aside and not knowing anything about the solution: I'm assuming those are 8-core processors? Depending on how busy the user load is and how high you the FMS cache set, asking the user to take on extra load server-side through PSoS or schedules may require some more memory.
  7. That's because the "Get Directory" script step was added in FM14. Just remove that step, and add the full path to where you want the export to go to the Set Variable $path step.
  8. By far the easiest way to install a plugin on the server is to use the "install plugin file" script step in a script that you run through PSoS. Does this one require a specific Java version that perhaps your server does not have?
  9. 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.
  10. You want to give full access to the records but not give full access at the same time? There seems to be a contradiction in your question? Don't rely on the UI to enforce your security, it really is as simple as that.
  11. Nothing wrong with multiple layouts so don't artificially limit yourself here. You need the layouts you need. Nothing more but also nothing less. And the layouts you use for scripting can just be blank layouts so there is virtually no maintenance on them. Absolutely agree. Security should be implemented at the data level first.
  12. The answer you got on community.filemaker.com was to use 'grant full access' to the script. I don't think that is always a good idea (it's a sledgehammer approach to security). Your scripts can use their own layouts where you can set fine-grained rights to, they don't have to re-use the user layouts.
  13. Say that you have these records with 3 columns (car make and how many sold in what month): Chrysler March 100 Mazda February 50 Chrysler February 200 Honda January 90 Mazda January 40 If you want to show the totals per car make then you can use your subsummary by sorting the records by car make and defining a summary field for the total sales. But you can also loop through the records (physically or using GetNthRecord) or use another aggregating technique to load the data you need in a variable to loop through (HyperList has a very interesting readup on the pros and cons of all of them: http://www.modularfilemaker.org/module/hyperlist/) And as you go through your list you can keep track of 'buckets' with their totals, all in variables $sales[ code("chrysler")] would be the Chrysler bucket for instance, just keep track of the names of each bucket in a separate list, for every record, add the sales value to the sales bucket for that car make. Once you are done looping through your records / list, go to your scratch table and create one record for each bucket item (car make) and set the field to the what is in the $sales bucket for that car make.
  14. Not correct. There are two types of calculated fields: stored and unstored. Stored calcs get calculated when the record is created or when a dependent field is changed. They don't get calculated at the moment of download / caching. Unstored calcs & summary fields get calculated when they need to be used or displayed, basically when their value is referenced. That does not happen at the moment of download / caching between FM client and FMS. Having said that, calc fields are very often the root cause of a lot of performance problems in my experience. They are easy to use but consider them carefully. Use with caution.