(352) > при снятии с проведения начисления ЗП, херятся у автора все записи в ЖР..
- ??? немножко не так... херятся они при перепроведении документа начисление ЗП, в котором отрабатывает штатный оператор ОчиститьДвижения() - а вот почему он прибивает весь ЖР при этом перед проведением начисления ЗП - снимаетм с проведения выплату ЗП) - хз...

РЕЗЮМЕ: проблема осталась нерешенной.

362-Чучундер > Как решается, так и получается.
Со среды надо смотреть. И бэкапы использовать.

359-Ирли Бёрд > Свинтуса ты в зеркале видишь ежедневно, неблагодарного. А Ёпрсту респект, 3 дня ковырялся, время свое тратил, жаль что не получилось.

363-VZ > Бэкапы разные поднимали, сильно старые времени уже нету поднимать. С момента перехода на ноябрь все перепробовали, везде рушится в итоге.

(363) это понятно. кроме того что восстановить работоспособную базу - еще бы хорошо хотя понять ГДЕ косяк..? пока - это непонятно...

Вот именно... "Рушится". Ага. Берет, и рушится. Сама. Ага.

(367) ну хз.. сама или не сама.. есть база (как проверить ее нет ли вней бяк - хз). есть последовательность действий, которая приводит к бяке... пока все... дальше - непонятно...

368-Чучундер > Чо непонятно? Причины разрушения дбф-[filolog]ных[/filolog] баз известны, в основном. Это размещение не в подходящей файловой среде (надо ntfs), это слишком разросшиеся таблицы (для 1С - это гиг, касается и индексов), это рассыпающийся диск, наконец, обиженный админ, хорошо знающий структуру... Самая популярная причина - это прокладка. С энтузиазмом, и кривыми конечностями.
Чей девиз "Бэкапы делают чайники".

369-VZ > НТФС есть, таблицы маленькие, винт целый, за админа не могу сказать, там их куча менялась. Бэкапы делались, но какой от них толк, если при ТИИ все они как один ровные, а проблема вылезает после?

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

371-Fold > И стабилизатор питания есть?
Должна быть внешняя причина. Чудес не бывает. Движок 27 устойчивый, работает ровно до 2008 и севена, проверено.
Еще сеть может быть виновата.
Если таблицы рвутся регулярно, рекомендую базу разместить локально, на комп расчетчицы. Бэкап наладить на сервер. Имена бэкапов должны включать дату: *20121214*.zip Хранить не менее 10 дней.
Поместили базу локально, и не мучая расчетчицу, ищем причину сбоев.

372-VZ > Там помимо расчетчицы еще 3 кадровика. База на сервере, они все по RDP конектятся. Если локально к расчетчице поставить базу то по сетке устанут они туда сюда гонять ее, тем более сеть сбоит бывает. Бэкапы делает расчетчица вручную после сбоя в июле регулярно, хранятся за последние пол года уже, места мало занимают на 7-ке, не критично.

Стабилизатор сказал купить. Админ бычит что это ниче не даст, но вроде как купить хотят.

"Поздно, Вася, пить боржом, когда почки отвалились!"

374-Fold > Сеть пусть протестирует. Не умеет - пусть ищет сетевика. Бычит он.

373-Fold > Бэкапы надо делать не руками, а автоматом. Минус админу, а тебе - два жирных. Три кадровика - это круто. Это, кстати, серьезная опасность саботажа, ибо для маленькой базы кадровик вообще не нужен, а три - это три бездельницы, обеспокоенные тем, что кто-то может удивиться: "А зачем, собственно, мы их кормим?"
У меня одна расчетчица (без кадровика) ведет базу с 600-ми сотрудниками, и не чирикает. Другая - базы поменьше (в среднем на 40 юзеров), но четыре. Она же и кадровик. Тоже не чирикает.

(376) Так ведь [b]терминал[/b] же! Физически база не покидает сервер, да и при локальной работе вылазят косяки, см. (4).

Мне, что ли, тоже попросить базу глянуть? Есть одна мыслишка... хотя нет, не надо: энтузизисты еще не кончились и ценник не озвучен. Да и переход на новую базу всяко дешевле будет.

378-Ткачик > Терминал я как-то пропустил :) Да, тогда сеть непричем. Хм.
А переход на новую базу - теперь только через месяц. Не раньше.
И все таки, ИМХО, скорее причина внешняя.

(379) А, может быть, и внутренняя... Помнится несколько лет назад на этом самом форуме некая Юля06 привела пример "штатного" дублирования внутренних идентификаторов. Народ тогда проверил, убедился и постановил считать это не глюком, а фичей. :)

Не причина в этом , я её нашел.
Ща поправлю - кину на проверку.

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

(382) не..
у автора косяк только в ЖР.
первичный документ Ввод расчета по списку сотрудников за 01.01.2010 имеет родительские документы за 10,11,12 года
:) и таких документов много.

377-VZ > Я сам в шоке, 1 расчетчик, 3 кадровика. :) А бэкапы я специально сделал чтобы ручками, мало ли что.

382-Синегурочка > Белая полностью 27я платформа стоит, ТИИ не находит ничего.

380+
у меня оно и в Бух 7.7 на SQL дубли появлялись. когда во второй раз появился дубль, я согласился на 8ку, благо до НГ недалеко оставалось.

383-Ёпрст > "первичный документ Ввод расчета по списку сотрудников за 01.01.2010 имеет родительские документы за 10,11,12 года" - а вот теперь сузим раскрывшиеся глаза, и начинаем думать, не привлекая нечистую силу в качестве объяснений (бритва Окамы).
Каким образом в 2010 году появились документы 2012 года? Ведь чтобы были ссылки, надо чтобы были документы, не так ли? Поле IDDOC, являющийся основой для формирования ссылки, объявлено в индексе уникальным, и платформа следит за соблюдением уникальности. Так что же произошло?
Первый вариант: активная работа при разрушенных индексах. Юзеры презирают сообщение, что был несанкционированный вылет, и не переиндексируют базу. Здесь нужна а) воспитательная работа б) организационная работа ([b]запрет[/b] запуска в монопольном режиме + скрипт восстановления индексов. Последний доступен интерактивному запуску, а так же автоматически выполняется автоматом каждые сутки до начала работы. Прмечание: переиндексации предшествует снос файлов cdx).
Второй вариант: Документы 2010 года были удалены без контроля ссылочной целостности ("Оне мне не нужны"). Как известно, платформа без специального режима "сжатие БД") записи не удаляет, а ставит специальный бит (флажок) удаления. После чего запись становится невидимой в 1С. И при создании новых записей платформа первым делом ищет такие псевдоудаленные записи, и размещает их в тех позициях. Чтоб не делать дефрагментезацию таблиц. Кстати, именно Расчет ну ооочень активно использует этот механизм для ЖР. Борьба с этой бедой традиционна: полный запрет на удаление без контроля ссылочной целостностью. И для себя, любимого, тоже.
Другие варианты требуют отложить бритву Окамы ;) и рассматривать тонкую диверсию.

(387) лень качать
приведи здесь значения IdDoc из документов - есть одно подозрение

(387) не, всё гораздо банальнее - тупое игнорирование о переиндексации базы, когда она того просит

Автор, посмотри это (я там даже твои "пустые" даты не трогал)
[url]http://rusfolder.com/34105043[/url]

(387) заставить переиндексироваться гораздо проще
ночью стартует задание, которое

1. делает регламентную копию
2. сносит индексы

при отсутствии индексов фиг они войдут в базу

на самом деле вывод уже есть - база на сервере в терминале. Значит, либо аппаратный косяк на сервере, либо .....

у автора, вот такая картина в ЖР:

[img]http://s2.ipicture.ru/uploads/20121214/B0rAFUt5.jpg[/img]

и записи на род документ начинаются с 2010 года

ну и таких документов.. дофига.

а при отмене проведения.. там тупой алгоритм - удаляет все записи ЖР, вот она ему и прибивает его весь целиком
:))

389-Ёпрст > "всё гораздо банальнее" - см.вариант 1 (387) - про то и речь.
390-Helen1986 > Угу. Только это означает, что каждое утро оне начинают работу со входа в монопольный режим. Ну зачем их так мучать? Надо быть гуманее к юзерам :) После удаления индексов просто запускаем на исполнение в пакетном режиме, заставляя конфу переиндексироваться, и выйти. Тут не надо ничего изобретать, достаточно команд пакетного запуска.

(395) можно и так

Всем физкульт-привет!
Автоматическую переиндексацию реализовал у себя не только по ночам, но и в случае, если она требуется во время работы, в разделённом режиме. Причём пользователь не может отказаться от неё, так как она происходит автоматически при попытке входа даже в разделённом режиме.
Подробности здесь:
[url]http://pl1c.org/publ/1-1-0-14[/url] (читать сообщения с 19 по 26)

397-volk13 > А зачем проверять "бит завершения"? Ведь время-то для переиндексации выделено? Нет? Тогда зачем проверять? Беспокоишься, что сервер вспотеет зря? :)

Да, еще. Обоснование FAT для диска со свопом: в FAT таблица заголовков файлов целиком загружается в память. Поэтому поиск нужных фрагментов осуществляется быстрее. Вот и все.

389-Ёпрст > Алгоритмом которым ронял до этого не роняется база.

393-Ёпрст > Ты таким докам самого себя в родителя воткнул?