Версия для печати темы (https://pro1c.org.ua/index.php?s=5ab48947b575ccbd48ccf3673f38073c&showtopic=4834)

Автор: tepliymv 23.09.11, 14:16

инфа довольно интересная, но у меня файловая база (

Автор: logist 23.09.11, 14:19

Посмотрите еще это http://pro1c.org.ua/redirect.php?http://www.0xc0000005.com/index.ru.html на всякий случай.

Автор: tepliymv 23.09.11, 14:37

больше предложений нет ?

Автор: Flexy 23.09.11, 14:42

А такие простые вещи, как Тестирование и Исправление и Выгрузить/загрузить пробовали?

Автор: rsu5 23.09.11, 14:45

х

Автор: tepliymv 23.09.11, 15:13

канеша, это первое что я сделал.
так же пробовал выгружать базу и загружать по новой.
платформу обновил, ниче ((

всем спасибо за внимание , проблема решена

Автор: Flexy 23.09.11, 15:14

Ну так поделитесь решением проблемы

Автор: mister-x 23.09.11, 15:18

от жеж, поки писав пост - не побачив, що проблему вирішено якось вже

Автор: tepliymv 23.09.11, 15:36

собственно проблема оказалась в конфе, более детально описать не могу так как сам не программист 1С, а сисадмин. Ну а майкрософт как обычно с своими ошибками кого угодно в тупик поставит. из выше указаной ошибки полезной инфы ровно ноль!!!!

если не ошибаюсь проблема была с регистраторами

Автор: mister-x 23.09.11, 15:43

скажіть хоч, що ви зробили для її вирішення чи це робили не ви?

Автор: tepliymv 23.09.11, 16:04

в том то и дело что не я решил проблему, но на сколько понял на программист убил регистратор и заново затянул из более старого бекапа и стало все гуд )

Автор: kivals 24.09.11, 17:25

Похоже дело было в каком-то битом потоке объекта конфигурации - это частый сбой при динамических обновлениях. Сам бился с подобным несколько дней в УПП Тоже решилось заменой объекта в конфигурации

Автор: logist 24.09.11, 19:51

Отсюда вывод, динамическое обновление еще не совсем динамическое )

Автор: yuritch 23.04.12, 16:57

Сегодня столкнулся с этой же бедой. Почитал тему, полазил по ссылкам. В итоге помог вот этот скрипт с Мисты (выполнять в консоли SQL-сервера):

use ИмяАктуальнойБазы
go

truncate table [dbo].[Config]
truncate table [dbo].[ConfigSave]
truncate table [dbo].[DBSchema]
truncate table [dbo].[Params]
--truncate table [dbo].[Files]
go

insert into [dbo].[Config] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Config]
insert into [dbo].[DBSchema] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[DBSchema]
insert into [dbo].[Params] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Params]
go

В чем вообще проблема: после каких-то динамических обновлений конфигурация оказывается запорчена. Это выражается разными симптомами - не проходит применение изменений из Конфигуратора, юзеры вылетают в винду с ошибкой basic.dll, тестирование и исправление просто закрывается и т.п.

Что нужно для исправления: заменить конфигурацию на исправную из бэкапа. Если бэкапы регулярно не делались - Вам сильно не повезло.
В чем подвох: Конфигуратор это сделать не может. Даже при попытке Загрузить конфигурацию (а не Сравнить/Объединить) Конфигуратор падает на этапе принятия изменений.
Выход: заставить SQL-сервер сделать всю работу.

Конфигурация хранится в таблице Config, ConfigSave = непримененные изменения. Мы просто затираем нашу испорченную конфигурацию и потом вставляем поверх нее рабочую из бэкапа. Данные при этом не страдают. Всего-то и нужно развернуть бекап на том же сервере, но в другую базу, и выполнить скрипт, поменяв имена баз на свои.

Автор: yuritch 25.04.12, 6:36

Еще по теме: вот http://pro1c.org.ua/redirect.php?http://infostart.ru/public/116123/ все о том же. Там еще и комменты почитать стоит - в них есть пример такого же "лечения" для базы на PostgreSQL. Вдруг кому поможет.

Автор: yuritch 31.05.12, 14:16

Дополнение по теме: думаю, что нашел, при каких условиях этот глюк происходит.

Требуется: сетевая версия 1С 8.2 (с другими не проверял), 2 и более компьютеров (назовем их А и Б), с которых делаются динамические обновления.

Исходные данные: на компьютере А открыт Конфигуратор с изменениями, на компьютере Б открыт "пользовательский" режим. С компьютера А применяют изменения динамически. После этого на компьютере А Конфигуратор закрывают, и открывают его на компьютере Б (не закрывая окно 1С Предприятия).

Что происходит: на машине Б в этот момент находится "неправильная" копия метаданных (в кэше метаданных), так как окно Предприятия не закрывалось и заново метаданные с сервера он не получил. Открываем Конфигуратор, и он (очень похоже на то) использует эту же самую, уже устаревшую, локальную копию! Делаем изменения. При применении изменений из такого Конфигуратора, похоже, и происходит "порча" базы.

Как избежать: после динамического обновления перед открытием Конфигуратора с другой машины обязательно на этой машине закрыть все окна 1С и очистить локальный кэш метаданных. Или, как вариант, все изменения конфигурации делать всегда с одного и того же компа.

Автор: Ardi 31.05.12, 15:12

Какая именно ЭТА ошибка?

Автор: yuritch 01.06.12, 8:27

Та ошибка, о которой вся тема, в которую я написал. Всегда Ваш, К.О.

Автор: irteg 08.04.13, 6:57

Скрипт выше помог, спасибо автору

Автор: belimencko 15.12.20, 13:57

Получилось решить подобную ошибку внесением изменений в конфигурацию. Но изменения были плановые, доработки модуля объекта документа.
Предположительно, предыдущие изменение были не правильно установлены..а