Lock is requested successfully, but syncstat is out of sync" Sage 50 error
This Sage 50 message means the program's internal synchronization status disagrees with its file locks, usually after a crash or network fault.
The message reads: “Lock is requested successfully, but syncstat is out of sync.”
Despite the wording, the lock is not the problem. Sage 50 asked for exclusive access to part of your company data and got it. The failure is in the bookkeeping around that access: the program’s internal synchronization status no longer matches what it just recorded. In plain terms, the software caught itself in a state it did not expect, and it is refusing to continue because writing data now could corrupt the file.
What the message means
Sage 50 keeps a small status record that tracks which workstation holds which lock on the company data. When that record disagrees with reality, the program stops. The message is a safety halt, not a lock failure.
It usually appears when opening the company, during a backup or verification, or when a second user tries to enter the file. It can also appear at year-end close or while posting a batch.
Why it happens
The most common triggers are an interrupted session and a multi-user setup on a shaky network. If Sage 50 was closed abruptly, a power cut hit mid-write, or a mapped drive dropped during use, the status record can be left half-updated. On networks, timing problems between the workstation holding the data and the machine accessing it produce the same mismatch.
Less often, the underlying database is already damaged, and this message is simply the first visible symptom.
What to try first
Restart every workstation that runs Sage 50, not just yours. Make sure nobody has the company open, then reopen it as the first user. This clears stale locks held in memory.
If it recurs, check the network basics: the connection to the machine hosting the data, the mapped drive, and whether the same error appears when the file is opened locally on that machine. If it does, the problem is in the data, not the network.
Restoring from backup
If you have a recent backup, restoring it is the safest route once the error repeats. You will lose anything posted since that backup, so weigh that before you commit. Keep the damaged copy untouched; do not restore over it.
When the file needs professional attention
If the message persists after a restart, or the file will not open at all, the synchronization record inside the database is likely damaged. There is no safe user-level fix for that, and repeated attempts to force the file open can make things worse. Our engineers repair damaged Sage 50 and Simply Accounting databases directly, and we can assess what is recoverable before you commit to anything. See our Sage 50 database repair service for a free evaluation and quote.
If the file is recoverable but you were already planning a move, we also handle Sage 50 to QuickBooks conversions, which can be done from a damaged copy in many cases. The right path depends on the file, and a free evaluation settles that quickly.