Database failure — what to do immediately so the situation does not get worse

When a database such as Płatnik, Optima, SQL or Subiekt stops opening, the worst thing you can do is run repeated "repairs" and restart it over and over again. Very often the problem is damaged database files, drive errors or lack of free space — and each additional attempt can write new corrupted data.

If possible, stop working on the computer or server and secure a copy of the current database files. In companies, the most common scenarios are drive failure, controller errors, a power outage or a failed update. The good news is that in many cases it is possible to recover the data or restore database consistency.

In the laboratory, we first create a safe image of the storage device and only then work on the copy. This reduces the risk of losing what remains of the data. If you urgently need settlements or declarations, mention it in the case form so that we can set the priority correctly.

  • Stop all write operations to the drive. Do not install anything and do not move files "just to save time".
  • Do not run multiple "repair" attempts and do not overwrite older database files with newer ones.
  • Save the error messages, for example as a screenshot — this is often crucial for diagnostics.

How to tell whether the problem is in the database or in the drive (without going into technical detail)

If the computer suddenly slows down, files take a very long time to open, or copy errors appear, that is often a sign that the problem lies in the storage device rather than in the application itself. On the other hand, messages about a "damaged database", missing table access or consistency errors may result from an interrupted write operation, for example during a power failure.

In practice, the safest approach is to treat the situation as a potential data failure: do not generate new writes and preserve the current state immediately. This gives us the best chance to rebuild the database or recover working copies without losing additional records.

  • Do not reinstall the system "quickly" — this often overwrites files and logs.
  • If you have backups, do not restore them to the same location without consulting us first.
  • In your case submission, include the name of the program (Płatnik / Optima / Subiekt / SQL) and the date of the last successful launch.

Facing a similar database or company system failure?

If Płatnik, Optima, SQL, Subiekt or another business system stopped working after a disk error, RAID issue, virtualisation problem or damaged database files, avoid random repair attempts. Incorrect actions can overwrite logs, break consistency and reduce the chances of a safe recovery.

See the most relevant recovery paths for this type of incident:

How to prepare files, logs and the environment for a database diagnosis

In database-related incidents, the most valuable assets are not only the .mdf, .ldf, .db files or working copies themselves, but also the context: the application name, system version, the last known-good moment and the exact error messages shown by the console or program. This helps distinguish a database failure from a wider problem with the environment, the drive or the virtual machine.

If you still have backups, SQL Server logs, the application folder or an export from the last working day, do not overwrite the original files with them. The safest approach is to preserve the current state first and only then decide on the next diagnostic step. In accounting, payroll and business cases, the biggest risk is often not the database itself, but a chain of rushed repair attempts.

  • Write down the program name and database version: Płatnik, Optima, Subiekt, SQL Server, Access or another business system.
  • Keep the exact error messages, the date of the last successful launch and information about any attempted repair, restore or migration after the incident.
  • Do not reinstall the application and do not replace database files without keeping a binary copy of the originals.

Which files and details actually speed up the diagnosis

In practice, diagnosis is much faster when the database comes together with basic context: the folder structure, server logs, usernames, the last correct write time and information about whether the failure happened after a power outage, drive error, system update or ransomware incident. Without that context, we first need to rebuild the incident timeline and only then diagnose the logical or physical damage.

In accounting and ERP systems, seemingly small details also matter: whether the database was stored on a server or a single workstation, whether it ran from a network share, whether somebody copied files while the application was still live, and whether a manual index or consistency repair was already attempted. Those details can determine whether it is safer to work on a logical copy, a full media image or directly on the database structure.

What not to do after a database error

  • Do not run several repair tools one after another just to see whether something starts working.
  • Do not restore older backups over the same production files without preserving the original state.
  • Do not compress, move or reattach a damaged database between computers without keeping a binary copy first.
  • Do not assume the issue is purely software-related if there were drive errors, power loss, freezes or RAID/NAS problems beforehand.

If the issue affects a production environment, secure what exists right now: current files, the application folder, logs and the storage itself if needed. Only then decide whether this is primarily a case for drive data recovery, RAID or server recovery or strict database repair. In many companies, a database failure is only a symptom of a larger storage problem.

When contacting a laboratory makes the most sense

If the application stopped opening the database after a power outage, the system reports read errors, the server disappears from the network or the files suddenly have abnormal sizes, it is safer not to run more operations on the original environment. This is especially true for Płatnik, Optima, Subiekt and SQL-based environments, where the damage may affect both the logical structure and the storage underneath it.

If you want to organise the broader business context first, also see our materials about data recovery for businesses, drive failure with accounting / HR data and GDPR and the first 24 hours after a server or NAS failure.

How should you prepare files and information so database repair does not take longer?

With database cases, not only the file itself matters, but also the incident context. It helps to note the program name, system version, the exact error message, when the problem first appeared and whether updates, a server restart or a backup job were running at the same time. For systems such as Płatnik, Optima, SQL Server or Subiekt, those details help assess whether the failure is logical, file-based or related to the storage layer.

If backups, logs or earlier versions of the database are available, secure them and avoid overwriting the originals. The same applies to exports, archives and local working copies. The fewer chaotic attempts are made on the live environment, the higher the chance that database recovery and structural rebuild will be faster and safer.

When is the database issue logical, and when can it mean underlying media failure?

Not every database error means physical drive damage, but some scenarios clearly require that possibility to be considered. If application errors are accompanied by delayed write warnings, copy failures, system freezes or disappearing files, the root cause may go beyond the database engine itself. Continuing to work on the same storage in that state can increase the damage and reduce the chances of a clean recovery.

In practice, it is worth comparing the case with scenarios described in Drive failure with accounting / HR data and GDPR, the first 24 hours after a server or NAS failure and VMware / Hyper-V / SAN data recovery. This makes it easier to decide whether the incident can be solved as a logical database repair or whether it already requires full media diagnostics in the laboratory.

Related articles