Cambio de configuración IB distribuida 1C. Para evitar problemas que se denomina este error, se recomienda no realizar una actualización dinámica (al menos varias veces seguidas, antes de descargar cambios en las sucursales), y también preferiblemente en la configuración de Post Exchange

La base de información distribuida (RIB) se usa a menudo para organizar el trabajo de sucursales y unidades, lo que le permite intercambiar información rápidamente, mientras se mantiene el grado de autonomía deseado. Aunque esta tecnología Es bastante confiable, se rompe de vez en cuando. Hoy veremos uno de los errores bastante comunes: contaremos sobre los motivos de su aparición y métodos para combatirlo.

Vamos a empezar, como siempre, desde el principio. Después de haber creado la costilla todos los cambios en la configuración base de información Se puede hacer solo en el nodo principal. Posteriormente, con el siguiente intercambio, todos los cambios se transferirán a los nodos subordinados y se usan automáticamente allí. Pero fue liso en el papel ...

En la práctica, a veces sucede que entre las sesiones de cambio, especialmente si en la periferia es mala con el canal, la configuración principal del nodo tiene tiempo para cambiar dos veces. Por ejemplo, realizó cambios, descargados, la base de datos periférica recibida, pero aún no los aplicó, lo que podría tomar algún tiempo, y la confirmación aún no ha enviado. Si durante este espacio para hacer cambios nuevamente y nuevamente, descargue el intercambio, resultará de que el centro espera ver el número de configuración 1 en el nodo periférico e intentará actualizarlo a la configuración No. 3, y de hecho, se enfrentará Configuración No. 2. A veces, esta situación se produce cuando la base central es dinámica. Como resultado, el intercambio será imposible, y recibirá un mensaje que ¡La configuración del nodo IB distribuido no coincide con lo esperado!

En general, la moraleja de esta historia es simple: no refina activamente la base de datos de trabajo, y si lleva, complete todas las sesiones de intercambio antes de realizar los siguientes cambios. ¿Pero cómo ser si tal problema todavía sucedió?

La solución "en la frente" es crear una nueva imagen del nodo subordinado, pero en la práctica generalmente no es aplicable. Como regla general, la aparición de un error grave en el intercambio no se fija de inmediato, pero después de algún tiempo después de que los datos operativos de las bases periféricas han cesado. Dependiendo del calendario de intercambio entre el momento de la ocurrencia del problema y su detección se puede realizar un día de trabajo completo, o incluso más.

Aquí vale la pena lanzar una piedra en el jardín de desarrolladores que se divierten como un error y simplemente resaltan la situación roja. El número de mensaje es menor o igual al número recibido previamenteque es generalmente bastante normal. Como resultado, los usuarios, la percepción de los errores se emboten, y simplemente dejan de leer los mensajes mostrados, creyendo que todo está bien y, solo, otro lado aún no ha hecho el intercambio en sí mismo.

Pero de vuelta a nuestro error. La solución es bastante simple y se encuentra en la superficie: para llevar la configuración de la base periférica a la esperada, es decir,. Llévalo en línea con la configuración del nodo central. Pero en la práctica, esto no es tan fácil. Si abrimos la base periférica en el Configurador, veremos que los cambios están bloqueados por los controles de la costilla.

Para cambiar la configuración del nodo subordinado, será necesario deshabilitarlo temporalmente desde la base central. Para estos fines, puede usar uno de los tratamientos, que se presentan en la red, o deshabilita IB del nodo central utilizando el parámetro de inicio del configurador/ Resetmosterno..

Abra el símbolo del sistema e ingrese (teniendo en cuenta la versión de la plataforma y la ruta de instalación real):

"C: \\ Archivos de programa (X86) \\ 1CV8 \\ 8.3.6.2100 \\ bin \\ 1cv8.exe" Config / resetMasterNode

Después de ejecutar este comando, aparecerá una ventana de inicio regular, seleccione la base de datos deseada allí y haga clic en Conifurador.

Lanzar IB al mismo tiempo no pasará. Puede parecer que no pasó nada, pero abriendo la base de datos en el Configurador nuevamente, puede asegurarse de que esté deshabilitada del nodo principal y está disponible para realizar cambios.

¡Atención! En las plataformas 8.3.7 - 8.3.9 La ejecución de este comando lleva a una finalización de la emergencia del trabajo. El error se fija en la plataforma 8.3.10.

Si no quieres meterte con línea de comandoPuede usar uno de los tratamientos, el que se presenta a continuación que usamos, se encontró en el disco de la red, y lo hemos ingresado solo en ediciones cosméticos. Nota, el procesamiento es adecuado solo para una aplicación regular, para configuraciones en una aplicación administrada, use la clave de inicio del Configurador.

Trabajar con él es extremadamente simple, ejecutelo en modo 1C: Empresas, a través de Archivo - abiertoLuego, solo presione el botón deseado en nuestro caso Deshabilitar el nodo principal.

Ahora necesitamos la configuración actual desde el nodo central. Para hacer esto, abierto iB central en el configurador y ejecutar Configuración: guardar la configuración para archivar. El archivo resultante con la extensión. cf. Será necesario transferir al nodo periférico.

Luego, en el nodo periférico, ejecute IB (después de apagarlo del nodo principal) en el Configurador y eliminar de Soporte. Para hacer esto, elige: Configuración - Soporte - Ajuste de soporte.

En la ventana que se abre, primero enciende la posibilidad de cambio.

Y luego elimine la configuración de Soporte.

Ahora puede descargar la configuración desde el archivo, para hacer esto, seleccione Configuración - Descargar configuración desde el archivo y especifique no transferido desde el nodo central cf.-expediente. Después de eso, recibirá una advertencia de que la configuración actual no está vacía. Tenga en cuenta que la manipulación que realiza es potencialmente peligrosa y puede llevar a daños irreversibles a IB, por lo que antes de continuar asegurándose de tener una copia de seguridad relevante.

Este error es típico para. El error "La configuración de un nodo distribuyó IB no coincide con el" es sistémico esperado. Básicamente surge debido a una realización de emergencia de trabajo durante el intercambio de datos sobre la URIB.

Es posible resolverlo. manera simple. Considéralo.

Instrucción

1. Haga copias de las bases de datos que funcionen se realizarán (en el Configurador de administración: descargar la base de información).

2. Ejecute el configurador de base principal del nodo de costilla.

3. Guarde la configuración del nodo central en el archivo de la base de datos ("Configuración: guardar configuración a un archivo ...")

4. Abra el configurador base de nodo subordinado.

Obtenga 267 tutoriales de video para 1C gratis:

5. Retire la configuración del nodo subordinado con Soporte (Configuración - Soporte: Ajustes de soporte: elimine del soporte):

6. Cargue la configuración de la base de datos ("Configuración: descargue una configuración desde el archivo ...").

8. Después de la reestructuración, es necesario ingresar al modo Enterprise y configurar el nodo de configuración principal. Es posible hacer esto con la ayuda del procesamiento especial. El procesamiento funciona tanto en el modo de aplicación controlado como en el modo de aplicación normal.

9. En el procesamiento, debe seleccionar el nodo principal y haga clic en "Ejecutar":

10. ¡Listo! Intente iniciar el intercambio, el sistema debe intercambiar correctamente.

Para empezar, traigo una lista de reducciones usadas por mí:

Base de información distribuida de costilla
CB - Base central, Nudo de raíz costilla
UB - Base remota, base de datos de costilla de nodo remoto

Por experiencia propia Puedo decir que se trató de dos razones para un error:

durante la recepción del archivo de mensaje en la base "Fell" de UB, en relación con la cual, aparentemente, hubo una desinxlina de conf. Banco Central y UB;
bajo MSSQL, el cliente ha descargado una copia de la base de trabajo y no apagó la regulación en la copia. Tareas de Autobrack, como resultado, parte de los mensajes en nodos remotos se formó a partir de la base de datos de trabajo, y una parte de la copia, que condujo a la configuración de la distancia

También existe la opinión de que este error proporciona el uso de un mecanismo de actualización dinámica. Hay dudas aquí, porque por un lado. actualización dinámica Nunca afecte la estructura de la base de datos, y los mecanismos de costilla todavía funcionan precisamente con la estructura de la base de datos, y no con su parte aplicada, sin embargo, la costilla se usa para formar una versión de configuración digital de la versión de configuración (en el futuro Lo llamaré para reducir la hashe), y el cambio en la parte aplicada del hash está naturalmente obligado a recalcular. No lo negaré ni diré, porque Si me encontré con esta situación, no encontré esta evidencia.

Para la corrección utilizo 2 técnicas, dependiendo de la situación.

Primera técnica

El primero (el más común) se menciona repetidamente en la conferencia de afiliados, y en otros recursos de Internet asociados con 1C. Se utiliza en la mayoría de los casos cuando, a pesar del mensaje sobre las configuraciones, cuando se compara manualmente, se emite que son idénticos.

Secuenciación:

descargar el archivo CF del banco central;
nos atenamos a la UB de la costilla (el método de instalación de la cadena, se puede encontrar el procesamiento listo en el apéndice o en otras publicaciones);
reemplazar conf. UB En el archivo CF descargado en el primer paso, para hacer esto, use el menú "Configuración de descarga desde el archivo" (y no comparando-asociación !!!);
signos relativos de costilla para UB.

En la mayoría de los casos, estas acciones son más que suficientes que restauren el intercambio, pero no siempre ...

Segunda técnica

Se utiliza si la primera técnica no funcionó, y no es posible descargar el nodo nuevamente.

Prehistoria: el cliente tenía una costilla en cascada y el error ocurrió en el primer nivel de la etapa (el segundo nivel todo el tiempo funcionaba perfectamente). El desarrollo de la configuración se realizó junto con el servicio al cliente de TI y desde el momento en que se produce el error, la configuración de CB logró cambiar varias veces. Una opción con un retroceso de cambios no se consideró en principio, porque La pérdida de piezas de datos y deteniendo el trabajo de varias unidades fueron completamente inaceptables. La primera versión de la corrección del error de cualquier resultado tangible no dio. A este respecto, lo que tenía que buscar otras soluciones.

Se ha hecho un pensamiento para tratar de reemplazar los archivos de configuración de Hashi directamente en los archivos de Exchange XML. Descripción de la estructura de archivos compartidos del libro "El desarrollo profesional en el 1C: Enterprise 8" dio una idea débil de la formación. firmas digitales Configuraciones y cambios en ellos, pero determinó la dirección de búsqueda: digest1 y los valores digest2. Todo lo demás descubrió una forma puramente empírica (quiero decir con el método de muestras y errores), pero la regularidad es establecer lo mismo.

Los experimentos de prueba fueron exitosos. También en las bases de trabajo, todo salió bien.

Entonces, la secuencia de acciones:

realizar acciones 1 - 4 de la primera técnica;
descargar desde el intercambio de archivos UB, pero no lo cargue en el banco central;
descargar desde el banco central el archivo de intercambio, pero no lo cargue en la UB;
en el archivo de intercambio desde el banco central, reemplazamos un bloque que contiene información sobre los cambios de configuración y la hashi (digest1 y digest2), en el bloque de caché desde el archivo UB (vea el ejemplo a continuación)
producimos la descarga de archivos desde el 4to punto en la UB;
¡Asegúrese de sobrescribir el archivo de Exchange desde la UB (2º artículo)! ¡Este archivo no debe descargarse al intercambiar en el banco central!
para la verificación, hacemos varios intercambios consecutivos.

Si se usa el intercambio para comprimir los datos, desactive la compresión, o primero desactiva el archivo, cambie, luego nos invierte y envíemos.

Unidad de intercambio de archivos del banco central

106.0
... Aquí están los bloques para describir los cambios de configuración ...
1CF680807E97A5DC0D1ED7F901B07392.
038211651CF680807E97A5DC0D1ED7F9.

debe reemplazar el archivo de intercambio desde la UB (NOTA El DIGEST1 del archivo desde la UB siempre es igual a "00000000000000000000000000000000" !!!)

106.0
00000000000000000000000000000000
11651CF680807E97A5DC0D1ED7F901B0.

Las acciones enumeradas deben llevarse a cabo con precaución marginal, la secuencia incorrecta está plegada de la inoperabilidad completa de la costilla. Por lo tanto, antes de estas acciones, la creación. copias de seguridad ¡Estar seguro!

Para el resto, solo puedo desear la buena suerte!

Para empezar, traigo una lista de reducciones usadas por mí:

Base de información distribuida de costilla
CB - Base central, Nudo de raíz costilla
UB - Base remota, base de datos de costilla de nodo remoto

Según su propia experiencia, puedo decir que he encontrado dos razones para un error:

durante la recepción del archivo de mensaje en la base "Fell" de UB, en relación con la cual, aparentemente, hubo una desinxlina de conf. Banco Central y UB;
bajo MSSQL, el cliente ha descargado una copia de la base de trabajo y no apagó la regulación en la copia. Autobracciones Asignaciones, como resultado, parte de los mensajes a los nodos remotos se formaron a partir de la base de datos de trabajo, y una parte de la copia, que llevó a la conexión a la configuración.

También existe la opinión de que este error proporciona el uso de un mecanismo de actualización dinámica. Hay dudas aquí, porque por un lado, la actualización dinámica nunca afecta la estructura de la base de datos, y los mecanismos de costilla todavía funcionan con precisión con la estructura de la base de datos, y no con su propia parte, sin embargo, la costilla usa una firma digital MECANISMO PARA LA VERSIÓN DE CONFIGURACIÓN (EN I DEBE LLAMARARÁ PARA REDUCIR A LA HASHE), y al cambiar la parte aplicada, el hash está naturalmente obligado a recalcular. No lo negaré ni diré, porque Si me encontré con esta situación, no encontré esta evidencia.

Para la corrección utilizo 2 técnicas, dependiendo de la situación.

Primera técnica

Secuenciación:

descargar el archivo CF del banco central;
nos atenamos a la UB de la costilla (el método de instalación de la cadena, se puede encontrar el procesamiento listo en el apéndice o en otras publicaciones);
reemplazar conf. UB En el archivo CF descargado en el primer paso, para hacer esto, use el menú "Configuración de descarga desde el archivo" (y no comparando-asociación !!!);
signos relativos de costilla para UB.

En la mayoría de los casos, estas acciones son más que suficientes que restauren el intercambio, pero no siempre ...

Segunda técnica

Se utiliza si la primera técnica no funcionó, y no es posible descargar el nodo nuevamente.

Se ha hecho un pensamiento para tratar de reemplazar los archivos de configuración de Hashi directamente en los archivos de Exchange XML. Descripción de la estructura de archivos compartidos del libro "El desarrollo profesional en el sistema 1c: Enterprise 8" dio una comprensión débil de la formación de firmas de configuración digital y cambios en ellos, pero determinó la dirección de búsqueda: digest1 y los valores digest2. Todo lo demás descubrió una forma puramente empírica (quiero decir con el método de muestras y errores), pero la regularidad es establecer lo mismo.

Los experimentos de prueba fueron exitosos. También en las bases de trabajo, todo salió bien.

Entonces, la secuencia de acciones:

realizar acciones 1 - 4 de la primera técnica;
descargar desde el intercambio de archivos UB, pero no lo cargue en el banco central;
descargar desde el banco central el archivo de intercambio, pero no lo cargue en la UB;
en el archivo de intercambio desde el banco central, reemplazamos un bloque que contiene información sobre los cambios de configuración y la hashi (digest1 y digest2), en el bloque de caché desde el archivo UB (vea el ejemplo a continuación)
producimos la descarga de archivos desde el 4to punto en la UB;
¡Asegúrese de sobrescribir el archivo de Exchange desde la UB (2º artículo)! ¡Este archivo no debe descargarse al intercambiar en el banco central!
para la verificación, hacemos varios intercambios consecutivos.

Si se usa el intercambio para comprimir los datos, desactive la compresión, o primero desactiva el archivo, cambie, luego nos invierte y envíemos.

Unidad de intercambio de archivos del banco central

106.0 ... Aquí están los bloques para describir los cambios de configuración ... 1CF680807E97A5DC0D1ED7F901B07392. 038211651CF680807E97A5DC0D1ED7F9.

debe reemplazar el archivo de intercambio desde la UB (NOTA El DIGEST1 del archivo desde la UB siempre es igual a "00000000000000000000000000000000" !!!)

106.0 00000000000000000000000000000000 11651CF680807E97A5DC0D1ED7F901B0.

Las acciones enumeradas deben llevarse a cabo con precaución marginal, la secuencia incorrecta está plegada de la inoperabilidad completa de la costilla. ¡Por lo tanto, antes de estas acciones, se requiere la creación de copias de respaldo!

Para el resto, solo puedo desear la buena suerte!

El archivo de mensaje ya se ha cargado en la base de datos del receptor. Es necesario descargarlo desde la base de datos de origen.

Error "Error al copiar un archivo con el recurso FTP ... Error de trabajo de Internet: Se alcanzó el tiempo de espera"

Desde el sitio a través del cual pasa el intercambio, es imposible de copiar. el archivo deseado.. Puede deberse a trabajo lento Su internet o con los problemas del sitio en sí.
Debe intentar repetir el intercambio en 15-30 minutos.

Error "La edición de estos períodos está prohibida. Los cambios no se pueden grabar ... "

Los datos descargables contienen documentos desde un período cerrado.
Es necesario intercambiar bajo los usuarios que tienen derecho a cambiar los documentos en este período.

Error "Debe actualizar la configuración de la base de datos. La actualización se puede realizar en modo Configurador »

Causa: los programadores cambiaron la configuración en el centro. Solución: actualice la configuración modificada en la base de datos periférica. Para esto:

Ir al configurador.
Ejecute el elemento del menú "Configurador / actualización de la configuración de la base de datos".
Si se emite una pregunta con respuestas solo "Repetir", "Cancelar", "Actualizar Dynamic", haga clic en el botón "Actualizar dinámica".
Si se emite una pregunta con respuestas solo "Repetir" y "Cancelar".
- todos los usuarios salen de 1c.
- presione el botón "repetir".
Para las preguntas restantes para responder a lo afirmativo: "Sí", "aceptar", "OK".
Cierre el configurador.
Repita la descarga desde el centro.

El error "La configuración no coincide con el intento", "intento de recibir cambios de una configuración desconocida"

Error en la base de datos.
Es necesario referirse a los especialistas.

El intercambio pasa muy largo, cuelga.

Posibles razones:

Hay muchos datos.
- Averigüe del remitente, ya sea que realice un cambio de grupo en documentos (realización, reemplazo de accesorios, etc.).
- En caso afirmativo, deje una computadora con cambio por la noche.
Un archivo grande no puede desaparecer de Internet.
- Si el archivo tiene un tamaño grande (80-100 MB y más), entonces tal vez 1C simplemente no puede descargarlo.
- Debe descargar el archivo y descargarlo en 1C manualmente (tal vez con la ayuda de especialistas).
  - pLANES DE MENÚ DE OPERACIONES / PLANES DE INTERCAMBIO / COMPLETO / BOTÓN EN EL PANEL "LEER MENSAJE".
La base está dañada:
- Intentar
Si estas acciones no ayudaban, tendrás que referirse a los expertos en la técnica.

Si no logró corregir el error, llame a Soporte de emergencia +7 (8512) 64-55-05.
Nuestro especialista lo ayudará en cualquier ciudad que no lo sea.