Jump to content

Search the Community

Showing results for tags 'easydeploy'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Custom Function Library

Community Forums

  • Community Resources
    • Community Articles, Tips, & Techniques
    • FileMaker Marketplace Discussions
  • FileMaker Security Management
    • Security Concepts
    • Intellectual Property
  • FileMaker Server Administration
    • FileMaker Server 16
    • FileMaker Custom SSL Certificates
    • External Server Authentication
  • FileMaker Go & Mobile Strategies
    • FileMaker Go for iPhone & iPad
    • iBeacon Support
    • FileMaker IOS App SDK
  • FileMaker and the Internet
    • FileMaker REST API
    • FileMaker Cloud
    • FileMaker WebDirect
    • Custom Web Publishing
    • Other Internet Technologies
  • FileMaker Interface Features
    • Cards & Window Management
    • Interface Design Discussions
    • Layouts
    • Themes and Styles
    • Button, Popovers, Button Bars, SVG Icons
    • Tab and Slide Control Panels
    • Portals
    • Web Viewer
    • Conditional Formatting
    • Custom Menus
    • Value Lists
    • Tool Tips
  • FileMaker Schema & Logical Functions
    • Managing Scripts
    • Calculation Engine (Define Fields)
    • Custom Functions Discussions
    • FileMaker Query Language or FQL
    • Relationships
    • Charting
    • Remote Container Fields
    • Finding & Searching
    • Importing & Exporting
    • External Data Sources
    • Advanced & Developer Features
    • Reports, Printing & Publication
  • Brain Food
    • The Left Brain
    • Upgrading & Migration
    • Data Analysis
    • Development Standards
    • The Separation Model
    • Relational Database Theory
    • Damaged / Corrupt File Problems
    • OS Level Database Automation
    • Hardware & Networking
    • Bar Codes (Printer, Scanners, Software)
    • Accounting Solutions
  • FileMaker Discussions
    • FileMaker Pro 16
    • FileMaker Pro 15
    • Legacy FileMaker Platform Discussions
  • Geist Interactive Product Support Forums
    • Visit Geist Interactive
    • Visit Modular FileMaker
    • FMPerception
    • Generator
    • fmQBO
  • 360 Works Official Product Support Forums
    • 360 Works General Support
    • MirrorSync by 360Works
    • SuperContainer by 360 Works
    • ScriptMaster by 360 Works
    • FTPeek by 360 Works
    • 360Works Email Plugin
    • DocuBin by 360 Works
    • Zulu – FileMaker, iCal & Google Calendar.
  • FM Forums Affiliate Sponsors
    • SyncServer Pro by LinearBlue
    • Open Source Frameworks
    • Monkey Bread Software (MBS Plugin)
    • FileMaker Plug-Ins
    • ISO FileMaker Magazine
    • User Group Central - Sponsored by FMPug.com
  • FM Starting Point - By Richard Carlton Consulting
    • Visit FM Starting Point
    • FM Starting Point - General Discussions
  • FileMaker Classifieds
    • FileMaker Product & Service Announcements
    • Professional FileMaker Training
    • Services for Hire
    • Services Wanted
    • Solutions Wanted
    • Tools Of The Trade
  • The Water Cooler
    • Member Lounge
    • Wants & Wishes
  • FM Forums Operations
    • FM Forums Feedback & Site News
    • Site Instructions
  • FileMaker Platform
  • Forum


There are no results to display.

There are no results to display.


  • Samples
  • Solutions
  • White Papers
  • Plug-Ins
  • FMGo

Found 4 results

  1. Hi, 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
  2. Hi. 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
  3. EasyDeploy File Cleanup

    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
  4. It 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,

Important Information

By using this site, you agree to our Terms of Use.