Wim Decorte

Moderators
  • Content count

    5,089
  • Joined

  • Last visited

  • Days Won

    119

Wim Decorte last won the day on February 17

Wim Decorte had the most liked content!

Community Reputation

405 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. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. auto-creation of related records is easy with the 'allow creation' toggle on the relationship. In general you will get lots of benefits from keeping the table narrow, how much benefit is hard to gauge without knowing more details and the overal design of the solution.
  8. No, they don't have to be; if you loop through the records and collect the data and put them into the right 'summary' buckets then you can create the records in the scratch table in the order you want them to appear on the report. No sorting needed.
  9. That's a field validation error, check the field definition, validation tab for what rules it enforces; that will be the clue for what is wrong. How are these files shared? Through peer-to-peer and 'open remote'? Are the files in a network share?
  10. Collect the data in a scripted fashion and dump it in a scratch table in a way that saves you from sorting. The extra effort needs to be weighed vs. how long it takes to do what you do now.
  11. Your basic troubleshooting is correct: find out what is occupying port 443 and 80 and work around that. However: it is not normal that immediately after a reboot it would report that FM14 (not FMS) would be open. That does not make sense and is something that definitely needs to be looked at. Is FMP installed on that machine? If so, get rid of it. This machine is not used as a TS box, is it? One thing in your set up routine: after uninstalling all the components and before the reboot: delete or rename the "filemaker server' folder that is left in Program files.
  12. If you have FMS15 you could use the new TopCallStats log to see what FM is really doing. If it is downloading data then you should see evidence in the FMS stats.log even if you are not on 15. Other suspects are record/layout triggers. And stored or unstored calculations that kick in.
  13. It's a Windows firewall setting. You can set up a rule in the Windows firewall to avoid this, or turn off the firewall on your computer if you have a firewall upstream in the network.
  14. Using RC does not automatically mean that all files end up in one folder. You can specify a folder structure in the container field setup. Most commonly you would use the record ID or some other record piece of data as the subfolder name.