1С:Предприятие 8.1 (8.1.15.14)
Бухгалтерия предприятия, редакция 1.6 (1.6.25.6)
База была на MS SQL 2005
Перенес на PostgreSQL Database Server 8.4.3-3.1C

При создании новых документов (пока были замечены списание, перемещение, требование-накладная) они не появляются в журналах документов хотя движения создаются, что видно из ОСВ.

После тестирования и исправления с настройкой "создавать объекты" сообщение:
Проверка логической целостности. РегистрНакопления.ИПИныеМатериальныеРасходы <Объект не найден> (184:a96a0022151dbde611e01bc4cd742c7a):1
   Неверная ссылка на регистратор. Создан новый объект. Документ.ТребованиеНакладная

В чем дело? Как исправить ситуацию?

(0)[они не появляются в журналах документов]
у бухов есть гнилая привычка ставить отбор на год

(1) Проверено :( Не в интервале журнала дело. Просто у нового документа отсутствует номер. В ОСВ регистратор проводки показан как "Объект не найден (многокраказябр)"

(2)[Просто у нового документа отсутствует номер]
пипец конфе
лезь в подписки

(0) зачем переходили?

походу грохнули документ непосредственно

*пипец конфе

разве переход может так повлиять?

(0) кстати база типовая или переписанная?

(6) раз 1С позволяет записать документ без номера, значит так перешли на PostgreSQL

(8) Как "Так"? Более предметно, пожалуйста.

Перед выгрузкой из MS SQL делал 1С Тестирование и исправление, затем регламентированное обслуживание средствами MS SQL.

Затем загрузка в PostgreSql на новом сервере.

(7) База типовая с минимальными изменениями. В тех документах с которыми "косяки" изменений нет.

(4) Во-первых перешли на новое железо. Во-вторых вместо пиратской MS SQL поставили "свободный" PostgreSql.

(5) Более развернуто можно?

База здоровая? Если например сейчас сделать из нее выгрузку и загрузить в файловую - то эти документы видны?

(13) В файловую загрузить нет возможности, т.к. размер базы более 10 Гб.

Кстати, да, а не ТиС случаем, эти документы грохнула?

(15) Конфа: Бухгалтерия предприятия, редакция 1.6 (1.6.25.6)

2(14) Это еще ни о чем не говорит... в файловую нет возможности загрузить если одна таблица в файловом варианте занимает более 4 Гиг..
10 Гиг - это выгрузка в ДТ? или Папка в Постгрессе?

Ладно, если даже не файловая - попробуйте загрузить обратно в МС СКЛ - эти документы там будут?

(16) Причем здесь конфа. ТиС - это Тестирование и исправление

2(19) Тестирование и Исправление, это очевидно ТиИ...
а ТиС - это Торговля и Склад

(20) Видел оба варианта сокращения, да и по контексту можно догадаться...

2(21) это не вариант сокращения... Это просто невнимательные пальцы... По контексту догадаться можно, но мы тут собрались не ребусы разгадывать

(19) До ТиС документы уже были без номера. Движения есть а документ в журнал не попадает потому что у него номера нет. А ТиС доки восстановила но с незаполненной ТЧ и пустыми реквизитами шапки. Но движения все равно в ОСВ остались.

(22) Действительно, абревиатура ТиС путает. Лучше уж ТиИ.

2(23) а мы сейчас какую базу имеем - с непоказываемыми документами просто, или с документами-пустышками, созданными ТиИ? если второе, то уже все.

2(24) нету аббревиатуры ТиС.  вернее она относится для конфы в77 Торговля и Склад. ТиИ - это и есть Тестирование и Исправление.

(23) Так погоди, ты загружал уже битую базу? Может после исправления стоило руками все исправить, перепровести доки, сделать еще одно тестирование и исправление, а только потом выгружать? Я бы, честно говоря, сделал именно так...

2(23) Можно что посоветовать сделать... Взять еще ту базу на МС МСКл, при условии что ее еще не грохнули - сделать чтобы у тех документов были номера, и при помощи обработки выгрузказагрузкаданныххмл.епф с ИТС выгрузить эти документы, и загрузить ею же в Постгресс-базу... Можно даже с движениями. Синхронизация будет по УИДу, так что этот вариант годен даже если у вас документы-пустышки созданные ТиИ

(0) одна из версий данного поведения - это некорректная работа 1С версии 8.15.14 с PostgreSQL 8.4.3. Если не углубляться в подробности сильно, то при записи документов в постгри происходит ошибка, однако движок 1С ее игнорирует и не откатывает транзакцию. В результате имеем движения регистров без документов. К сожалению, проверено на личном опыте.

В общем, ставьте PostgreSQL 8.3.8

(27) Ошибочные документы создавались уже в базе загруженной в PostgreSql. В базе MS SQL было все ок.

+(30) что еще раз косвенно подтверждает (29). Ставьте PostgreSQL 8.3.8. Вот только "испорченные" документы придется ручками восстанавливать к сожалению, поскольку в базу они не записались. Ради интереса еще посмотрите: в журнале PostgreSQL скорее всего увидите ошибку base x of block xxx/xxx/xxx is still referenced (local x), где x - это произвольные цифры. Вот сколько таких ошибок найдете - столько документов и испорчено...

(31) А можно версию откатить без выгрузки\загрузки базы? Глупый вопрос наверно, но неохота сутки опять убивать на выгрузку\загрузку.

(32) Врать не буду - не делал, но скорее всего нет. Сам всегда делал через выгрузку/загрузку через *.dt

(32) странный вопрос, pg_dump/pg_restore релиз PostgreSQL не важен

(0) пока больше ничего не натворил немедленно сноси 8.4.3
Мы напоролись на эту хрень весной.
Документ создаешь, проводишь, он проводится, движения в регистрах делает, а сам документ не сохраняется, а записи в регистрах есть и номер документа занят.
Теперь тебе еще и регистры чистить от битых записей...

(31) самое забавное что документа нет, а движения все есть, у нас были 2 принятия к учету ОС, вот была развлекуха )))

Сделали лучше, не стали удалять движения, а восстановили объект по известному идентификатору

(+36) обработкой типо этой http://infostart.ru/public/74186/

(37) Описание обработки:
{Достаточно часто встречаются случай, когда необходимо
восстановить удаленный объектиз базы.
Возможно остались ссылки и система сообщает, что
"Объект не найден".
Такой объект можно восстановить с помощью этой обработки.
Достаточно знать его ID и тип.

Объект создается ПУСТЫМ!}

А зачем он мне пустой? Тестирование и исправление тоже пустой создает...

2(38) Блин, да восстанови его из МС СКЛ копии, в (28) рецепт

(39) не сможет он их восстановить, этот документ никогда в базу не записывался...

(40) неужели до сих пор стабильной версии постгрии не появилось?

*стабильно работающей

(40) а!

(41) 8.3.8 стабильно работает, думаю в к концу января попробовать на 9-тку перелезть попробовать на каком-нибудь филиале, потестить...

+(44) да и хотелось бы задать официальный вопрос фирме 1С о совместимости 1С 8.1.15.14 и PostrgeSQL 9.0.1, а то подозреваю предложат перейти на 8.2... блин, надоело быть бета-тестером - хотелось бы сосредоточится на прикладных задачах (мысли вслух)...

Как вы вообще можете полагатьтся на учетные системы с такими вот глюками??

(46) предложи альтернативу

2(47) ДБ2 Екпресс-Ц 9.7.1 :)

(47) как алтернатива БД - MS SQL - просто и надежно

2(49) Линукс-сервер 1С не может держать базу на МС СКЛ.

(50) это еще почему ? ему что есть разница где находится движок БД ? или у него радикальные отличия от 1с сервера для виндуз ?
(систему 8юх видел только на картинках)

8.х

2(51) бикоз нет реализации МДАК под линукс.. как я понимаю

http://v8.1c.ru/overview/cluster_linux.htm

Особенности рабочих серверов под управлением Linux

не могут взаимодействовать с СУБД Microsoft SQL Server;
не поддерживается работа с СОМ-объектами;
аутентификация на сервере выполняется по протоколу Kerberos;
не доступна работа с Интернет-соединением.

ясно - в топку значит

(51) [систему 8юх видел только на картинках]
ниже картинки есть подписи
о невозможности гетерогенных систем сервер 1С - сервер СУБД

2(55) точно. Кому он нужен такой прожорливый и замкнутый...

(0) если вот это

При создании новых документов (пока были замечены списание, перемещение, требование-накладная) они не появляются в журналах документов хотя движения создаются, что видно из ОСВ

можно воспроизвести руками в любой момент, то виноват либо переход, либо какой-то идиот, поломавший конфу. Однако мне почему-то кажется, что воспроизвести не получится и документы в лабораторных условиях нормально проведутся и сохранятся. А это будет означать, что какой-то товарещ развлекается непосредственным удалением объектов.

PostgreSQL откатывать на версию 8.3 не стал т.к. сейчас идет активный переход на Бухгалтерию 2, которая уже на сервере 8.2. (он должен корректно крутиться на PostgreSQL 8.4)

P.S. Если перечисленные доки (списание, требование-накладная и перемещение) перед проведением записывать, то им корректно присваивается номер и они появляются в журналах. Но при проведении опять ошибка хотя по ним создаются корректные проводки. Обработкой ставлю реквизит "Проведен" в Истину и записываю док, чтобы не нервировать лишний раз бухов.

В новой конфе после выгрузки доков все поправим и заживем весело и дружно.

Все двойные, ошибочные движения отследил и убрал из базы.

Еще, что интересно "траблы" только по одной организации. Бухи которые работают по другим организациям даже ничего и не заметили.