10 posts in this topic
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!
I have a system being hosted using FMS14. I also have a duplicate database hosted for testing/exporting using FMS15. PSOS is much slower in my hands with FMS15.
Both servers are physical boxes, with similar (maybe identical) specs (Cores, RAM HD Space, HD Space available)
I also have a Server Side script that creates a found set, exports data to excel and emails it to a user. (This is based on https://www.skeletonkey.com/restoring-filemaker-clients-found-set-within-server-side-script/). The exports have a couple of related fields, but no unstirred calculations.
Using FMS14 this has been working just fine. Using FMS15 it has been significantly slower.
As a test, I exported 13,000 records from both FMS14 and FMS15.
Using FMS14, it takes about 10 Seconds to recreate the found set, then 70 Seconds to create the export.
Using FMS15, it takes about 20 Seconds to recreate the (same) found set, then 175 Seconds to export the data.
In another series of tests, this time exporting 30,000 records (more realistic in my scenario) I found;
Using FMS14, it takes about 25 Seconds to recreate the found set, then 168 Seconds to create the export. (2.5x longer to find/2x longer to export 3x records)
Using FMS15, it takes about 90 Seconds to recreate the (same) found set, then 825 Seconds to export the data. 9x longer to find/11x longer to export 3x records)
In the last series of tests, this time exporting 50,000 records I found;
Using FMS14, it takes about 59 Seconds to recreate the found set, then 262 Seconds to create the export. (6x longer to find/4x longer to export 5x records)
Using FMS15, it takes about 160 Seconds to recreate the (same) found set, then 1700 Seconds to export the data.(16x to find/24x to export 5x records)
Any ideas? Anyone see similar results with PSOS on FMS15?
Again, the machines are identical, the databases are identical and the scripts are identical. the only difference is FMS14 vs. FMS15. I am also letting another user pull data using ODBC. That has also gotten extremely slow using FMS15, but that is a discussion for another thread. I am not using WebD on this server. In general the FMS15 database performs find using FMP Clients. But the FMS15 functions are not very impressive. I am petrified to move my production database to FMS15, and even considering moving the test server back to FMS14. Help!
I am building a customer database. The database will have a primary key. I am looking to make the primary key either a unique integer or a UUID (with 32 chars). The UUID appeals to me due to its ability to sync tables. The primary key will be used for (obviously):
Searching and sorting records As a tag against documents eg document XX is linked to customer AA, BB and CC; and A foreign key to link tables My questions are:
Do UUIDs adversely affect database size Do UUIDs adversely affect speed If UUIDs retain their full 32 chars, then there will obviously be a disadvantage.
However, is FM clever enough to convert the UUID "under the hood" (such as to an integer referenced index) to improve database speed and/or size.
By cat traveller
currently I am looking into creating a very simple database for a cocktail competition for a spirits brand. The competitors are coming from markets all over the worlds, the local offices are submitting the recipies, images and some further information in my ideal world via webdirect into the database itself.
I dont think there need to be more then 2-3 users accessing that database simultaneously.
My question would be if anyone is experienced with filemaker hosters and the perfomance of that hosting when the db is accessed from different parts of the world.
In other words: where would be an ideal country for hosting the file (in terms of performance) if it were to be accessed from Europe, Japan, USA, Israel, China and South America?
My server is running on FMS 13.0v9 and my clients are running FMP 12.0v4. The mismatch is due to my clients still mostly being on OS X 10.6.8. I'm having a strange issue with slowness that I was hoping to get some insight on. Here goes:
I have a layout (named "Checkin Layout") that access a table and a few related tables. The main table has a field named "CheckedIn" which contains either a 1 or a 0. The user checks a checkbox, which enters the value "1". The auto-enter calculation is as follows:
Case (CheckedIn = 1 ; 1 ; 0)
This makes it so that the value isn't ever empty, but will be either 0 or 1. Users have lately been complaining that toggling this checkbox is becoming incredibly slow. I initially tried to remove objects from the Checkin Layout, but found that even if the layout contained nothing but the field in question, toggling the checkbox was still incredibly slow. I then tried changing the auto-enter calculation, thinking that may help. I changed the "Case" function to "If" and noticed that the speed shot up immediately. However, I found that if i closed and reopened my layout, the slowness came back. After some more experimentation, I found that opening the "Manage -> Database" window and changing ANY definitions or calculations would make the Checkin Layout extremely fast, until it is closed. Then once it is opened it becomes slow again.
I'm curious if there is anything happening when I adjust definitions that I could do via scripting. The slowness is taking its toll on productivity, and I can't be around to mess with definitions every time a user needs to check something in. Is there anything I can do??
Thanks in advance for your help.