To prevent problems that cause this error, it is recommended not to do dynamic updates (at least several times in a row - until changes are uploaded to branches), and it is also advisable to check the box in the exchange settings "upload data only when successful."

To prevent problems that cause this error, it is recommended not to do dynamic updates (at least several times in a row - until changes are uploaded to branches), and it is also advisable to check the box in the exchange settings "upload data only when successful."

28.03.2024

Question: Error updating the RIB node


Good afternoon.

I updated the main Rarus-Retail node to 2.2.5.27, made an exchange with a couple of RIB nodes - everything is fine.

I started a massive update of the remaining nodes (similar to the “top couple” (other RIB stores)) - an error pops up in the client part:

Distribution of Reports. Register Data for Updating the List of Routine Tasks"
deferred update handler
"Distribution of Reports. Update the List of Routine Tasks"
An error has occurred:
"(GeneralModule.GeneralPurpose.Module(3502)): Error when calling context method (Contains)
Return Metadata.InformationRegisters.Contains(MetadataObject);
because of:
Type mismatch (parameter number "1")".

Has anyone encountered this? I already tried to update the platform (to the maximum 8.3.10, and tested it on 32-64 computers)... it didn’t help. But the test 2 stores were updated without problems, I can’t understand how.

Answer:() This is how I install the main node. I wrote a little about something else: after you unbind a node by processing, the next time you start it, the update of the conf does not immediately begin, but first 1C opens a window in which it asks you to confirm that the node is being unlinked. After this it is updated - after the update the node is no longer in the list.
In fact, on 2.1, I remember that I updated it using this method, but on 2.2 something didn’t work. Maybe in the park I already poked the wrong sequence in the actions)

ACCORDING TO THE SUBJECT:
I figured out what I have. It turned out that I had overlooked:
“In one of the 2.2 releases, the Report Distribution directory appeared with the predefined element “Personal Data”” - a directory with this element was also available in 2.1.

The nuance is this: jambs with updating nodes are observed on those databases that were created from the central one precisely on release 2.1.9.18. Everything that was created in earlier releases was updated normally. This probably explains why a couple of TS databases were also updated successfully, and then there were problems.

I didn’t try to invent anything with creating a new element in the directory and setting it as predefined. I transferred this element from a copy of the center to 2.1 via unloading/loading XML and repeated the update on the problematic “base” - everything worked.

() So use the method if you haven’t found the answer yet.

Question: Configuration update error


I am updating the Accounting 2.0.64.14 configuration to 2.0.64.24. platform 8.2.19
An error immediately appears:
Error accessing file... path... temporary file.tmp.
Where to look?

Answer: I solved the problem that time by waiting for a new “stable” release

Question: Error in user rights to BSP


Greetings!!! I am writing a conf based on BSP 2.2, it seems that I already have experience, and have studied the docks far and wide, but when I launch the information security for the first time, an error appears:

(GeneralModule.UsersService.Module(345)): Authorization failed. The system will be shut down.
User: The administrator was not found in the Users directory.

An error occurred when trying to add a user to the directory:
"Error updating the infobase.
The access restriction parameter is not filled in:
"Possible rights for setting object rights."

For the developer: the supporting data may need to be updated,
that affect the operation of the program. To perform the update you can:
- use external processing
"Developer Tools: Updating Support Data",
- or run the program with the command line parameter 1C:Enterprise 8
"/C LaunchInformationBaseUpdate",
- or increase the configuration version number so that the next time you start
The procedures for updating the infobase data have been completed."

Click to expand...

I would like to hear the answers of the “experienced”, for subsequent active dialogue, perhaps even cooperation

Answer:

Vdeg said:

Problem solved?

I have a different problem: I add a user to BSP 2.2.5.29, and he either has full rights (if I manually add them) or none at all (he sees an empty interface without a single reference book or document). Because in typical BSP roles there are no checkboxes at all for accessing specific (my) directories and documents. How then will record level access for a new user be tracked???

Click to expand...

How should the BSP know what kind of directories you have and how you want to configure access to them?
We probably need to do it ourselves

Question: SendingDeliverableNotified Remote node failed verification


Until last Friday the following code worked fine..

XdtoSubscriber = FactoryXDTO.Create(FactoryXDTO.Type(";));
xdtoSubscriber.DeviceID = DeviceID;
xdtoSubscriber.SubscriberType = FactoryXDTO.Create(FactoryXDTO.Type(";), "GCM");
New XDTO Serializer = New XDTO Serializer(XDTO Factory);
Subscriber = NewSerializerXDTO.ReadXDTO(xdtoSubscriber);
Notification=New DeliverableNotification;
Notification.Recipients.Add(Subscriber);
Notification.Text=Text;
Notification.SoundNotification=SoundNotification.Default;
Notice.Sticker=1;
DATAAuz=TOKEN;
SendingDeliverableNotifications.Send(Notification, DataAuz, True);

Now the error: The remote node failed verification. Broke my whole head. I caught requests from the server - it was empty, it felt like it wasn’t contacting anywhere... I tried it on three different machines with different axes. dried up.. help...

Answer: Up

Answer: So, I decided to make a new image of the node. When starting the node, it says that you need to start with \c start updating the information base
and remake the image.

It turns out that this is something due to an update curve.

I tried to launch with this key and make an exchange with an existing node. No updates started on the node, I didn’t ask to restart anything.

And as a result, the message was again not accepted in the main node with the same error.

What can be done?
Can I fictitiously change something in the main node in the conf and make an exchange? Or will it not update the entire configuration, but only what I change? I'll try to make a knot for now. But I'll wait for your ideas

Question: Distributed database - error during exchange is not resolved


Good day everyone!

The situation is as follows.

When loading an exchange from a peripheral node, I receive the message “The configuration of the distributed information security node does not match the expected one.”

Then I follow the instructions.
I unload the configuration from the central database into CF, untie the peripheral database from the central node by processing, remove the configuration in the peripheral database from support, load the configuration from a file.
I bind the central processing node in the peripheral database.
Save, apply.

I download the exchange from the central database again.
I load it into the peripheral. I am unloading the exchange from the peripheral database.
I load it into the central one. Again I receive the message “The configuration of the distributed information security node does not match the expected one.”
But this is some real nonsense - I load the configuration into the central database and no one has changed the configuration in the peripheral database.

How to overcome such an error?

Answer: It never occurred to anyone to advise such obvious things after many years of abuse about the demonic update :)

Question: RIB and updates


Hi all. It is planned to use distributed information security.

configuration changed. The central database configuration is updated by the programmer. These changes will then be transmitted to peripheral databases using exchange files.

The question is: what about launching handlers after updating the database configuration and logging in for the first time in user mode?

updating the main configuration - updating the database configuration - executing update handlers in user mode

For example, many releases were missed, you need to sequentially update to 3 releases. There are no problems with updating the central database, but what about the peripheral ones? It is also necessary to update them in 3 stages (update the central database with the first release, update the RIB, update the central database with the second release, update the RIB, etc.?)

Thanks everyone for your help!

Answer:() point your nose, I can’t find the code that is executed when registering changes to an object.
It seems that if you use the WhenSendingData method, then changed objects will still be accumulated in the main node for sending to the slave node. And these are extra computer resources
Therefore, I want the objects in the main node not to be registered for sending immediately at the moment of their change (On Write, for example). In what place, for example, in the standard Accounting Rev. 3 are these objects registered for filing?

Question: [SOLVED] Error contacting online support


Dear experts, please tell me!
1C:Enterprise 8.3 (8.3.11.2899)
On the 1C server there are several databases of different configurations running, in all of them Internet support is connected and working normally. Incl. loading currency rates, banks, checking counterparties, SPARK, etc.
Proxy settings in all databases are spelled out identically.
But in the BP-3 KORP databases an error always appears:

In the log book:

Failed to obtain an authentication ticket from the service.
Failed to load content(). (GeneralModule.InternetUser SupportClientServer.Module(362)): Error when calling the context method (SubmitForProcessing)
Response = Connection.SendForProcessing(HTTPRequest, ReceivingParameters.ResponseFileName);
because of:
Internet Error: Remote host failed verification

Click to expand...

I tried it on different versions of the platform (8.3.10..., 8.3.11...), and on different versions of the configuration (3.0.54.15, 3.0.57.10).
Testing and fixing doesn't help either.
What can be wrong?
Does BP-CORP really access the Internet in a special way?
Thank you.

Answer:

Answer from 1C (what was highlighted in red helped me):

During the transition, the BSP as part of the power supply unit was updated from 2.4.3 to 2.4.4
In the list of changes BSP 2.4.4
Increased security when establishing a secure connection with HTTPS Internet services. If various problems are detected with the certificate of the Internet service with which a secure connection is being attempted (the certificate is not valid, out of date or not trusted), the connection will not be established.
In 8.3.10, certificate verification in Windows is carried out using the operating system." -
Install the latest updates for your OS. They contain important updates to system components that are responsible for working with certificates.
Please also install the latest root certificate updates distributed by Microsoft in the installation packages.
Requires version no lower than IE8.0. It contains important updates to system components that are responsible for working with certificates.
As a rule, after installing all the updates, the problem is solved.
Check that if you enter it in the search bar in Internet Explorer, the link opens.
The user on whose behalf you are working has Internet access.
If this is a file database on the client's machine, you should check it on it.
If this is a client-server database, then on the server under the user under which the 1C server is running.
Check only with IE browser.
Check that ports 443 and 80 are open
If a Proxy server is used, check whether the data is configured in the Personal Settings menu.
If the client-server version is used, then you should configure the server in such a way that the connection to the Internet with the IE browser works correctly under the user on whose behalf the 1C server is running.


I registered the proxy in the IE settings of the user under which the 1C server was running - everything worked.

Question: Bukh 3 update


Good day
Accounting 3
I updated from 3.0.43.208 to 3.0.43.235
errors
first
(GeneralModule.MessagingInternal.Module(381)): Error when calling context method (ThisNode)

because of:
More than one entry found
second
When calling the update handler:
"MessagingInternal.SetCodeThisEndPoint()"
An error has occurred:
"(GeneralModule.MessagingInternal.Module(381)): Error when calling context method (ThisNode)
ReturnExchangePlans.MessageExchange.ThisNode();
because of:
More than one entry found."

I read that there is a problem with the platform, I tried it on different versions of the platforms
I tried to take a clean config of the latest version and just stupidly load it with a complete replacement
In general, it didn’t help, it was always the same thing. Tell me, has anyone encountered this?

Answer:

I changed the node from true to false above, I thought it didn’t work, and then I went to see it worked

Hello, dear readers of our blog site! Today we'll talk about
fixing two errors that may arise during exchange in a distributed information base (RIB). Such errors can occur if you have changed the configuration of your database and are trying to transfer these changes from the central database to the peripheral one. For example, in the way that was described. Let's get started!

These are the messages that may appear when you try to make an exchange using RIB:


"Data is received from the node for which
configuration changes have been logged.
Changes need to be transferred
configurations to the node."


“Distributed information security node configuration
not as expected!”

Let's look at the steps to help correct the situation. Before we start, let's create our information database!!!


  1. Let's take the configuration file with the update, open the central database in the Configurator and load it (Configuration-Load configuration from file...). Let's save the information security (F7).
  2. Let's go to and upload to a file for the peripheral database:

    • Select the exchange plan in the list, then Right-click to open the context menu and select “Save changes...”.
  3. Now let's deal with peripheral information security. Let's open it in exclusive mode so that there are no users, and also close the Configurator. Now you need to remember the node that is the main one for the current database. Open Operations-Exchange Plans-Select your exchange plan (for example, “By warehouse”). In the list of exchange plans, the main node is the item with the yellow icon. This information will be useful to us in the seventh point. Let’s open processing and click the “Cancel assignment of master node” button.
  4. Now let’s open the peripheral information security in the Configurator and load the same configuration file that we loaded in the first step in the central database (Configuration-Load configuration from file...). Let's save the information security (F7).
  5. Let's change the support settings (Configuration-Support-Support Settings...). In the dialog, select the cell in the table at the intersection of the first row and second column. Then double-click to open the “Support Rules Settings” dialog. In it, check the “Install for subordinate objects” flag and click the “OK” button. Close the support settings dialog by clicking the “Close” button. Save IB (F7). Let's close the Configurator.
  6. Now let’s open the peripheral information security again in 1C:Enterprise exclusive mode so that there are no users, and also close the Configurator. Let's open the processing Installation of the MainNodeDB.epf and select the exchange plan that we want to install as the main node (in the fourth paragraph we remembered this node). Then click the “Install Master Node” button. After this, the current information security will again become peripheral.
  7. Now in the current information security (peripheral) we will open the exchange plans and download the file with the exchange from the Central database, which we received in the third step:

    • Operations-Exchange Plans-Select our exchange plan (for example, “By warehouse”).
  8. If everything went well, then we will upload the exchange for the Central database in the current information security (peripheral):

    • Operations-Exchange Plans-Select our exchange plan (for example, “By warehouse”).
    • Select the exchange plan in the list, then Right-click to open the context menu and select “Save changes...”.
    • In the dialog, indicate the path and name of the exchange file. Click the “OK” button.
  9. Now let’s try to load this file into the Central Database and open it in 1C:Enterprise mode:

    • Operations-Exchange Plans-Select our exchange plan (for example, “By warehouse”).
    • Select the exchange plan in the list - Right-click to call up the context menu and select “Read changes...”
    • In the dialog, select the exchange file. Click the “OK” button.

To avoid problems with working copies, do first

  • The message file has already been loaded into the receiving database. You need to download it from the source database again.

Error "Error when copying a file from an FTP resource... Error working with the Internet: Timeout was reached"

  • It is not possible to copy the required file from the site through which the exchange takes place. This could be due to your internet being slow or problems with the site itself.
  • You need to try to repeat the exchange after 15-30 minutes.

Error: Editing data for this period is prohibited. Changes cannot be recorded..."

  • The downloaded data contains documents from the closed period.
  • It is necessary to carry out the exchange under users who have the right to change documents during this period.

Error: Database configuration updates need to be performed. The update can be performed in configurator mode"

Reason: The programmers changed the configuration in the center. Solution: Update the changed configuration in the peripheral database. For this:
  • Go to the configurator.
  • Execute the menu item “Configurator / Update database configuration”.
  • If a question is displayed with the answers only “Repeat”, “Cancel”, “Update dynamically”, click the “Update dynamically” button.
  • If a question appears with only “Retry” and “Cancel” answers.
    • all users log out of 1C.
    • press the “Repeat” button.
  • Answer the remaining questions in the affirmative: “Yes”, “Accept”, “OK”.
  • Close the configurator.
  • Repeat loading from the center.

Error: “The configuration does not match the expected one”, “Attempting to accept changes from an unknown configuration”

  • Database error.
  • It is necessary to contact specialists.

The exchange takes a very long time and freezes

Possible reasons:
  • There's a lot of data coming in.
    • Find out from the sender whether he performed a group change of documents (posting, changing details, etc.).
    • If so, leave the computer with the exchange overnight.
  • A large file cannot be downloaded from the Internet.
    • If the file is large (80-100 MB or more), then perhaps 1C simply cannot download it.
    • You need to download the file and upload it to 1C manually (possibly with the help of specialists).
      • menu item “Operations” / Exchange plans / Full / Button on the “Read message” panel.
  • The database is damaged:
    • Try it
  • If these steps do not help, you will have to contact specialists.
  • If the error cannot be corrected, call the emergency support number +7 (8512) 64-55-05.
  • Our specialist will help you, no matter what city you are in.

First, here is a list of abbreviations I use:

  • RIB - distributed information base
  • CB - central base, root node of RIB
  • UB - remote base, database of a remote RIB node

From my own experience, I can say that I have encountered two reasons for the error:

  1. While receiving the message file, the database “fell” in the management system, and therefore, apparently, there was a desynchronization between the conf. Central Bank and UB;
  2. under MSSQL, the client downloaded a copy of the working database and did not turn off the reg. auto-exchange tasks, as a result, some messages to remote nodes were generated from the working database, and some from a copy, which led to desynchronization of configurations

There is also an opinion that this error is caused by the use of a dynamic database update mechanism. There are doubts here, because on the one hand, dynamic updating never affects the database structure, and the RIB mechanisms still work with the database structure, and not with its applied part; nevertheless, the RIB uses a mechanism for generating a digital signature of the configuration version (in in the future I will call it a hash for short), and when the application part changes, the hash naturally must be recalculated. I will neither deny this nor affirm it, because... If I encountered this situation, I did not find any clear evidence of it.

To correct it, I use 2 methods, depending on the situation.

FIRST TECHNIQUE

The first (most common) is repeatedly mentioned both in the partner conference and on other Internet resources related to 1C. It is used in most cases when, despite the message about discrepancies in configurations, a manual comparison shows that they are identical.

Sequencing:

  1. unload the cf file from the central bank;
  2. we unlink the UB from the RIB (the Set MainNode method, ready-made processing can be found in the application or in other publications);
  3. replacing conf. UB to the cf file uploaded in the first step, for this we use the “Load configuration from file” menu (and not comparison-merge!!!);
  4. Let's restore the RIB sign for the UX.

In most cases, these actions are more than enough to restore the exchange, but not always...

SECOND METHOD

It is used if the first method did not work, and it is not possible to unload the node again.

Background: the client was setting up a cascade RIB and an error occurred in the first level of the cascade (the second level worked flawlessly all this time). The configuration was developed jointly with the client’s IT service, and since the error occurred, the configuration of the central bank has changed several times. The option of rolling back changes was not considered even in principle, because the loss of some data and the shutdown of several departments was completely unacceptable. The first option for correcting the error did not produce any tangible results. Therefore, we had to look for other solutions.

The idea came to try to replace the hashes of configuration files directly in the XML exchange files. The description of the structure of the exchange file from the book "Professional development in the 1C:Enterprise 8 system" gave a weak idea of ​​​​the formation of digital signatures of configurations and changes in them, but determined the direction of the search: the values ​​of Digest1 and Digest2. I figured out everything else purely empirically (that is, by trial and error), but it was possible to establish a pattern.

The test experiments were successful. At the work bases, everything also went well.

So, the sequence of actions:

  1. perform steps 1 - 4 of the first method;
  2. We unload the exchange file from the UB, but do not load it into the Central Bank;
  3. We unload the exchange file from the Central Bank, but do not load it into the UB;
  4. in the exchange file from the Central Bank, we replace the block containing information about configuration changes and hashes (Digest1 and Digest2) with a block of hashes from the UB file (see example below)
  5. We upload the file from the 4th point to the UB;
  6. Be sure to overwrite the exchange file from UB (2nd point)! this file should not be downloaded when exchanging with the Central Bank!
  7. To check, we make several consecutive exchanges.

If data compression is used during the exchange, then we either disable compression, or first unpack the file, change it, then pack it back and send it.

Exchange file block from the Central Bank

106.0...here are blocks describing configuration changes... 1cf680807e97a5dc0d1ed7f901b07392 038211651cf680807e97a5dc0d1ed7f9

needs to be replaced with a block of the exchange file from UB (note that Digest1 for a file from UB is always equal to "000000000000000000000000000000000"!!!)

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

The listed actions must be performed with extreme caution; an incorrect sequence can result in complete inoperability of the RIB. Therefore, before these actions, creating backup copies is MANDATORY!

For the rest I can only wish you good luck!

This error is typical for . The error “The configuration of the distributed information security node does not match the expected one” is a system one. Mainly occurs due to an abnormal shutdown during the exchange of data via URIB.

This can be solved in a fairly simple way. Let's consider it.

Instructions

1. Make copies of the databases on which work will be carried out (In the configurator “Administration - Upload infobase”).

2. Launch the configurator of the main database of the RIB node.

3. Save the central node configuration to a database file (“Configuration - Save configuration to file...”)

4. Open the slave node database configurator.

Get 267 video lessons on 1C for free:

5. Remove the configuration of the slave node from support (Configuration - Support - Support Settings - Remove from support):

6. Load the database configuration (“Configuration – Load configuration from file...”).

8. After the restructuring, you need to enter enterprise mode and install the master configuration node. This can be done using special processing - . Processing works in both managed application mode and regular application mode.

9. In processing, you need to select the main node and click “Run”:

10. Done! Try to start the exchange, the system should complete the exchange correctly.

© 2024 hecc.ru - Computer technology news