noxxx писал(а) 05. Ноября 2009 :: 14:38:

Все старые исправить а новых ошибок не должно возникать.
разбираться почему появляются.
У всех не появляются у Вас появляется.
Вы что хотите сказать что sql сервер сам придумывает какие-то движения (и даже записывает их по нескольким таблицам) ?

noxxx писал(а) 06. Ноября 2009 :: 09:39:

Может документ пришел из переф базы и там были созданы именно такие движения.
Сделай документ непроведенным. Снова проведи.
Появились или нет "левые" движения ?

Ветку не хочется всю перечитывать.
У тебя вроде базы одинаковые я имею ввиду параметры миграции
e документов справочников регистров констант какие ?

Z1 писал(а) 06. Ноября 2009 :: 10:10:


Место создания и центр, кроме нескольких констант. Ни на одном регистре не стоит галочка "запретить миграцию движений".

Мое мнение.
1. На выходных сделай полный обмен.

2. делаешь копии всего и sql и каталогов баз ( центральная + переф базы).

3.
В переф базе отмени распределеность.
Далее из нее делаешь Центральную распределенную
( с трехзнач кодом ). Создаешь на том же компьютере новую переф базу ( тоже с трехзначным кодом) после этого делаешь несколько обменов
Далее переносишь централ базу на кокой либо носитель и
разбираемся с сервером где центральная : текущую базу удаляем
с носителя востанавливаем.

Ну сам посуди.
Что у тебя сейчас с базой непонятно.Там из-за некоректных действий что-то нарушено. Найти все что там нарушено либо нереально либо надо очень много времени.
В твоем случае легче из переф базы все перевостановить.
Ну также перед выполнением этой операции можешь проверить какие либо показатели.
Остатки на складах.Взаиморасчеты по важным клиентам.и.т.д.
Опять же у тебя останутся копии и можешь их развернуть на вспомагательном сервере(псевдосервере)

Также можешь потренироваться и сначала все предложенное сделать.как бы на копии и убедиться что все работает.

Ну и конечно такие координальные действия нужно делать через руководство чтобы оно знало что ты исправляешь "недоделки"
предшественников.

Тем более сам говоришь база стала лучше работать т.е. у тебя уже есть положительные результаты  

Что-то вы не туда пошли - сервера, УРБД, бекапы....

Для начало нужно определится что за глюк -  "железный" или "софтовый". Судя по топику глюк выражается в том, что в определенном файле (или группе файлов) мы имеем записи, которые там быть не должны. Когда происходят проблемы при записи на диск, связанные с железом, то обычно вместо необходимых записей мы получаем "мусор" - набор символов, не несущий информации. В нашем же случае мы имеем структурированную информацию, которая полностью отвечает всем необходимым параметрам. Тоесть с точки зрения железа - все правильно, никаких нарушений. Неправильность видится со стороны софта - согласно бизнес-логики программы - в регистре этих "правильных" данных быть не должно. В результате этого коротко анализа можно с большой долей вероятности забыть про сервера/винты/память и прочее.
Давай-те лучше рассмотрим подробнее софт:
На мисте (ссылка из первого поста) Ёпрст давал ссылку на описание таблиц 1С - вот с их изучения и надо было начать - там видно логику работы 1С с таблицами БД - как взаимосвязаны регистры и документы и тп.
Теперь попробую описать действия 1С при проведении и отмене проведения документа (рассмотрю только регистры).
При проведении документа 1С добавляет в регистры записи, которые в качестве указателя на документ имеют поле IDDOC (такой же как у нашего документа в 1SJourn). Логично предположить, что если мы вручную в регистр добавим запись с любым движением и IDDOC равным нашему документу, то в режиме 1С у этого документа добавится еще одно движение. Но при перепроведении документа эта запись удалится. Объясняется это тем, что 1С (в случае установленной галки автоматическое удаление движений) при начале проводки выбирает все движения документа в регистрах и "чикает" их, а потом записывает новые движения.
Теперь объясню как "происходит" глюк у автора:
Во-первых: глюк произошел только один раз - в момент "одновременной" проводки проблемных документов. Проверяется легко: снимаешь с проводки свой ПКО, а затем выбираешь движения этого документа с помощью такого кода
Рег=СоздатьОбъект("РегистрПоКоторомуВисятЛевыеДвижения");
Рег.ВыбратьДвиженияДокумента("НашПКО");
Пока Рег.ПолучитьДвижение()=1 Цикл
Сообщить("есть движения по регистру!");
КонецЦикла;
То-есть "мусор" в регистре уже лежит, причем давно - проводка и удаление документа ничего не меняет.
Объясняется все это очень просто:
в журнале документов 1SJourn, есть специальные поля на каждый из регистров - при проведении в них ставится флаг, что документ имеет движения по определенному регистру. Сделано это затем (ИМХО), что бы при удалении движений документа (снятие с проводки) не сканировать все регистры на предмет наличия движений,  а только те, в которые писали при проведении.
Так вот в твоем случае документ ПКО имеет движения по регистру, который не отмечен в 1SJourn - соответственно при удалении дока эти движения и не удаляются.
Последствия лечить довольно легко:
1) удалить лишние движения (я давал пример кода на мисте)
2) поставить нужную галку в 1SJourn и перепровести документ (сам не пробовал, но в теории сработает)
3) ТИИ - долго, но надежно (не надо кричать, что ТИИ побьет базу - в подавляющем большинстве базу бьют "сверхумные" админы)

Причина глюка:
Точно не скажу причину (не хватает мне опыта для подобных исследований), но умные люди подсказали несколько очень правдоподных вариантов forum.mista.ru/topic.php?id=391827



Сорри за длинный текст.

ЗЫ если я оказался в чем-то не прав - обязательно поправьте.

Автор пишет появляются левые движения ( заметьте не итоги  а движения )

Цитата:

При отмене проведения все движения документа из таблицы ra удаляются. удаляются командой sql delete .
Если эти движения остаются в ra это говорит о диком нарушении индексации в sql. Такого я еще ни разу не встечал. ( в dbf
были проблемы с индексами).
При отмене проведения флаги rf... - сбрасываются 1с программой.

Когда есть несоответсвие полей rf c движениями ra (речь о конкретном документе)  то в УРБД при обмене 1с падает по duplicate key . У автора этого не происходит.


Базу "правили" руками. Что там могли сделать и сколько нужно времени чтобы  это исправить.
Откуда известно что только регистры изменили ?

Смотри есть две базы которые должны быть идентичны а этого нет.
В одной есть ошибки в другой нет.
Мое мнение легче заново создать(пересоздать) УРБД чeм искать баги в базе после ручного редактирования.

Цитата:
не нашел ни одного варианта решения в этой ветке одни только предположения. Может назовешь конструктивное предложение из этой ветки ?