Hampden Tech

Okay, the bug report has been sent. The strange thing is that regardless of which tenant I select on the spoke, the same tenant is always identified on the HUB, and this is not the first tenant chronologically.

The tooltip says that the HUB field cannot accept nulls but the Spoke (FM) database does allow nulls. However, all of these entries are supplied default values in the spoke table before syncing. If I'm not mistaken, any attempt to insert a record with null values in non-null columns prevents the record from being updated. The insert is taking place, but some of the values are not being updated.

I checked the config again and the columns seem to be mapped correctly. In addition, each tenant has a numeric account number. Through the debugger I was able to determine that the correct account number was assigned to the AccountNo field in the WorkOrder table on the FM/Spoke. When I synced, the matching column/field in the HUB record showed a zero for this value. Attached is the configuration for the WorkOrder table.

The primary key in the FM spoke is an auto-assign number and the primary key in the HUB (SQL Table) is an integer.

I could use another set of eyes on a problem I just discovered. I have a table, call it "Tenants" to keep it simple. On the HUB (a SQL Server DB) the primary key is pTenantID. On the FileMaker spoke the primary key is pk_TenantID. I have another table "WorkOrder" on both the hub and spoke which contains as a foreign key field, fk_TenantID to the Tenants table. When I do a sync to the spoke, all tenant records come over and are assigned PK's on the spoke. If a Work Order exists on the HUB, the corresponding tenant is properly assigned on the spoke, so if I view it on the FM datab

Yes, the version that I have is #9503 from 10/11/2017.

Yes, I believe so too. I received and installed the latest update and now it appears to be working properly. Thanks!

I occasionally get the following error when pasting the MirrorSync generated download link into the browser. "No db parameter was supplied. Pass a separate db parameter for each database to download." Usually I can get past this by simply retrying the URL, but this time, I cannot get past it. I tried recreating the download link but it still gives me the error. Any ideas on this one? Thanks!

I am using MS 4.x, and I have been utilizing the Database Version field in the MirrorSync table to alert users of an update. I have increased the version number, yet I do not get a prompt on the client to download the new version. This was working before but now does not seem to prompt. What should I be checking? Thanks!

Thanks for all of the hard work on this Jesse. The update seems to have solved the problem. Bob Hill

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,