Search the Community
Showing results for tags 'easydeploy'.
Found 4 results
Joshua Willing Halpern posted a topic in FM EasySyncHi, I have a db ~27Mb. Using EasyDeploy As Is takes very long to complete (~20 minutes). Each segment takes around 10 seconds and there can be anywhere 90 to 300+ depending on the $segment_size. I modified the EasyDeploy file by adding a table occurrence for the hosted file's EasyDeploy table and then replacing the script's loop with a simple Set Field that copies the B64 data from the host's field and decodes it locally into the container field. The new wait time is < 1 minute. Soooo... My question is why use this looped Get (ScripResult) method instead of simply grabbing the data through a relationship and then closing the EasyDeploy file when done? I have a hunch it has to do with Tim wanting to abstract the process as much as possible but I'm not sure. Maybe a relationship has other consequences? Josh
Joshua Willing Halpern posted a topic in FM EasySyncHi. I noticed that when using EasyDeploy, the new file will not pull records the client pushed just before updating. This is because the client will not pull records that have the same ES_Device_ID despite their ES_UTC_TIME being greater than the last sync timestamp of the updated file (file stored in 'database_container' on server's EasyDeploy table). i.e. Client A has version 1 and new version is listed as 1.1. Client A pushes a record to server and then updates his file with EasyDeploy The new file opens and does not contain any of the records created by Client A after the last sync stamp of the updated file. Even after syncing again, Client A does not have these records because the matching ES_Device_ID prevents them from being pulled. One solution is to append the ES_Device_ID field with the current version #. That way the device field in the above example would read <deviceID>1.0 for the pre-updated records and <deviceID>1.1 for any records created on the new file version. Since records with <deviceID>1.0 and <deviceID>1.1 do not match they will be pulled as if another device created them. A couple other things need to be changed to work: Create a field in EasyDeploy called EasyDeploy::Current_Version that stores the current version #. Update the ES_Device_ID field auto-enter calculation in all sync tables to Let ( trigger = GetField ( "" ); If ( IsEmpty ( $script_override ) ; Get ( PersistentID ) & EasyDeploy::Current_Version ; Self ) ) Update the 'EasySync Settings Client' script so that: $$client_version [ EasyDeploy::Current_Version ] Update the 'Pull Payload' script so that line 3 of $pull_parameters reads 'Get ( PersistentID ) & $$client_version & ¶ &' Update the 'Push Payload' script so that line 4 of $settings_info reads 'Get ( PersistentID ) & $$client_version & "</setting>" & ' To test it out. Save a new file version and update the database_container field on server (and increase the version number field). Then create a new record or two on the client and press sync. When prompted, perform the version update. After update check to see if that new record or two is missing (it should be). Sync again and voila they should appear. Do this same test with the existing EasySync and the records will not appear after post-update sync. Apologies for the long-windedness. I don't think this applies to everyone and a little extra description of the problem was required. Best, Josh
Hi Tim, I was wondering why you seemed to have backed away from deleting the EasyDeploy file once it has been used, and instead set a flag "consumed?" Did you feel that the "Export Empty to delete a file technique" was not reliable? Also, at the top of the Upgrade Solution script in the EasyDeploy file, you have an Installer OnTimer Script [Interval: 0] script step. That might be a left over from attempts at a 1-click update, because I do not see any previous OnTimer sets. Can you confirm? Thanks, Barbara
folks posted a topic in FM EasySyncIt seems like it would be possible, in the interests of maintaining a single code base, to configure EasyDeploy as a single database that could be renamed and the appropriate EasyDeploy layout container filled before deployment. That is, there is a server and client EasyDeploy table, they are different but with no similarly named fields so they could be combined perhaps. Likewise, with the EasyDeploy layout fields in both could be combined into a single layout. Deployment would start with a database where the helper file is in the appropriate EasyDeploy layout container. This is the client file. Copy the client file and call it the server file. The client file is added to the server file in the appropriate EasyDeploy layout container. The helper file can be removed from the EasyDeploy layout container in the server file, but likely will not cause any problem other than making the server file larger if it is left in place. Hopefully I have not missed an infinite regress in this merging process… Any comments are most welcome. Thank you,