Jump to content

joevmartin

360Works
  • Content Count

    29
  • Joined

  • Last visited

Community Reputation

1 Neutral

About joevmartin

  • Rank
    newbie

Recent Profile Visitors

1,667 profile views
  1. Hey MMHinSEA, I appreciate your concern. As part of the improved reporting feature, I will add that we should include a "Total time to complete" portion in the report. Thanks, Joe Martin
  2. Yes that should work. Before you run a deployment, be sure to duplicate your prod file on the prod server first, and according to this example, you would name it "RemoteDevFileA". If 360Deploy does not find a prod file matching the expected prod file name, it will deploy an empty clone, which I don't think would be desired in your case. Thanks, Joe Martin
  3. Hey MMHinSEA, To accomplish this currently, I would duplicate my prod file on my prod server, and setup a deploy configuration that points to the duplicated file. With a 360Deploy Express License, you can deploy a single dev solution to a single server, but as long as the dev file name does not change, the prod file name can change. So you could set up two different configurations that use the same license key, the same dev file, and the same prod server, but different production files. Thanks, Joe Martin
  4. Hey MMHinSEA, I will update the documentation to make this clearer, but if you want to schedule deployments, we recommend you host the 360Deploy database on your Dev server, and schedule the migration using the FileMaker script scheduler, which will allow you to pinpoint an exact date and time you want the migration to run. In my own setup, 360Deploy is hosted on my dev server, and I open the file remotely to manage and trigger deployments. With the file open remotely, I don't need to remote into a workstation to open the file. As to the pros and cons, I prefer having my file hosted on a dev server so I can take advantage of the features of FileMaker Server (backups, server side scripts, etc). In the end, there is little difference when actually using the file, and if you have a strong preference to keep the file local it should work fine. If you want to manage the 360Deploy file from multiple computers, having it hosted on your dev server will help with this as well. Thanks, Joe Martin
  5. Hey MMHinSEA, To describe your screenshot, this shows that 0 databases have a completed migration, and there is 1 database where the migration is not complete. As the files are migrated, the databases will move into the "Migration Complete For Databases" section. We are working on better reporting of the migration process, and I expect this to be included in a future release. It will be very hard to anticipate the length of the migration, mainly due to the fact that the migration tool makes the call whether to migrate the databases in "block" mode (really fast) or "record" mode (slower, but still fast). "Record" mode migration is triggered if there is any field definition changed in a table, and can result in a table taking a lot longer to migrate, relatively. We could potentially analyze the schema differences between dev and prod and guess at which mode the migration tool will use, but this is not a high priority feature for us now, and would involve a good deal of work to get working correctly. Thanks, Joe Martin
  6. Hey MMHinSEA, You are not required to have a FileMaker Developer Subscription. We are embedding the migration tool inside of our application and it is used behind the scenes, but you do not have to purchase it. Thanks, Joe Martin
  7. Hello MMHinSEA, Are your dev files hosted on a server? If so, the scripts are not necessary. The scripts are only used to create clones of the dev files when the dev files are local. If the dev files are hosted, we can ask the dev server to provide the clones, and no scripted cloning process is required. If your dev files are local, the 360Deploy Dev Server configuration detects if you are using a file path instead of a host name for your dev location, and provides you the option of copy/pasting the scripts, because that is the only case where they are required. Thanks, Joe Martin
  8. Hey Duane, We were seeing similar errors with 360Deploy when only one of the migration zip files was stored in the 360Deploy FileMaker file. We have fixed that issue in the latest development build, available here: 360Deploy 2.006.zip If that link doesn't work, try this one: http://s3-external-1.amazonaws.com/com.prosc.support.uploads/Outbound/360Deploy%202.006.zip?AWSAccessKeyId=AKIAIDQUCQL7APZLJCDA&Expires=1534002521&Signature=WVHeTjyCUMRpAYPtTupkvHk183o%3D If you are still having problems, feel free to reach out to our support team at: support at 360works.com Or give us a call at: (770) 234-9293 Thanks, Joe Martin
  9. pfroelicher and I worked this out, this was an issue confined to a developer build of Zulu, this should not affect anyone using the store version of Zulu.
  10. 360Works Support here, We were able to identify the issue, this time OS X Server was completely innocent. There was an exception thrown when trying to read registration info from a preferences file. It's likely that a bad install of Zulu cleared this registration info, but not completely, leaving it in an unknown state. When a later installation tried to load the info, it would fail and Zulu would never start. This fix will be pushed to the store within a few weeks, and the issue itself is rather rare and I doubt anyone else will run into this in the meantime, but if you think you are experiencing this issue, or one like it, email us at: support@360works.com
  11. You will need to re-publish your calendars, and reconfigure them in the Zulu admin console, as the process for this has changed. If you want to take advantage of adding attendees to Google events, you will need to map those fields on your field mapping layout, but these are optional. I would download the demo, and install it as a hosting provider so you can test it out before replacing your production version of Zulu
  12. We set up a Google Developer Account, which is necessary to leverage the Google Calendar API. They give you a quota limit, i.e. number of requests you can make per day against their Calendar API. We had to request and increase to this limit as Zulu began to get close to hitting it.
  13. The official place for Zulu support is our internal support ticket system. You can open a new ticket by going to the Zulu admin page, and clicking the "Email Log File" link. This will send in your logs as well. We will take a look and get back to you as soon as we can.
  14. If there were no more software updates to Zulu from this point forward, it would continue to work as long as Google did not shut down Calendar API V3. There is currently no mention of Calendar API V4, and V3 will probably be good until V5 is released. So Zulu will work in its current state for a while. Furthermore, we are a small, but strong company with no intention of going anywhere. We have been around for almost 20 years, and we plan to be around for much longer. Zulu is one of our main products and I expect to see continued development on it as long as we are in business.
  15. Halburn, Sorry we missed your post on the 16th. We try to stay on top of these forums, but our internal ticket system is where we focus our primary support. To open a ticket with us and send in your logs, Go to the Zulu admin page, and click the "Email Log File" link. We will take a look at the logs and get back to you as soon as we can
×
×
  • Create New...

Important Information

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