Вот, вдруг понадобилось для одного документа фиксировать все действия оператора, естественно записанные в базу.
Как думаете, что лучше с точки зения скорости записи лога, ТХТ-файл или документ "ЛогДействий"?
База - самописка, маленькая,  документ "ЛогДействий" - один в день.

Лучше всего - запись в mssql )

(0) файловый поток конечно быстрее

(1) база файловая
(2) txt?

+(3) п.2 че ругаешься?  :)

(3) я за .txt хотя можно и .log

(0) имхо, в РС лучше
можно сделать периодическим, удобно искать инфу по дате в логах. можно даже запросами

(5) понял
у документа "ЛогДействий" есть небольшое преимущество, его несанкционировано труднее удалить будет

(6) как-бы клюшки

(8) прошу прощения, неуглядел

(9) да ну, не за что :)

лучше всего камеры со всех сторон... и пару надзирателей не забыть...

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

(12) на справочниках - громозко получится, ибо хранить надо примерно :  
Пользователь, Сотрудник, Дата, Время, Сканнер/РучнойВврод

(13) в смысле громоздко? Справочник с пятью реквизитами: Пользователь, Сотрудник, Дата, Время, Сканнер/РучнойВвод.

(14) в смысле за день таких записей может быть штук 10 на каждого сотрудника, один док на 1000 строк мне представляется более логичным

(15) извините а какая разница? много доков с шапкой без таблица или мало но с длинными таблицами?

и еще учтите... в курсе какое ограничение в 7.7 на кол-во строк в доке максимум?

(15) ну если тебя не пугают транзакции при каждом проведении этого документа, то можно делать и документами

Подбор в документ (и сканирование) - операции не блокирующие запись в базу, а вот запись документа - блокирует запись другим. Я бы очень удивился, если мне, как пользователю будет timeout на запись при сканировании, потому что мое "сканирование" нельзя в лог записать. Я бы во внешнее файло писал. Имя файла = документ+дата. проще будет ненужную историю удалять/архивировать.

(16) один док, на мой взляд, - удобней,  про ограничение "в курсе" :)
(17) проведения не будет
(18) аргумент, правда постоянно с базой работает один оператор, редко - пара руководителей
зы: база УчетРабоВремени :)

(19) тогда чтобы не пухла база делать банальные дампы сразу после изменения, измененных объектов в файлы целиком с реквизитами (13)(14)

(20) не слишком-ли жестко для таой-то задачки?  :)
и это, повторюсь, база файловая

(19) > правда постоянно с базой работает один оператор
А потом "директор" скажет, что оператор "нинужен" - пусть рабы сами свой трафик счетают :)

(22) "работает один оператор" - в смысле комп работает, а он на него сморит... в основном на прогу с видеокамер  :)
а рабы и так сами "свой трафик счетают", при помощисканнера конечно

Рабы проштрихкодированы? Да у вас и так уже предел автоматизации :D Я бы лучше GPS маячки начал внедрять - вдруг побег :)

пиши в стороннюю базу sqllite, к примеру

fso=СоздатьОбъект("Scripting.FileSystemObject");
    Попытка
        вТекстСтрим=fso.OpenTextFile(вИмяФайлаЛога, 8, 1, 0); //Открываем файл в режиме "дозаписи"
    Исключение
        Возврат 0;
    КонецПопытки;
вТекстСтрим.Write(вСтрокаДатыВремени + "; " + вПользователь+ "; "+ вСтрокаЗаписи+ РазделительСтрок );

(18) Клюшки не пытаются подождать освобождения блокировки??

(27) Так то пытаются конечно... но плохо :)

Что значит "плохо"?) Там же простая перезапись документа, которая и десятой части секунды занять не должна..

(25) Да ну, это уже перебор наверное. Да и знания по sqllite уменя мизерные :)
(26) скорость?
кста, насчет "блокировок", если писать в один файл с двух компов "одновременно" - как-бы похуже будет, а?

(30) Больше чем на скуле. Если локально. По сетке не сравнивал. Но если сетка дохлая лучше скуль.

(31) сетка стандартная, 100мбит,  колизий не замечал

(26) ну. можно и в файло.
Токма вот в базёнке все жешь и блокировки поставить и удалить/апдейтить..

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

(32) У меня был один пользователь, у которого были тормоза похоже из-за старой сетки.

(0) Документ? Как лог-файл?
Изврат, однозначно!

Либо файл, либо БД.

(0) Пиши в свободный Регистр сведений, хоть поиск потом будет проще реализовать.
А то в текстовые файлы считываются только первые 100 метров, потом теряют адекватность.
Писать каждый файл для каждого документа тоже не айс, если документо-оборот в день превышает 1 000 000, то будет познание в фееричной работе файловой системы и безконечная благодарность от Админов :)

А так, какая именно информация интересует Работодателя? :)

(0) "фиксировать все действия оператора" - тут видео с экрана нужно писать.

(36) документ конечно лишнее, а вот справочник самое то. пользуемся больше трех лет конфигурацией бизнес плюс:журнал изменений, который на справочнике сделан. дополнительный плюс, вся история хранится в отдельной базе, которую можно поместить на отдельный sql-сервер.

(0)Может так?:-)
http://www.ravepoint.narod.ru/aticles/tricks/methods/keephistory.htm

(39) аааа, блин.. 7ка

(41)точно...

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

(40) ",,В конце хочу добавить, что пользователя? который постоянно менял документы я с помощью этого монитора отловил в течении нескольких дней.  Уверяю вас, вывести его на чистую воду, схватить за руку и отвести к высокому начальству – было ни с чем не сравнимое удовольствие : -)"
.
- каждый автоматизатор в душе гестаповец ;-)

(0) Когда попал на подобную задачу - сначала запилил свой лог-журнал в внешней ИБ, используя полюбившуюся ВК sqllite. Количество записей было примерно ~200 в месяц. А потом потребовалось существенно расширить аналитику, я подумал-подумал, и сконвертил все это дело в справочник... Потом уже его читал той-же sqllite (насколько знаю - скорости это не прибавляет, просто удобнее).

Весьма странно использовать таб.часть документа для лога.
Т.к. при добавлении одной строки будут перезаписываться все строки таб.части.

(46) И более того, будет переписываться дбф-ка в составе базы.

(47) ну так и справочник - дбфка.
а вот что при перезаписи документа будет блокироваться (?) общий для всех юзверей журнал..?

Я думаю, что не стоит логи хранить в составе бд.
Хранить их нужно отдельно, но рядом с базой.

(49) Логи - нахрен не нужны для работы базы. На работоспособность это никак не влияет. Поэтому где хранить - пофиг. В самой базе (мерзопакостном снеговике где нет КаталогИБ) - хранить наверное не надо, чтоб чисто базу зря не раздыувать...

Посмотрел что у меня там в логах разных - 23 мена за сколькото лет по изменениям доков

(0) журнал регистрации уже предлагали?