In the last two weeks, on at least three occasions involving two shared databases, a user added a record but it was not on the server when other users tried to access it. The users were instructed to use Download Data, which removed the record, as expected, then added it a second time. I have very little info about events surrounding the addition of the record, except they were all done by a procedure that has worked correctly hundreds of times.
Given the little information I am able to provide, I don’t expect a substantive response. But if it’s happening to me, it will probably happen to other users.
Hi Jim, yesterday I said during the Server training that we had experienced users adding a record that did not get onto the server. Here is my post from two weeks ago about this issue. Unfortunately, the way I learn about it is several hours later or the next day, so I have not been able to get any useful information from the user who added the record. I will be very interested if anyone else reports this kind of occurrence. But they will have to have other users using the same shared database, and I suspect that is not the case for most of the people in the class.
I know it’s an edge case, but something to be concerned about. The fix of re-downloading the server data and re-entering the missing local data is great, once you’ve discovered that the data is missing… but, what about all the other things that might be messed up by this? IE CS enters an invoice and by doing so reduces inventory in another db. Shipping prints out the invoices for the day…but, one of them somehow did not make it to the server and does not print out. Now, inventory is off, a customer does not receive their order and it’s invisible until they call or write. Re-entering the invoice will get it back in the system, but you then have to adjust all the other data that might now be duplicated or incorrect. I used to run checksynchronization in critical procedures to make sure; after having this issue a few times in v6 and it saved me much hair pulling. Not something you’d want to run all the time, but for critical data entry situations it sure would be nice to have a way to be proactively positive that the data in the local and server do indeed match before changing other data downstream. Also, a way to ID the mismatched records and choose the correct ones would be nice, but just knowing there is a mismatch is the first step. I’d love to trust that this will just work perfectly all the time, but the real world cares not…trust and verify has always been a good model, belt and suspenders makes sure the pants stay up… 
So, I’d love to eventually see checkcynchronization return, or something to replace it. Or perhaps there is something that replaces it that I’ve not learned yet?
Your statement of ‘re-entering the data’ is fine for when the information might be on a form, but in my world, the physician’s attendent is taking vitals, noting symptoms, entering history, etc. Once that patient has moved on, there is no ability to go back and determine the data, other than having a group of patients returning to the office for a 2nd try. Re-entering the data is not a good option.
Agreed, thus my desire for an easy and simple way to verify the data entry makes it to the server at the time of entry… but, preserves any local data that did not…and allows that data to be “forced” to the server. Rather than overwriting that data with a download from the server.
I estimate about a 1% occurrence starting in April 2020 in one particular database. (Another database with far more records has not been found to suffer this problem.) There have been a lot of changes to 10.2 since then, and the incidence rate may be lower, but the most recent occurrence was January 13th. I provided some detail about how we have responded mainly to demonstrate that I am 100% confident of my assertion: that a record was added to a shared database but did not get onto the server. I have no working hypothesis about how this happened, but I do not mean to minimize the seriousness. The particular database error will certainly be discovered and can be corrected. But I am sure there are many situations where the omission will escape detection and could not be re-created accurately even if it were, one of which Richard refers to.
I think one might be able write code to test for the presence of a record on the server using the Serveridrecord field (caution is needed because this value changes with new generations) or using the Automatic Record Numbering feature. I just need this issue to occur again so I can explore these possibilities. (I don’t know any way to cause this to happen.)