Jump to content

seankuhn

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0 Neutral

About seankuhn

  • Rank
    member

FileMaker Experience

  • Skill Level
    Beginner
  • FM Application
    16 Advanced

Platform Environment

  • OS Platform
    Mac
  • OS Version
    High Sierra 10.13.4
  1. Hi Joel, iOS 12 and Mojave require that CalDAV accounts connect over SSL, so when you make your account, enable SSL. Also, make sure your server is open on port 443. A default FileMaker Server install usually allows that anyway, but if you're implementing a network gateway, you'll have to make sure you have the proper port forwarding set up.
  2. Hello, Sorry for the late reply. Next time you boot the instance, can you send us the logs? You can find them in the following directory: Mac: Library/360Works/Applications/Logs Win: Program Files\360Works\Applications\Logs The logs I'd like you to find will be called "Zulu.[date].log", "catalina.[date].log", "manager.[date].log", where the date is the day you produced the issue in the format YYYY-MM-DD. When you find the logs, e-mail them to us at support@360works.com. Once we receive them, we'll take a look at what's going on and get back to you.
  3. Hello, Currently, we have our plugins installing java in the User directories on MACs because there tend to be permissions hurdles that are resolved when an instance of java exists there. We're currently working on builds of our plugins, including ScriptMaster, that can implement java installed in a ROOT directory. I'm sorry this isn't available now, so check with us or our store at a later date for versions of our plugins with this capability. Also, just in case, here's a reference link for manual java installations on our recent plugin versions for MAC. http://docs.360works.com/index.php/Common_issues#Plugins_released_on_or_after_May_2017_fail_to_load
  4. seankuhn

    unhelpful error message dialog

    Hi John, If you're still running into this issue, please try applying the built-in ScriptMaster functions SMLastError and SMLastStackTrace trace, which can be called right after a plugin error occurs to return more information on the error that occurred. Documentation for these functions can be found at the following link. http://static.360works.com/plugins/SCRIPTMASTERPLUGIN/documentation.html#SMLastError You can also take a look at the log files that may have captured this information. Reference the following link to find the location of those log files. http://docs.360works.com/index.php/Plugin_log_files If you'd like me to take a look at the logs, you can e-mail them to support@360works.com. We'll take a look at the logs and reply back through the same e-mail thread. Sean Kuhn 360Works Support 770.234.9293
  5. Hello! Zulu employs an instance of MirrorSync 2 to execute the sync, and it appears to be running out of memory. Are you still having this issue? If so, try the solution at the following link to increase the memory allocation. http://docs.360works.com/index.php/MirrorSync_4_advanced_topics#OutOfMemoryError
  6. Hello, We have a build which employs our new Zulu Google API acct so that syncs won't be hitting the quota limit. I'll shoot you a link to download it via messages. Let me know if you received it.
  7. Hello! We had to change accounts registered for using the Google Calendar API, and are also working to increase the Google request quota limit to address this issue. We're currently waiting on a response from Google. I apologize for the delay. Sean
  8. seankuhn

    Migration to a new server

    That could possibly work. You probably already know this, but just in case, you'll want to decrease the TTL when you make the address change to a domain name so the propagation step doesn't cause a lot of downtime. Another step I forgot to mention is, while you make the change to the domain name in your MirrorSync configuration, you'll need to delete the database's MirrorSync external data sources before you copy the new MirrorSync scripts into the file.
  9. seankuhn

    Migration to a new server

    Conducting a hard stop on syncing to move the database to a new server would be the simplest and least risky method, and it would not require any new license/configuration purchases. I would recommend doing the following: To reduce server downtime, you can set up your new server with a 1 sync device configuration at no cost. Do this to test your new configuration so integrating the database over to the new server goes more smoothly. Once you have a successful configuration on your new server, have all users perform a final sync to update the database, and then close out of their files. When all users have done so, copy the up-to-date database file to the new server. Step the file through the MirrorSync configuration client you already created on the new server to make sure there are no discrepancies. Copy the scripts into your database file, then you should probably test a sync to make sure everything is working properly, and distribute new offline copies to all of your users. I hope this information helps, and let me know if you have more questions!
  10. seankuhn

    Migration to a new server

    Hello! Before I can answer your question, I want to verify exactly what you're trying to do. You have a server with 50 users syncing to an old IP. You want to transition the database and all users on that server to a new server with a new address, and eventually discontinue the old server. Is this correct? I'm assuming you do not have anything setup on the new server for the database in question. By smooth transition, do you mean you would like to allow users to continue to sync throughout the transition instead of doing a hard stop on syncs while the new server is getting set up? Specifically, do you want two servers hosting their own instance of the same database, and have the host files sync with each other until all users set up their machines to sync with the new server? Also, do you want to increase the total number of users allowed to sync with the database, as well? To clarify, in your example, there are two separate groups of users syncing. 50 users are currently syncing on the old server, and 50 new users will be syncing on the new server once the database is hosted. When the transition is complete, the 50 users who were syncing on the old server will join with the 50 others on the new server, making 100 users in total syncing with the new server. You didn't mean 50 users syncing on the new server as just available license space for the original 50 to occupy. Is this correct?
×

Important Information

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