Restore base 1C using HEX editor
This article is for those who are desperate to restore their base and climbed behind backups. Namely: what to do when the 1C base was killed, the so-called “utility testing the physical integrity of the database” chdbfl.exe and her friend 1C platform.
Who does not know, chdbfl.exe is a standard program for restoring and testing the physical integrity of the 1C database, included in the platform bundle. And everyone has long known that chdbfl.exe only makes things worse in most cases (in my practice it is like that).
It all started with a very banal error. Since programmers from 1C love to be wise, during the next update of 1C: Accounting, the following fell out:
')
Now I know that this error is fixed by clearing the cache, but at that time I used exactly chdbfl.exe and the Configurator (Testing and Correction). The error went away and I was easily updated. But the next day the accountant’s alarm bell rang: “Come!”
Upon arrival, I was met by 1C with a pop-up dump at the opening of the document “Receipt of goods and services”. It was decided to reiterate the above points. And lo and behold! The problem was solved. I proudly left the organization, but at the same time took the base for testing on my computer. But it was not there. Now another document fell out with a dump. It was decided to postpone everything until tomorrow and try to do something on my computer. And this time the same steps helped me as before. "Now everything" - I thought. But not really.
After 2 weeks, another bell rang: - Reports are burning, come urgently!
This time it was all much more serious. When recalculating the results, 1C produced the following:
Reports that require results gave the following:
As before, I used the same utilities as before, but it did not give a result. As did not give the result all sorts of upload / download / save. The update also did not take place for an unknown reason:
It stumped me for 2 days. During these days, almost everything was tried. Many advised to look at the chart of accounts and remove the extra subconto from this account. But! Everything was typical, no changes were made.
The decision came suddenly and inspired by this little article . I downloaded all the programs from the article and began to "pick". I opened the database file in Tool_1CD and after half an hour of smoking and understanding it turned out that:
- _Acc - the main table of accounts.
- _Acc_ExtDim - table of types of subconto of the chart of accounts, created for the plan of accounts in the event that the maximum number of subconto is greater than zero.
In my case, these are the _ASS13 and _ASS13_EXTDIM446 tables, respectively:
So, the fun begins. Remember the _IDRREF field of our account in the _13 table:
Go to _13_EXTDIM446 and try to find this identifier in the _13_IDRREF field:
Here they are, our cherished subconto. But there must be three of them! Somehow, in an incomprehensible and strange way, the Configurator during restructuring and chdbfl.exe duplicated the subconto of this account and therefore an error popped up. Extras need to somehow be removed. For this we need another field from the same table, _KEYFIELD . We remember all the values ​​of extra subconto. You should have the following:
-
-
-
For the next step, we need a HEX editor. Open our database file in it. Then I slowed down a bit. I was looking for as soon as possible and wherever possible the line 5724b6a1-5590-484e-a7c1-920ebbd1a385 . The truth was almost near. It was necessary to look not all at once, but over the decades of numbers. But here again a trick. There were a lot of such values. And in some random way I found what I needed, but in a completely different form. So, the sequence 5724b6a1-5590-484e-a7c1-920ebbd1a385 000001b0 in the HEX editor was this - a7c1920ebbd1a385484e55905724b6a1000001b0 .
And so with every subconto. The lines we need are:
-
-
-
It remains the case for small. Change the first digit of the code to 9 (you can take any other, but you need to control the uniqueness of this code) and save the database file. We open all this in 1C: Enterprise (for sure, we can once again get rid of testing and fixing and chdbfl.exe ) and rejoice in the restored and working base.
Who does not know, chdbfl.exe is a standard program for restoring and testing the physical integrity of the 1C database, included in the platform bundle. And everyone has long known that chdbfl.exe only makes things worse in most cases (in my practice it is like that).
It all started with a very banal error. Since programmers from 1C love to be wise, during the next update of 1C: Accounting, the following fell out:
')
Now I know that this error is fixed by clearing the cache, but at that time I used exactly chdbfl.exe and the Configurator (Testing and Correction). The error went away and I was easily updated. But the next day the accountant’s alarm bell rang: “Come!”
Upon arrival, I was met by 1C with a pop-up dump at the opening of the document “Receipt of goods and services”. It was decided to reiterate the above points. And lo and behold! The problem was solved. I proudly left the organization, but at the same time took the base for testing on my computer. But it was not there. Now another document fell out with a dump. It was decided to postpone everything until tomorrow and try to do something on my computer. And this time the same steps helped me as before. "Now everything" - I thought. But not really.
After 2 weeks, another bell rang: - Reports are burning, come urgently!
This time it was all much more serious. When recalculating the results, 1C produced the following:
Reports that require results gave the following:
As before, I used the same utilities as before, but it did not give a result. As did not give the result all sorts of upload / download / save. The update also did not take place for an unknown reason:
It stumped me for 2 days. During these days, almost everything was tried. Many advised to look at the chart of accounts and remove the extra subconto from this account. But! Everything was typical, no changes were made.
The decision came suddenly and inspired by this little article . I downloaded all the programs from the article and began to "pick". I opened the database file in Tool_1CD and after half an hour of smoking and understanding it turned out that:
- _Acc - the main table of accounts.
- _Acc_ExtDim - table of types of subconto of the chart of accounts, created for the plan of accounts in the event that the maximum number of subconto is greater than zero.
In my case, these are the _ASS13 and _ASS13_EXTDIM446 tables, respectively:
So, the fun begins. Remember the _IDRREF field of our account in the _13 table:
Go to _13_EXTDIM446 and try to find this identifier in the _13_IDRREF field:
Here they are, our cherished subconto. But there must be three of them! Somehow, in an incomprehensible and strange way, the Configurator during restructuring and chdbfl.exe duplicated the subconto of this account and therefore an error popped up. Extras need to somehow be removed. For this we need another field from the same table, _KEYFIELD . We remember all the values ​​of extra subconto. You should have the following:
-
5724b6a1-5590-484e-a7c1-920ebbd1a385 000001b0-
5724b6a1-5590-484e-a7c1-920ebbd1a385 000001b1-
5724b6a1-5590-484e-a7c1-920ebbd1a385 000001b2For the next step, we need a HEX editor. Open our database file in it. Then I slowed down a bit. I was looking for as soon as possible and wherever possible the line 5724b6a1-5590-484e-a7c1-920ebbd1a385 . The truth was almost near. It was necessary to look not all at once, but over the decades of numbers. But here again a trick. There were a lot of such values. And in some random way I found what I needed, but in a completely different form. So, the sequence 5724b6a1-5590-484e-a7c1-920ebbd1a385 000001b0 in the HEX editor was this - a7c1920ebbd1a385484e55905724b6a1000001b0 .
And so with every subconto. The lines we need are:
-
a7c1920ebbd1a385484e55905724b6a1000001b0-
a7c1920ebbd1a385484e55905724b6a1000001b1-
a7c1920ebbd1a385484e55905724b6a1000001b2It remains the case for small. Change the first digit of the code to 9 (you can take any other, but you need to control the uniqueness of this code) and save the database file. We open all this in 1C: Enterprise (for sure, we can once again get rid of testing and fixing and chdbfl.exe ) and rejoice in the restored and working base.
Source: https://habr.com/ru/post/155105/
All Articles