23 posts in this topic
The attempt to push data to the server has failed. (The message received from the server was: "111A01C0-27AE-414B-AC1C-DC56C83F877EBy Gianluca D'Aquino
I've set up 2 files syncing with Easysync. I've set up just a single table in sync called ES_TRIP (without pull or push, because I want to sync in both directions, is that correct).
I put the same cfg on mobile and on host file and the process start working but it throws me an error:
"The attempt to push data to the server has failed. (The message received from the server was: "111A01C0-27AE-414B-AC1C-DC56C83F877E"
The hosted file is on a fm server 15 that is reachable and working - I've tried the hosted link and it is correctly working.
The TRIP child table is set to add record (but not delete) on both files.
What should I check on it?
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!
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 had been using FM EasySync for few months now, so it had been working fine till now.
Without having any change in the table structure, i got the error " The attempt to push data into server has failed ( The mesage recevied rom the server was "852" )
852 Error is : Cannot write a file to the external storage
I believe this is related to container fileds I am using. There has been no change in the Container field options. They are still being stored "Externally" on the server with Open Storage option. Also there hasn't been any change on Server policies as well.
I have no clue as to what could have cause this. Anyone having idea about this ??
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!