Hampden Tech

I'm just following up to see if there are any updates on this issue. If this is a bug, are there any workarounds? At this point, our project is on hold because we can't release this if we are unable to create new records on the FileMaker Go spoke up and then sync with the MS SQL table on the hub. Thanks!

Hi Jesse, Any updates on this issue? Thanks! Bob

Hi Jesse, Yes, I got your response. I'm checking on it right now. There is a column in the SQL table that is being inserted as a null. It is a nullable integer so NULL is a perfectly valid entry in SQL, albeit not the best approach. I'm thinking that in the select statement, the null is throwing off MIrrorSync. I have added this field to the sync layout and will make sure it is populated with an integer in the FileMaker spoke to see if that does the trick. I'll let you know. Thanks for your prompt response to this!

Hi Jesse, Okay, I have submitted the ticket from the MirrorSync launch page with information about the issue. The ticket is HD-37158. Thanks! Bob

I am seeing an error after syncing when I have a new record on the spoke (FileMaker DB) to be synced into a Microsoft SQL server table on the hub. The MirrorSync setup uses a custom primary key to do the insert into the SQL table. According to the sync window as well as the sync log, the insert fails. However, when I review the table in SQL Server on the hub, the record has indeed been inserted properly. For some reason, MirrorSync is reporting this as an error. In addition, MirrorSync does not seem to remember the PK of the newly inserted hub record so if I do another sync on the spoke, it inserts it again. If I run the sync 3 times, I will have 3 new records inserted. This is the error that I see in the log. No further information is available. table Hub node MS SQL Server/KeyPhrases failed for source nodeId '275' This also happens on another table as well. Is this a bug in version 4 of MirrorSync or is there some configuration step that is missing? Any help would be greatly appreciated, as this is preventing us from releasing this solution to production. Thanks!

Outstanding! That worked like a charm. Thanks for the help!

Thanks for the quick reply Jesse. I just checked this out. Is that an open SQL query where any SQL can be executed? Can you give me an example of what type of SQL statement you could use there? Thanks! Bob

I have a situation that is causing me some issues. In my MirrorSync configuration I am able to download data from the HUD, make changes in the spoke DB and then sync back up and the changes are properly reflected in the HUB (Microsoft SQL) database. However, I tried to add a new record on the spoke DB and when I did a sync operation, the error on the HUB indicated that the primary key field could not be null. We manage the primary keys in our SQL database ourselves, so the next number for each table is stored and updated within the DB. MirrorSync must be expecting that our HUB table is using an Identify column to set the primary key. There is no way that I see of specifying the primary key value in the HUB database. In other words, if I could match up a value in the spoke DB with the primary key and then insert it, I could use an insert trigger on the HUB database to catch this and then assign it a new number in sequence. For example, I could setup a new field in the table called "Temp PK" and set it to some magic number like "999916". Then, I can trap for this on an insert trigger in SQL and assign it the correct way. The only issue that I see with this is that 1. I'm not sure how MirrorSync will be able to match up this new HUB PK with the Spoke PK, and 2. I'm not sure if there would be any conflict issues with multiple users syncing at the same time Any advice on how to work around this would be helpful.

Is there a log file or files that I can view to determine explicit SQL errors? For example, I'm getting a "data would be truncated" error during the sync which points me to the correct row of the table in question, however, I can't tell which column/field is causing the problem. It would be helpful if this was logged. It's possible that the SQL error itself does not state this, but I'd like to see the logs if available anyway. Thanks! Bob