Dotmim.Sync
Dotmim.Sync copied to clipboard
Synced image file goes to wrong user
We've had an issue where a customer printed an invoice with another customer's letterhead. The letterhead is stored as a Base64 string in the Pictures table on the client and the server.
Our users are companies. Each company has it's own database on our SQL Server. We sync 42 tables for each company via our web api. We currently have ~500 companies syncing their data ... customers, orders, stock etc
The SQLite client table implicated
CREATE TABLE Pictures (
PictureName varchar(15) NOT NULL COLLATE NOCASE CHECK (length(PictureName) <= 15),
PictureFile varchar COLLATE NOCASE,
PRIMARY KEY(PictureName));
The SQL Server table implicated
CREATE TABLE [dbo].[Pictures] (
[PictureName] VARCHAR (15) NOT NULL,
[PictureFile] VARCHAR (MAX) NULL
);
GO
ALTER TABLE [dbo].[Pictures] ENABLE CHANGE_TRACKING WITH (TRACK_COLUMNS_UPDATED = OFF);
The Pictures table has only 1 row with PictureName='Letterhead' and PictureFile the Base64 string representation of the image file.
On the server we have Dotmim.Sync.Web.Server 0.9.1 and Dotmim.Sync.SqlServer.ChangeTracking 0.9.1 On the client Dotmim.Sync.Sqlite 0.9.1 and Dotmim.Sync.Web.Client 0.9.1
DMS syncs thousands of orders every day without mixing up user data. Sync passes an Authorization header. We don't use static classes on the server. Pictures is just another table synced like any other.
The user who got the wrong letterhead did not normally use a letterhead ie PictureFile was null. When the issue was reported their server database still showed PictureFile = null.
Any thoughts on how DMS sync could work so well so often yet this might happen?
No idea. Did you had the bug once again ?
This same issue has not recurred, but from time to time (rarely) we do hear that the wrong company has got a few rows of another company's data intermingled with their own data.
We sync data from ~500 companies, each to their own database on our server. We see ~10,000 syncs per day. We hear of this issue about once per month ie once in ~40,000 syncs.
Each time it has been reported we also see a user device crash in our server logs from either the company which owned the data or the company that got the wrong data.
It's rare, but very worrying.
I worked a lot on the new version to be sure everything is separated. The migration can be tricky, let me know if you are able to migrate correctly (test it before going into production) Once you have migrated, let me know if things have changed