Если открыть журнал регистрации из монитора, то види вот так
http://screencast.com/t/SjdkKk9XuWX
.
а если открыть журнал регистрации из прелприятия, то види вот так
http://screencast.com/t/goMFp9TSxIg
.
почему? поясните плиз...

У меня всё нормально кажет, проблема на вашей стороне

Может ты чужой журнал открываешь?

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

ЗЫ: ты же в предприятии щелкая по ЖР сразу можешь открыть объект, в мониторе - нет, т.к доступа в табличкам ИБ нет, только к самому файлу журнала

(3) Ну у меня пишет название документа, а не объект не найден

(4) дык ты его удали непосредственно и проверь

(5) Если я его удалю, то он и в предприятии будет писать объект не найден. Не так ли?

(6)Будет как у Чебура в (0)

Потому что приключился песец. классика как всегда.
Работа сделана, с утра в базе - "пусто".
типа "расследуем": по тем признакам какие видно - работа закончена в 20:19 (расчетчица сделала сохранение базы), в 19:45 - открыт документ. На руках у меня нормально посчитанный расчетны листок. в базе - пусто по зарплате марат, куча доков - как на картинке. в ЖР пометко об удалениях - нет. База файловая ЗИКа. Порыл слегка систему - вроде все чисто. Хз, что это могло быть..?

индексы?

Было что то аналогичное, только на бухгалтерии.

(8) индексы? восстановление системы? восстановление из бэкапа, как вариант?

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

"рухнуло" похоже в промежуток с 19-45 до 20-19...

(8) походу расчетчици вместо сохранения в бекап сделала восстановление из бекапа,
посмотри в конфигураторе

Было подобное, причем в бухгалтерии.

(8) кто-то запустил поделку непосредственного удаления объектов в конфе.

(10) + (15) Очередной бот-генератор?

посмотри записи в 1sjourn и сколько из них помечены маркером удаления - просто сыми маркер и доки появятся + сыми маркер в табличке шапки и тч дока.

Это ежели их действительно кто-то прибил

Если мне не изменяет память, я в тот момент всех выгонял из системы через обработку в которой ЗавершениеРаботыСистемы() после нескольких вопросов. А бух ушла и оставила заполненный док несохраненным. Еще подобное было, когда какая то фигня была с блокировками.  Бух создал и набил документ, но он в базе не сохранился, хотя запись что он записан была. Причем помню что че то с блокировками было. На ДБФ базах вообще часто такие приколы.

http://screencast.com/t/qe3WyQdjSGk

(17) Отвлекался, и не забыл что уже отправил сообщение в эту ветку. )

человек работал монопольно

(22) У тебя написано что документ открыт. А есть запись что он сохранен?

(18) сейчас попробую, но яне особо в этом силен

(19) расчетный листок есть, значит док был проведен

в 1Sjorn удаленных записей (именно помеченых в таблице) - нет.
Есть записи ISMARK = "*"
.
так что пока - пусто...

спроси у человека, не было ли чего то странного. Отключения света, например, визжания упса и т.д.

посмотри по журналу, точно не восстанавливала из бекапа?

(28) не, по ЖР нету записей. да и на восстановлене или загрузку прав нет у нее.

А что в шапки дбф-ки с документом с этим ID есть такой?

но что блин что сильно подозрительно - что сделано полностью все, и только после этого все "исчезло", ну не верю я в такие совпадения (параноик я)

(30) ???

Ну у тебя ID 1265. соответственно преобразовываем его в 36-ную систему и ищем документ с таким ID в DH?????.dbf

_IdToStr(1265) =     Z5
Т.е. нам нужен документ  в колонке ID у которого Z5

Был похожий случай. На сервере аппаратный рейд 1 (из двух винтов в зеркале). По ходу работы первый винт отвалился, но прекрасно работало все на оставшемся... до перезагрузки. Тогда  состема обнаружила что винты отличаются и отразила первый (отвалившийся) на второй (исправный).
Все что писалось на второй винт в это время - похерилось.

(33) пусто...

может всётаки из бекапа подняли?

(35) это мысль! а зеркало что - может вот так подняться - отразить отвалившийся на исправный?

(38) После перегрузки - может

(37) хм.. а как это увидеть...? да и нет прав на восстановление/загрузку...

(38) а первый винт при перезагрузке опять появился.
Поищи в логах не восстанавливался ли рейд ночью. Поищи на дисках: есть хоть один файл записанный в этот промежуток времени.

(39) сервак не перегружался.

(41) ща бум смотреть, админ подползет...

..я вторую половину дня и всю ночь в офисе был - все работало, ничего не глючило...

ночью вряд ли - потому как в 20-19 сохранение расчетчицей была сделана на отдельный файлсервер. и сохранено уже кривое...

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

..похерилась работа, начиная с 16:47 - всего-то 3 с половинйо часа.

(46): угумц, именно такое было. причем транзакция тупо "повисла" начатой, потом ввод, потом выход - и все что с начала зависа незакрытой транзакции - псу под хвост.

Автономные файлы поди, да ?

+ смотри атрибуты файла , когда его последний раз изменяли

(49) нету у нас такого. все в терминалке работают.

локализовал временной промежуток, когда началось что-то, что привело к глюку: всего-то 3мин 26сек

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

а не могло ли это например быть из-за того, что юзверь при заходе вбазу отказался от переиндексирования?

(54) вполне.

ТиИ сделай в копиии

еще есть один признак подозрительный:
http://screencast.com/t/FUGoDFosM
.
время у файлов 16:43 - подозрительно практически 1-в-1 совпадает с локализованным временем начала проблемной ситуации - примерно 16:43:54
.
- это чем-то поможет...?

(56) делал. все проходит чисто.

пользователь начал работать в 10:26 и колбасил до 20:19, а в 16:43 что-то наступило...

16:43:54 - проведение документа, который нормально остался в базе.
16:46:58 - создание нового документа - все доки создаваемые после этого - оказались похеренными

ага - это кто-то (или что-то) файло восстановило на это время..
типа автономных файлов

или отката системы.

(ну если бы восстановило - то дальше, что билось в базу - оно бы осталось? похерились бы как раз данные набитые с утра...?

(63): в порядке бреда... если автообновление чего-то системного в это время было - автосоздано контролпойнт, потом неудача - откат.

(63) ну, по твоим файликам видно - что с базой прекратили работу в 16.43

смотри системные логи

да смотрю уже

(65) да вот не получается такого вывода
http://screencast.com/t/4EdH6EG49V
.
и расчетчица сидела и долбила в монополе с 10-26 до 20:19

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

так, похоже что возможно было дело так:
пользователь (новый) запустил 1Ску с локального ярлыка (не зашел в терминалку). Появилось окно со списокм баз - выбрал ЗиКу, зика стартанула, сказала что заблокирована монопольно, далее отмена...
.
могло это привести к тарблу? бо больно уж по логам время такого локалного входа на сервер четко ложится в найденный мной ранее временной промежуток...

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

Чебур, беги оттуда, пока тебя не покусал барабашка!

(72) Мамонты умирают стоя!

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

Итого: если кому будет интересно.
На данный вывод такие итоги и вывод о возможной причине.
.
Безвозвратно утеряна работа, сделанная Расчетчиком в ЗиК за 3ч 35 минут, начиная с 16:43
.
Обобщенная причина потери данных - работа с файловой ДБФ и отсутствие возможности постоянного резервного копирования на лету. Рабочие бэкапы есть ночные - ввиду мизерности количества действий по базе ЗиК потеря одного дня несущественна. В течении дня бэкапы базы ЗиК не проводились сторонними средствами, Расчетчик делал сохранение самостоятельно - в 10:30 перед началом работы, и сделал сохранение в 20:19 после окончания работы - данные по ЗиКе были успешно посчитаны, распечатаны и выгружены в файлик на ЗП в банк. Однако, как оказалось - сохраненная копия в 20:19 - была "ПУСТОЙ". А самое интересное - что даже бы и полез посмоте

.. была "ПУСТОЙ". А самое интересное - как она такой получилась...
.
Тотального аудита файловой системы на сервере - не ведется. Компания небольшая, необходимости в тотальном аудировании и контроле кто что сделал и зачем и в какое время - нет.
.
Теперь самый интересный вопрос: как получилось так, что работая весь день монопольно и сделав все что надо, по факту выхода из программы исохранения - получили "пустой" бэкап...?
.
Рассмотрение возможных вариантов с выборочной подчисткой базы и поиск следов таких подчисток - ответ отрицательный. Конечно возможно, что базу подчистили "в сторонке" и подсунули н аместо рабочей базы - попахивает крайной степенью паранойи даже для меня - убежденного параноика. Квалификация людей, которым возможен доступ к базе длятаких действий - явно недостаточна, причем недостаточна сильно. так что варианты преднамеренного вмешательства - ответ отрицательный.
.
Никаких автономных файлов и откатов системы и автообновлений и автосозданий контрольных точек нет.
.
Все 1Ски на фирме запускаются из одного единственного места из одного экзешника.
.
Рассмотрение возможных мест/времени возникновения проблемы привело к обнаружению конкретного момента времени когда, скорее всего и была запущена "проблема", которая привела к потере данных. было что-то похожее типа такого?
.
- расчетчик в терминалке работает с базой монопольно. Программа/база используются штатно. Выполянются работы по созданию и проведнению/перепроведению документов в ЗиК расчету ЗП и прочего сопутсвующего что обычно делает расчетчик в ЗиК
- по всем доступным логам единственные попытки коннекта к базе зафиксированы у единтственного второго пользователя, который запускал 1Ску не терминально, а локально;
- ярлык для локального запуска висит как "запасной" вариант на рабочем столе всех пользователей - ими вообщем никогда не пользуются. (система стабильно работает в терминале более 2.5 лет, а до этого еще четыре года на стром сервере). Изредка кто-нить в запале может локально запустить 1Ску - она спокойно работает, но все шевелится не сильно быстро - обычно этим страдает бухгалтерия... и выявляется это когда начинаю жаловаться что-то типа сегодня 1ска медленно шевелится, оборотки медленно строятя);
- Совместное работа с базой и в терминальном режиме и локально через шару (база подцеплена в стартере пр расшаренному сетевому ресурсу типа \\server\bases1C\..) - насколько я знаю (ошибасюь или нет?) тоже вроде является штатным использованием...
- так вот: расчетчик монопольно работает с базой в терминале; второй юзер подключается к базе через шару - получает предупреждение о невозмоности входа в базу, пытается повторно - без успеха, пока наконец не выясняет что база эксплуатируется Расчетчиком монопольно и попытки подключения в базу прекращаются; при этом по логам видно, что подключение  в базу второго пользователя по времени очень близко совпадает с созданием Расчетчиком нового документа (с точностью до нескольих секунд) - и именно начиная с этого нового документа - впоследствии оказались потерянными все новые введенные документы...
- вдобавок эти же маркировки времени, соответвующие попыткам подключения в базу и времени создания первого "исчезнувшего" документа, стоят и на совокупности сиситемных таблиц и таблицам одного документа - см. http://screencast.com/t/FUGoDFosM - таблицы с маркером 16:43
- похоже что в этот момент возник какой-то клинч между дейсвиями мнонопольного Расчетчика по созданию и записи новых документов(документа) с попытками подключится к базе через шару вторым юзверем с получением сообщеняи о блокировке базы (как долго висело предупреждение и сколько раз запускалось подклбчение с сообщенями о боикровке - выяснить достоверно не удаетяс возможным - но то что не менее раза - 100%, а со слов юзера - раза два-три).
- и где-то внутрях 1ски что-то "заклинило" - то ли осталась типа незакрытой взведенная неявная транзакция (то ли еще что-то) - в рамках этой "транзакции" расчетчик успешно работал три с половиной часа, успешно все сделал - ВЫШЕЛ ИЗ БАЗЫ - незакрытая транзакция ОТКАТИЛАСЬ, все похерилось. И база , откатившаяся неявно для пользователя до состояния  мину 3 часа назад была успешно забэкаплена.
.
вот такой вот мой диагноз как неспециалиста в тонких вопросах.
в вскр буду смотреть еще попристальнее на логи, маркеры - но, как-то вот так...

Транзакция тут не при чём.
Скорей всего, неправильная работа сети.
В момент подключения система открывает файлы по сети - обнаруживает, что они недоступны (заблокированы), но при этом пытается создать копию файлов на локальной машине - режим автономных файлов с разделённым доступом.
Конечно, при запуске 1С понимает, что она не может открыть базу по таблице блокировок, которые система автономных файлов игнорировать не может - 1С закрывается с ошибкой, но при входе она открывала файлы и "обновила" их.
После закрытия 1С система обработки файлов пытается их восстановить на сервере, но сделать она это сможет только тогда, когда из базы выйдет терминальный пользователь - что и произошло.
К сожалению, так бывает - в экспериментах по сети я видел сообщение системы о восстановлении автономных файлов, после чего базе было не совсем хорошо (тестовая база "развалилась" по файлам - одни от одного момента времени, а другие - от другого).
После этого всегда в групповой политике специально отключают все возможности работы с автономными файлами - при этом и работа с фалами идёт без локальной копии - при отказе сети шара падает безвозвратно.
P.S. если базу гоняют в терминале, то локально к ней доступа быть не должно. Если он нужен, то и в терминале должны заходить через сеть (\\ИмяКомпьютера\ИмяШары), тогда ве будут в одинаковых условиях, и отказы будут менее вероятны.

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

(77) спсасибо, будем исследовать. Но у админа специально уточнял - нет у пользователей возможности работать с автономными файлами. Однако, направлю еще раз его по описанию (77).
> могут быть сохранены в служебных директориях сервера.
- а хоть примерно это где?

(77) такой вариант мне, конечно, кажется более похожим на правду, но как теперь установить имел ли такой факт место...

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

(81) Насколько я помню, работа с автономными файлами никак не связана со сменой пользователей.
Быстрая смена пользователей может влиять только на сетевой доступ.

Посмотрел ссылки:
http://technet.microsoft.com/ru-ru/magazine/2007.11.offline.aspx
Там сказано, что система предлагает выполнить синхронизацию вручную.

Вопрос - насколько время на клиенте синхронизировано со временем на сервере ?

То есть, на самом деле, ситуация могла бы иметь место, если бы пользователь ещё раз произвёл подключение по сети, чтобы файлы восстановились.
Другое дело, что если происходит удаление файла, то файл остаётся на диске, пока он открыт из 1С, так как она с ним работает - вопрос в том, что будет, если создать второй файл с таким же именем.
Мне кажется, что есть вероятность того, что сетевая система удалила файлы и создала их заново согласно копиям (которые от 16:43) потом 1С продолжила работать с удалёнными из папки файлами (при работе монопольно они все открыты, пока открыта 1С). И файлы умерли сразу после выхода пользователя.
Очень похоже на правду, только если это так, то сбоев должно быть больше.

(83) >  ситуация могла бы иметь место, если бы пользователь ещё раз произвёл подключение по сети, чтобы файлы восстановились.
- в смысле? локальный пользователь повторно попытался подключится - какие файлы восстановились? не понял, поясни чуть более подробно.

и нет работы с автономными файлами у пользователя...

(84) Просто, если рассматривать откат транзакции, как говорил (64), то время файлов было бы правильное, то есть последняя запись в файл была бы на момент отмены транзакции, и хотя бы 1susers, где фиксируются открытия и закрытия объектов.
Если этого нет, то 1С точно не при чём, так как она может восстановить содержимое файлов после отката транзакции, но не может восстановить время последней записи в файлы.
Работа же автономных файлов на такое способна, но, для этого нужно, чтобы подключение на какой-то момент разорвалось.
Также интересно посмотреть, а вообще какие-то изменения в системе за этот момент были ?

ну если отмена транзакции - то никакой записи в файлы нет как раз. а в 1susers - я сомневаюсь что фиксируются открытия и закрытия ОБЪЕКТОВ.

(86) не было изменений в системе в это время. логи чистые. буду юзеров еще дополнительно трясти.

По журналу регистрации поясните

(86) задайся вопросом - где находятся данные множества объектов из раных таблиц если открыта длительная транзакция. и откуда получают ЧИТАЯ данные  об этих объектах другие пользователи...?

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

Если в групповых политиках пользователя есть перенаправление папок ( Folder redirection, см. http://support.microsoft.com/kb/232692 ), то "по умолчанию Windows XP Professional делает любую переадресованную папку доступной в автономном режиме". так, на всякий случай...

доп.: про групповые политики в смысле автономных файлов и связанных - вот тут вроде неплохо нарисовано - http://helpwinxp.narod.ru/helpwinxp-12.html
(таблица 12.1 и около, например)

(90) Понятно, что данные транзакции хранятся в памяти, так как в файл их записать нельзя, а вот счётчик открытых форм в 1susers должен работать вне зависимости от транзакции, и у него время должно поменяться.
Просто, если делали сохранение, то в сохранённой версии можно посмотреть время dbf-файлов - все ли они замерли на той отметке.

Что касается транзакции:

   НачатьТранзакцию();
   ОткрытьФормуМодально("Документ.УшиМёртвогоОсла");
   ОтменитьТранзакцию();

Такая конструкция позволяет создать и провести документ в транзакции причём интерактивно.
Сейчас проверю, чтобы менялись файлы.

В общем, 1susers изменяется при закрытии 1С, если делали сохранение из конфигуратора, то закрывали - время должно было измениться.
Остальные dbf-файлы в транзакции - не меняются.

Получается, что на транзакцию тоже похоже.
К сожалению, время последнего доступа к файлу фиксируется в момент выхода из 1С, так как для открытых файлов оно почему-то не обновляется (по крайней мере на XP).

(0) интересный отчетик есть ЧтоКтоКогда.. я уж забыл, кто писал его.
http://yadi.sk/d/gEP4UO5_3qBag
забери, а вдруг как-нибудь поможет

Пропадают данные 1С 7.7 DBF XP

дая тут ща с ходжиком кучу экспериментов аналогичных проводим

Злопчинский - так ведь у всех файлов кроме 1Cjourn дата 4 апреля, а у 1Cjourn - дата 5 апреля. Как такое может быть???

это уже последствия копания 5 апреля. в ночной копии все обычно.

Если откинуть идею "транзакции" и учесть что автономные файлы не работают - какие внешние причины могли привести к подмене файлов после освобождения этих файлов из монопольки..?