Without knowing the specifics of what MobiLink server is reporting, I am reluctant to advise next steps. Certainly, you can reset the remote if that is the appropriate action. See ml_reset_sync_state system procedure. Please read and understand what this does before using it.

The point I was marking with respect to a recovery is that if there have been synchronizations since the point in time of the database that has been put into the system, those remotes will no longer be able to sync without some intervention. This is not ideal. I take it that the database that was put back into production was not restored to the point in time of the hard drive failure. If so, there will likely be remotes that cannot sync if they have sync'd at a time after that restore point i.e., you have lost the sync status that synchronization uses to ensure data consistency between the remote and consolidated. You can reset the sync state to force that remote to synchronize.

Your log suggests that the reset procedure in theory should work with the affected users.

Please hold off on the use of ml_reset_sync_state. We are looking at options on the remote.

Please note that this is really a salvage because data has been lost at the consolidated - the data might simply be related to the current sync state of affected remotes or could extend to data that should be in the consolidated and may no longer exist on the remote. Given the flexibility of the scripts that are used for synchronization, MobiLink would not be able to determine what rows should look like - that is left to the consolidated and its recovery gear. This is not a defect in design. It is reasonable that MobiLink expects that the consolidated database is capable of recovery with no loss of data. That did not happen in this case.

You need to now decide 1) Is there data on the remote that may be important to the application and efforts should be made to get that data into the consolidated? If so, this may be a manually effort for the affected remotes. -or- 2) Are you willing to lose that data? If so, options include resetting the remote status or recreating those remotes by sync'ing the database from an empty state - in that case, keep the existing remote as you may be able to manually re-enter the information that exists only in the remote.

You may want to work with technical support to go through the details if you are not familiar with MobiLink.

The design is not insane and the product is not worthless.
Operating it without an administrator who has the required skills and understanding .is. insane. This is probably not your fault, but it is one. If you get out of this with the help from somebody, you're still left with a system that, in the best possible situation, works, and you don't know why.
It is mandatory and critical that a node in a system of communicating databases is restored to a point where no communication with another database is missing. This is particularly critical for any consolidate database which communicates with all other nodes. All supported MobiLink consolidate platforms have mechanisms to achieve this, depending on the failure scenarios you need to cover and the infrastructure required to implement the required countermeasure. Determining this requires solid knowledge (not at rocket science level) about the way MobiLink works and the administration of the consolidate database.
I wish you good luck that somebody here or from TechSupport can help you out of this. If anybody can, Chris is a hot candidate. Whatever will be the outcome of this crisis, I highly recommend that you go to your manager and insist that you and probably somebody else get trained on the subject. If [s]he compares the cost for such a training with the risk of not having somebody available with the skills to handle a crisis, [s]he will be responsible for the decision.

Just my €.02...

Volker