Skip to content
QIO journal

Websites and development6 min read

1C 8.5.5 will shrink your database: what finally moves out of it

The 1C:Enterprise team announced further work on the mechanism that handles heavy data. In version 8.5.5 the binary data storage will be able to hold tabular section attributes, and the integrity check will stop freezing the entire database. Both changes matter most to large deployments where the size of the working database has become a problem in its own right.

1C 8.5.5 will shrink your database: what finally moves out of it

What changes in the storage

Today tabular section attributes are not saved in the binary data storage, and selective placement through configuration settings and the built-in language is not supported for them. Version 8.5.5 adds that option for both the internal and the external storage.

The point is practical: the more binary data is moved out of the working database, the smaller it becomes and the lighter the load on hardware. Until now part of that data stayed inside simply because it lived in a tabular section.

Database size is rarely treated as a task of its own while routine operations still fit into a night. When they stop fitting, it turns out half the volume is attachments nobody has ever opened. That is worth looking at in advance.

How it looks in the interface

In the technical specialist function for managing binary data storage, two forms change: the one for using binary data storage and the one for updating data placement. Tabular section attributes appear in the metadata tree, and only fields of the value storage type are listed.

Such attributes gain a setting for using the binary data storage. Choosing to use it opens one more setting, where you pick a boolean attribute of the same tabular section to control writing. The built-in language will be extended to support the new functionality.

The setting that enables binary data storage for an attribute of the value storage type
The setting that enables binary data storage for an attribute of the value storage type

An integrity check that does not stop everyone

The second change concerns the database testing and repair function. Today the binary data storage integrity option requires an exclusive lock on the whole database, and on large databases the operation takes a significant amount of time.

In separated databases that is particularly wasteful: the check may be needed only for some of the applications running in the database, yet everyone stops. Version 8.5.5 adds a run filtered by data separator, so only selected applications are tested and repaired while other users keep working. The same improvement will also be available in 8.5.4.

The database testing and repair window with the binary data storage integrity check selected
The database testing and repair window with the binary data storage integrity check selected

Who benefits

Three kinds of deployment gain something, for different reasons.

  • Large databases with attachments: scans, photographs and printed forms inside tabular sections stop inflating the working database.
  • Separated databases and cloud services, including those running as a service on 1cfresh: routine checks stop being an event for every tenant at once.
  • Projects with a tight maintenance window: an operation that used to require a full stop now fits into partial maintenance.

What to check before upgrading

1C itself warns that this is an announcement of new functionality rather than documentation, and that it should not be used to learn the mechanism. The full description will appear in the documentation for the relevant version, and the complete list of changes in the v8Update.htm file.

Before moving, it pays to see which of your tabular section attributes use the value storage type and how much space they take: that is the potential gain. Decide separately which boolean attribute will control writing, and allow time for updating the placement, because moving existing data is never instant.

The takeaway

Both changes address the same problem from different sides: a large database is hard to maintain. The first shrinks the database, the second makes maintenance less painful. Small deployments will not notice the difference; large ones will measure it in hours of downtime.

Sources

  1. Development of the binary data storage, 1C:Wonderland
  2. 1C:Enterprise 8
  • 1C:Enterprise
  • Binary data storage
  • Tabular section
  • 1cfresh

Follow the journal

New pieces on websites, SEO and AI come out in the QIO journal. Follow in Google, by RSS or in Telegram to get them first.

Read next

How can we help?
Discuss a project