Jesse Barnum

I think that would work... you'll need to put them back every time you want to edit the configuration though.

Yes, this definitely sounds viable. The primary issue to be aware of when using MirrorSync to integrate FileMaker Server with Wordpress is that the schema needs to be similar. 1 table in Wordpress / MySQL needs to correspond to 1 table in FileMaker: You can't split or merge the sync so that 2 Wordpress tables are synced to a single FileMaker table, or vice versa. Pricing for this is $1,800. Contact charis@360works.com if you'd like to arrange a 30 day trial license key.

I didn't know about that limitation on the developer server. Give it a try. I doubt it's legal to use FMS development server license for live deployment, even if it does technically work.

Hi Bob - I responded to your ticket, just want to make sure you get it.

I will need to see the log to make a guess as to what is happening. Could you repeat the problem and then submit a problem report from the mirrorsync launch page? This will attach the server log file.

OK, I see what you're saying. To do what you want, the best thing is going to just simply be copying and pasting that section of the MirrorSync script into a separate script that you run manually. You'll find this towards the end in the sync finished section of the script.

I haven't actually tested this, but it seems like this could be accomplished with these steps: * Change the DatabaseVersion field from a calculation to an auto-entered calculation * For your developer script in the offline file, change the database version to '0' and then run the script. '0' will be different than whatever version is on the server, so it will trigger the update to run.

Here's an example from another customer. I'm not an expert at SQL Server syntax, but I think anything that ends with a SELECT statement will work: DECLARE @newaccountid char(12) EXEC [sysdba].[GenerateSLXId] 3, @newaccountid OUTPUT; SELECT @newaccountid;

This is only the second time I've ever come across this issue, but fortunately we solved it for somebody before you, so you can use the same solution :-) In the screen where you select the primary key, check the box that says 'Custom PK.' Whatever a new record is being inserted into SQL Server, this SQL statement will be executed, and the result will be used as the value for the primary key. Use the MirrorSync-managed primary key option in this case. That will make it so that the same record can have different primary keys for different devices / databases, and MirrorSync will keep track of that.

http://s3-external-1.amazonaws.com/com.prosc.support.uploads/Outbound/360Works MirrorSync 2.6009.zip?AWSAccessKeyId=AKIAIDQUCQL7APZLJCDA&Expires=1506267898&Signature=3bn13j3Z9Kx5p8RcEW0oVSYOWwk%3D

The existence of a record in the MirrorSync table does not necessarily indicate that a sync has occurred. There are two cases that I can think of off-hand where this is not true: 1) If you downloaded a full copy of the database (as opposed to an empty clone), then it is normal for there to be a record where type='hub' and another where type='server' 2) If you downloaded an empty clone, but the first sync failed for some reason, such as a network problem, there will be a record in the MirrorSync table. The safest way to tell if a sync has occurred is to look in the MirrorSync table for a record where type='client' and see if the lastClientToken field is not empty. That would indicate that a sync has occurred.

Woud it be possible to send me an offline file so that I can try the sync myself and see what happens?

I don't understand the issue, could you provide more explanation?

Can the sync be one-way from spoke to hub? In that mode, MirrorSync never deletes anything, on the hub or the spoke. If not, then the next time it occurs, file a problem report with the primary key of at least one record that was incorrectly deleted and we can check into it. Usually, incorrect deletions are due to problems with the MirrorSync customization script.

Sorry Mark, I'm still catching up from DevCon backlog. If you're running MirrorSync 3.17 or 4, then the cancel function should be pretty reliable. However, it can take up to 30 seconds to work, because we wait that long for pending write operations to complete before we force the sync to stop. If it takes longer than a minute for a sync to cancel, contact our support team so we can figure out why.