- El archivo de mensaje ya se ha cargado en la base de datos receptora. Debe descargarlo nuevamente de la base de datos fuente.
Error "Error al copiar un archivo desde un recurso FTP... Error al trabajar con Internet: se alcanzó el tiempo de espera"
- No es posible copiar el archivo requerido desde el sitio a través del cual se realiza el intercambio. Esto podría deberse a que su conexión a Internet es lenta o a problemas con el sitio en sí.
- Debe intentar repetir el intercambio después de 15 a 30 minutos.
Error: Está prohibido editar datos para este período. Los cambios no se pueden registrar..."
- Los datos descargados contienen documentos del período cerrado.
- Es necesario realizar el intercambio bajo usuarios que tengan derecho a cambiar documentos durante este período.
Error: Es necesario realizar actualizaciones de la configuración de la base de datos. La actualización se puede realizar en modo configurador"
Motivo: Los programadores cambiaron la configuración en el centro. Solución: actualice la configuración modificada en la base de datos del periférico. Para esto:- Ir al configurador.
- Ejecute el elemento del menú “Configurador / Actualizar configuración de la base de datos”.
- Si se muestra una pregunta con solo las respuestas "Repetir", "Cancelar", "Actualizar dinámicamente", haga clic en el botón "Actualizar dinámicamente".
- Si aparece una pregunta con solo respuestas "Reintentar" y "Cancelar".
- todos los usuarios cierran sesión en 1C.
- presione el botón “Repetir”.
- Responda afirmativamente al resto de preguntas: “Sí”, “Aceptar”, “OK”.
- Cierra el configurador.
- Repita la carga desde el centro.
Error: “La configuración no coincide con la esperada”, “Intentando aceptar cambios de una configuración desconocida”
- Error de la base de datos.
- Es necesario contactar con especialistas.
El intercambio tarda mucho y se congela.
Posibles razones:- Están llegando muchos datos.
- Averigüe con el remitente si realizó un cambio grupal de documentos (publicación, cambio de detalles, etc.).
- Si es así, deja la computadora con el intercambio durante la noche.
- No se puede descargar un archivo grande de Internet.
- Si el archivo es grande (80-100 MB o más), quizás 1C simplemente no pueda descargarlo.
- Debe descargar el archivo y cargarlo en 1C manualmente (posiblemente con la ayuda de especialistas).
- elemento de menú “Operaciones” / Planes de intercambio / Completo / Botón en el panel “Leer mensaje”.
- La base de datos está dañada:
- Intentalo
- Si estos pasos no ayudan, deberá ponerse en contacto con especialistas.
- Si el error no se puede corregir, llame al número de soporte de emergencia +7 (8512) 64-55-05.
- Nuestro especialista te ayudará, sin importar en qué ciudad te encuentres.
A menudo se utiliza una base de información distribuida (DIB) para organizar el trabajo de sucursales y divisiones, lo que permite el rápido intercambio de información manteniendo el grado requerido de autonomía. A pesar de que esta tecnología es bastante fiable, de vez en cuando falla. Hoy veremos uno de los errores bastante comunes: le informaremos sobre las razones de su aparición y los métodos para solucionarlo.
Empecemos, como siempre, desde el principio. Una vez que haya creado el RIB, todos los cambios en la configuración de la base de información solo se pueden realizar en el nodo principal. Posteriormente, durante el siguiente intercambio, todos los cambios se transferirán a los nodos esclavos y se aplicarán allí automáticamente. Pero sobre el papel era suave...
En la práctica, a veces sucede que entre sesiones de intercambio, especialmente si el canal de la periferia está defectuoso, la configuración del nodo principal logra cambiar dos veces. Por ejemplo, hicieron cambios, los subieron, la base de datos periférica recibió los cambios, pero aún no los aplicó, lo que puede tardar algún tiempo, y aún no envió confirmación. Si vuelve a realizar cambios durante este período y carga el intercambio nuevamente, resulta que el centro espera ver la configuración No. 1 en el nodo periférico e intentará actualizarla a la configuración No. 3, pero de hecho encontrará la configuración No. .2 allí. A veces ocurre una situación similar durante la actualización dinámica de la base de datos central. Como resultado, el intercambio será imposible y recibirá un mensaje indicándole que ¡La configuración del nodo de seguridad de la información distribuida no coincide con la esperada!
En general, la moraleja de esta historia es simple: no perfeccione activamente la base de datos de trabajo y, si lo hace, complete todas las sesiones de intercambio antes de realizar los siguientes cambios. ¿Pero qué pasa si ocurre tal molestia?
La solución sencilla es crear una nueva imagen del nodo esclavo, pero en la práctica esto no suele ser aplicable. Como regla general, la aparición de un error grave durante el intercambio no se detecta inmediatamente, sino algún tiempo después de que los datos operativos de las bases de datos periféricas ya no llegan. Dependiendo del cronograma de comunicación, puede pasar un día hábil completo o más entre el momento en que ocurre el problema y su descubrimiento.
Aquí vale la pena tirar una piedra a los desarrolladores, quienes lo reportan como un error y resaltan la situación en rojo de la misma manera. El número de mensaje es menor o igual que el número de un mensaje recibido anteriormente, lo cual en general es bastante normal. Como resultado, la percepción de los errores por parte de los usuarios se embota y simplemente dejan de leer los mensajes mostrados, creyendo que todo está bien y que la otra parte aún no ha realizado el intercambio.
Pero volvamos a nuestro error. La solución es bastante sencilla y está en la superficie: llevar la configuración de la base periférica a la esperada, es decir alinearlo con la configuración del nodo central. Pero en la práctica esto no es tan fácil. Si abrimos la base de datos de periféricos en el configurador veremos que los cambios quedan bloqueados por las herramientas de gestión de RIB.
Para cambiar la configuración de un nodo esclavo, deberá desconectarlo temporalmente de la base central. Para estos fines, puede utilizar una de las opciones de procesamiento que se encuentran en abundancia en la red, o desconectar la seguridad de la información del nodo central. usando el parámetro de inicio del Configurador/RestablecerNodoMaestro.
Abra un símbolo del sistema e ingrese (teniendo en cuenta la versión de la plataforma y la ruta de instalación real):
Configuración "C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" /ResetMasterNodeDespués de ejecutar este comando, aparecerá la ventana de inicio habitual, seleccione allí la base deseada y haga clic en el botón Configurador.
Lanzar la seguridad de la información al mismo tiempo. No pasará, es decir. Puede parecer que no pasó nada, pero al abrir la base de datos nuevamente en el Configurador, puede asegurarse de que esté desconectada 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 provoca un bloqueo. El error se solucionó en la plataforma 8.3.10.
Si no quiere perder el tiempo con la línea de comando, puede usar uno de los tratamientos; a continuación se muestra el que usamos; se encontró en Internet y solo le hicimos cambios cosméticos. Tenga en cuenta que el procesamiento solo es adecuado para una aplicación normal; para configuraciones en una aplicación administrada, use la tecla de inicio del Configurador.
Trabajar con él es extremadamente simple, lo ejecutamos en modo 1C:Enterprise, a través de Archivo - Abrir, luego simplemente presione el botón deseado, en nuestro caso Deshabilitar el nodo maestro.
Ahora necesitamos la última configuración del nodo central. Para esto abriremos seguridad de la información central en el Configurador y ejecutar Configuración: guardar la configuración en un archivo. El archivo resultante con la extensión cf deberá enviarse a un nodo periférico.
Luego, en el nodo periférico, lanzamos la seguridad de la información (previamente desconectada del nodo principal) en el Configurador y la retiramos del soporte. Para hacer esto, elija: Configuración - Soporte - Configuración de soporte.
En la ventana que se abre, primero habilite las opciones de edición.
Y luego eliminamos la configuración del soporte.
Ahora puede cargar la configuración desde un archivo, para ello seleccione Configuración: cargar la configuración desde el archivo e indicar no transmitido desde el nodo central cf-archivo. Después de lo cual recibirá una advertencia de que la configuración actual no está vacía. Tenga en cuenta que las manipulaciones que realizamos son potencialmente peligrosas y pueden provocar daños irreversibles a la seguridad de la información, por lo que antes de continuar, asegúrese de tener una copia de seguridad actualizada.
Primero, una lista de abreviaturas utilizadas:
- RIB - base de información distribuida
- CB - base central, nodo raíz de RIB
- UB - base remota, base de datos de un nodo RIB remoto
Por mi propia experiencia, puedo decir que encontré dos razones para el error:
- Al recibir el archivo de mensaje, la base de datos "cayó" en el sistema de gestión y, por lo tanto, aparentemente hubo una desincronización entre el archivo conf. Banco Central y UB;
- En MSSQL, el cliente descargó una copia de la base de datos de trabajo y no desactivó el registro. tareas de intercambio automático, como resultado, algunos mensajes a nodos remotos se generaron desde la base de datos de trabajo y otros a partir de una copia, lo que provocó la desincronización de las configuraciones.
También existe la opinión de que este error se debe al uso de un mecanismo dinámico de actualización de la base de datos. Hay dudas aquí, porque, por un lado, la actualización dinámica nunca afecta la estructura de la base de datos, y los mecanismos RIB aún funcionan con la estructura de la base de datos, y no con su parte aplicada; sin embargo, el RIB utiliza un mecanismo para generar una firma digital de la versión de configuración (en el futuro la llamaré hash para abreviar), y cuando la parte de la aplicación cambia, el hash, naturalmente, debe recalcularse. Ni lo negaré ni lo afirmaré, porque... Si me encontré con esta situación, no encontré ninguna evidencia clara de ello.
Para corregirlo utilizo 2 métodos, según la situación.
PRIMERA TÉCNICA
El primero (el más común) se menciona repetidamente tanto en la conferencia de socios como en otros recursos de Internet relacionados con 1C. Se utiliza en la mayoría de los casos cuando, a pesar del mensaje sobre discrepancias en las configuraciones, una comparación manual muestra que son idénticas.
Secuenciación:
- descargar el archivo cf del banco central;
- desvinculamos la UB de la RIB (el método Set MainNode, el procesamiento listo para usar se puede encontrar en la aplicación o en otras publicaciones);
- reemplazando conf. UB al archivo cf cargado en el primer paso, para esto usamos el menú “Cargar configuración desde archivo” (¡¡¡y no comparar-fusionar!!!);
- Restablezcamos el signo RIB para UX.
En la mayoría de los casos, estas acciones son más que suficientes para restaurar el intercambio, pero no siempre...
SEGUNDO MÉTODO
Se utiliza si el primer método no funcionó y no es posible descargar el nodo nuevamente.
Antecedentes: el cliente estaba configurando una RIB en cascada y se produjo un error en el primer nivel de la cascada (el segundo nivel funcionó perfectamente todo este tiempo). La configuración se desarrolló conjuntamente con el servicio de TI del cliente y desde que ocurrió el error, la configuración del banco central ha cambiado varias veces. La opción de revertir los cambios no se consideró ni siquiera en principio, porque la pérdida de algunos datos y el cierre de varios departamentos fue completamente inaceptable. La primera opción para corregir el error no produjo ningún resultado tangible. Por tanto, tuvimos que buscar otras soluciones.
Surgió la idea de intentar reemplazar los hashes de los archivos de configuración directamente en los archivos de intercambio XML. La descripción de la estructura del archivo de intercambio del libro "Desarrollo profesional en el sistema 1C:Enterprise 8" dio una idea débil de la formación de firmas digitales de configuraciones y cambios en ellas, pero determinó la dirección del búsqueda: los valores de Digest1 y Digest2. Todo lo demás lo descubrí de forma puramente empírica (es decir, por prueba y error), pero fue posible establecer un patrón.
Los experimentos de prueba tuvieron éxito. En las bases de trabajo también todo salió bien.
Entonces, la secuencia de acciones:
- realice los pasos 1 a 4 del primer método;
- Descargamos el archivo cambiario de la UB, pero no lo cargamos en el Banco Central;
- Descargamos el archivo cambiario del Banco Central, pero no lo cargamos en la UB;
- en el archivo de intercambio del Banco Central, reemplazamos el bloque que contiene información sobre cambios de configuración y hashes (Digest1 y Digest2) con un bloque de hashes del archivo UB (ver ejemplo a continuación)
- Subimos el expediente del punto 4 a la UB;
- ¡Asegúrese de sobrescribir el archivo de intercambio de UB (segundo punto)! ¡Este archivo no debe descargarse al realizar intercambios con el Banco Central!
- Para comprobarlo, realizamos varios intercambios consecutivos.
Si se utiliza compresión de datos durante el intercambio, entonces desactivamos la compresión o primero descomprimimos el archivo, lo cambiamos, luego lo volvemos a empaquetar y lo enviamos.
Bloque de archivos de intercambio del Banco Central
...aquí hay bloques que describen los cambios de configuración...
debe reemplazarse con un bloque del archivo de intercambio de UB (tenga en cuenta que Digest1 para un archivo de UB siempre es igual a “00000000000000000000000000000000”!!!)
Las acciones enumeradas deben realizarse con extrema precaución; una secuencia incorrecta puede provocar la inoperancia total del RIB. Por lo tanto, ante estas acciones, ¡crear copias de seguridad es OBLIGATORIO!
Los errores de actualización dinámica (u otros fallos de la plataforma) pueden ser la causa de errores en el intercambio de bases de datos distribuidas:
"Los datos se reciben del nodo para el cual se han registrado cambios de configuración"
"La configuración del nodo de seguridad de la información distribuida no se corresponde con lo esperado"
¿Cómo restaurar el intercambio?
Pero comencemos no con la restauración, sino con la oportunidad de realizar.intercambie "manualmente", lo cual es importante durante el día, porque, como siempre, todo debería funcionar "ayer" :) Esto se puede hacer con la ayuda de tratamientos maravillosos que no recordabanude donde lo descargué (autores, respondan; dejaré enlaces a su recurso y, si es necesario, lo eliminaré del mío)). El procesamiento permite descargar solo los cambios de datos registrados en la base de datos (¡de acuerdo con el plan de intercambio especificado para un nodo específico!) en XML sin descargar cambios de configuración y, si los objetos de configuración no han cambiado mucho, entonces existe una probabilidad muy alta. de cargar estos datos. Estos se pueden descargar desde el enlace al final del artículo.
En cuanto a la recuperación. Existen métodos más sencillos que no incluyen todos los elementos de la lista siguiente, pero no siempre ayudan, como fue el caso en uno de mis casos. Por eso, presento el método que me ayudó, evita posibles problemas de una manera más completa. Siguiente paso a paso.
Es recomendable seguir estos pasos cuando no haya usuarios activos en la base de datos. Si esto no es posible, entonces tendrás que “terminar” el método por ti mismo y, por lo tanto, primero debes comprender su lógica.
1. Haz copias de seguridad en todas partes.
2. Para servidores cliente: desactive las bases de datos a través de la "administración del servidor" y conéctelas inmediatamente con el bloqueo de tareas programadas (esto restablecerá el caché del servidor). Después de esto, no olvide transferir el registro de registro al nuevo directorio.
3. En todas las computadoras utilizadas para la recuperación, elimine la base de datos de la lista de bases de datos iniciales de 1C y cree una nueva (se borrará el caché del usuario)
4. En el configurador (en la base de datos central), agregue una nueva constante y guarde los cambios de configuración.
5. Borre todos los directorios de intercambio.
6. Realizar descargas a todas las sucursales (solo descargas por ahora).
7. Intente descargar (solo descargar) los datos recibidos en todas las sucursales. Es natural aceptar los cambios de configuración.
Si todo está bien en todas partes, seguimos adelante; si todo está mal, creemos que descargar .cf de la base de datos central y CARGARLO en la sucursal (sin comparar ni fusionar) podría ayudar. En el nodo esclavo, debe desvincular la base de datos del RIB (el procesamiento ayudará con esto; descárguelo desde el enlace a continuación). Hay un artículo sobre este tema en infostart.ru.
8. Cancelamos el registro de cambios para sucursales en el Banco Central (después de todo, ya hemos recibido todos los cambios en todas partes). Es importante hacerlo en esta etapa para que los cambios acumulados de diferentes ramas lleguen a otras ramas. (descargue el procesamiento para desvincular-vincular desde el siguiente enlace).
9. Cargamos en el Banco Central y si todo está bien, entonces cargamos y descargamos con cada sucursal varias veces para consolidar el resultado.
10. Eso es todo.
Puede habilitar la ejecución de tareas rutinarias para bases de datos cliente-servidor.
Para evitar problemas que causen este error, se recomienda no realizar actualizaciones dinámicas (al menos varias veces seguidas, hasta que los cambios se carguen en las ramas), y también es recomendable marcar la casilla "cargar datos solo después de una carga exitosa". en la configuración de intercambio.
¡Hola, queridos lectores de nuestro blog! Hoy hablaremos de
arreglando dos errores que pueden surgir durante el intercambio en una base de información distribuida (RIB). Estos errores pueden ocurrir si ha cambiado la configuración de su base de datos y está intentando transferir estos cambios desde la base de datos central a la periférica. Por ejemplo, en la forma que se describió. ¡Empecemos!
Estos son los mensajes que pueden aparecer cuando intentas realizar un intercambio mediante RIB:
"Los datos se reciben del nodo para el cual
Se han registrado cambios de configuración.
Los cambios deben transferirse
configuraciones al nodo."
“Configuración del nodo de seguridad de información distribuida
¡no como se esperaba!"
Veamos los pasos para ayudar a corregir la situación. Antes de comenzar, ¡¡¡creemos nuestra base de datos de información!!!
- Tomemos el archivo de configuración con la actualización, abramos la base de datos central en el Configurador y carguemos (Configuración-Cargar configuración desde archivo...). Guardemos la seguridad de la información (F7).
- Vayamos y carguemos un archivo para la base de datos periférica:
- Seleccione el plan de intercambio en la lista, luego haga clic derecho para abrir el menú contextual y seleccione "Guardar cambios...".
- Ahora tratemos con la seguridad de la información periférica. Abrimoslo en modo exclusivo para que no haya usuarios, y cerramos también el Configurador. Ahora necesita recordar el nodo principal de la base de datos actual. Abra Operaciones-Planes de intercambio-Seleccione su plan de intercambio (por ejemplo, “Por almacén”). En la lista de planes de intercambio, el nodo principal es el elemento con el icono amarillo. Esta información nos será útil en el séptimo punto. Abramos el procesamiento y hagamos clic en el botón "Cancelar asignación del nodo maestro".
- Ahora abramos la seguridad de la información periférica en el Configurador y carguemos el mismo archivo de configuración que cargamos en el primer paso en la base de datos central (Configuración-Cargar configuración desde archivo...). Guardemos la seguridad de la información (F7).
- Cambiemos la configuración de soporte (Configuración-Soporte-Configuración de soporte...). En el cuadro de diálogo, seleccione la celda de la tabla en la intersección de la primera fila y la segunda columna. Luego haga doble clic para abrir el cuadro de diálogo "Configuración de reglas de soporte". En él, marque la bandera "Instalar para objetos subordinados" y haga clic en el botón "Aceptar". Cierre el cuadro de diálogo de configuración de soporte haciendo clic en el botón "Cerrar". Guardar IB (F7). Cerremos el Configurador.
- Ahora abramos nuevamente la seguridad de la información periférica en modo exclusivo 1C:Enterprise para que no haya usuarios, y también cerremos el Configurador. Abramos el procesamiento Instalación de MainNodeDB.epf y seleccionemos el plan de intercambio que queremos instalar como nodo principal (en el cuarto párrafo recordamos este nodo). Luego haga clic en el botón "Instalar Master Node". Después de esto, la seguridad de la información actual volverá a ser periférica.
- Ahora en la seguridad de la información actual (periférica) abriremos los planes de intercambio y descargaremos el archivo con el intercambio de la base de datos Central, que recibimos en el tercer paso:
- Operaciones-Planes de Intercambio-Seleccione nuestro plan de intercambio (por ejemplo, “Por almacén”).
- Si todo salió bien, cargaremos el intercambio para la base de datos central en la seguridad de la información actual (periférica):
- Operaciones-Planes de Intercambio-Seleccione nuestro plan de intercambio (por ejemplo, “Por almacén”).
- Seleccione el plan de intercambio en la lista, luego haga clic derecho para abrir el menú contextual y seleccione "Guardar cambios...".
- En el cuadro de diálogo, indique la ruta y el nombre del archivo de intercambio. Haga clic en el botón "Aceptar".
- Ahora intentemos cargar este archivo en la base de datos central y abrirlo en modo 1C:Enterprise:
- Operaciones-Planes de Intercambio-Seleccione nuestro plan de intercambio (por ejemplo, “Por almacén”).
- Seleccione el plan de intercambio en la lista: haga clic derecho para abrir el menú contextual y seleccione "Leer cambios..."
- En el cuadro de diálogo, seleccione el archivo de intercambio. Haga clic en el botón "Aceptar".
Para evitar problemas con las copias de trabajo, haga primero
Cargando...
