Płatnik, Optima and Subiekt after database failure — which do not do before diagnosis...

If, after a computer, server or disk failure, the accounting program suddenly does not open the database, the worst decisions are usually made in the first minutes. The time pressure is increasing in the company and someone just wants to get the system back on track. In the background then there are ideas for instant interference with the database, copying MDB/MDF files without consistency control or rebuilding the environment without checking what has really been damaged.

When the problem looks like a program failure, and it really starts with a storage device

Płatnik, Optima and Subiekt are often the first place in which the company notices the incident, but they are not always its source. If there were suspensions before, input/exit errors, disappearing directories, slowing down or rebooting after the power loss, it is equally likely to damage the disk, controller, array or SQL environment itself.

In practice, the most dangerous are situations where someone assumes that the problem is only about the program file, and starts to move the database between positions, run modifying procedures or overwrite existing files with a new installation. Such movement may impede later retrieve and repair the database Or completely erase the trace needed for diagnosis.

What not to do before diagnosis

• Do not run CHKDSK or any other file system modification procedures on the base media.
• Do not copy database files test between damaged and new environment.
• Do not update your accounting program unless you have confirmation that the database and media are consistent.
• Do not restore backup to the same damaged disk to force the environment to start.
• Do not run multiple attach/repair attempts on the same base if the source of the problem can lie in the disk or SQL.

How to gather the information needed for a reasonable diagnosis

Before you file a case, make a list of facts instead of hypotheses. The most useful ones are: program name, system version, database type, exact error message, last moment of correct operation, backup information and whether the problem concerns a single position or the entire company.

It is also worth saving immediately where the files are physically located: on the local SSD, on the server, on the NAS, in a virtual machine or on a shared resource. For accounting offices and financial departments it is often more important than the error message itself, because it allows to distinguish the application failure from infrastructure failure.

Symptoms that suggest a disk or environment problem

If, in addition to a program error, RAW, disappearing volumes, CRC errors, unusual HDD sounds, or file system modification messages appear, you must first treat the incident as a storage device problem. In such cases, see the guides to disk failure involving accounting data and the first 24 hours after a server or NAS failure.

Backup is not all if you don't know if it's coherent

In many companies there is a belief that if a backup exists, it can be restored immediately. Problem is, after a disk or server failure, the backup can be incomplete, old or logically inconsistent. This applies in particular to situations where copies were made during the program or without a playback test.

It is therefore worth answering three questions before the restoration decision: on which day is the last certain copy, whether it covers all components of the program and whether it can be activated outside production. If the answer to one of them is "I don't know", it's not worth doing further operations on a damaged environment without consulting.

What a safe B2B procedure looks like after such an incident

In practice, the good path consists of three layers: environmental protection, storage-device and database diagnosis and then the decision to repair or recover. For companies, it is also important who has access to the data and how actions after the incident are documented. When there are customer or employee data in the database, you also need to think about confidentiality and the NDA from the beginning.

If the case concerns multiple positions, accounting processes or personnel data, a reasonable direction is a parallel transition to the website for accounting and accounting offices and preparing one incident owner on the company's side. This significantly reduces chaos and reduces the number of risky decisions taken in parallel.

FAQ before contact

Is it possible to recover the base if the program stopped opening after the reboot?

Yes, but first you need to determine whether the problem concerns the database itself, the file system, disk or SQL Server. Without this diagnosis, it's easy to make things worse.

Can you immediately restore the backup?

Only if you're sure that the copy is consistent and that you're restoring it outside the damaged environment. Otherwise, you may be wasting your time and overwriting important tracks.

When do you need the NDA?

In B2B environments with accounting, personnel or clients, it is worth to determine this even before transferring the storage device or working copy.

When to go from analysis to description of symptoms

If you are not sure whether the problem lies in the database, media or server, and at the same time the company cannot wait long, it is not worth to multiply the production trials. Safest to collect symptoms, indicate critical directories and go to laboratory contact. In strictly bazodan cases, the right path is database repair and recovery service and, if the incident affects the entire organisation, also B2B path for companies.