Доброго времени суток

Сто лет не заходил на форум, а тут решил совета спросить.

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

Вариантов "где фиксировать" не так много :

штатный ЖР трогать нехочется по религиозным соображениям
регистры требуют документов
справочники - пухнет база

остаются внешние хранилища. Вариантов тоже не много :

1. внешний файл
2. "левая" таблица в скуле

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

2. ниразу не видел и не сталкивался. Даже не представляю как...

в общем нужны советы.

смотрел dll от ромикса - похоже но опять же типа внешнего ЖР. оставил на крайний вариант

Вот теперь вроде всё изложил. Весь в внимании....

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

(2) ну +/-
(3) нет, машину хочу обновить ;)

(4) скуль скуль

давайте ещё подождём по первому варианту. Нет - буду пытать по второму ;)

(4) ну, путей несколько, в зависимости от того, что в лог будешь пихать. Т.е что именно нужно отслеживать.

(8) ну а как ты думаешь? всё стандартно. "кто, что когда" и "какого чаи гоняем по часу в час пик" ;)

:) все ясно...Д. знает скуль хуже внешних файлов

(10) скуль только на уровне запросов. Этого мало? ну что есть

(11) INSERT - это тоже запрос :-)

(12) так ладно. есть ещё желающие покрасоваться несомненно бесконечными знаниями по SQL? Если нет - предлагаю перейти к конкретике. А если ещё примеры будут - вообще супер

:) тезка, тебе как бы намекают что разделенный доступ к внешнему файлу это гораздо менее надежно чем сикул-таблица

(14) это я уже понял. Суть выбора проста и описана в топике - работа со скулем кроме как написание запросов в 1С++ для меня "ниразу не видел и не сталкивался. Даже не представляю как..."

если распределённый доступ к внешнему файлу организовать сложно и нереально (в понятиях доступных мне) то буду копать в сторону скуля. Вот сейчас пытаюсь рыть в инете примеры или хотя бы описание

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

на счет одного файла.. есть поделка готовая на проклабе, с помощью filler.dll пишет в файлик

Создать свой Журнала Регистрации mlg для обмена
проблем с "одновременной" записью нет

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

правда запись таки кешируется немного - в ТЗ и раз в 30 сек скидывается в файл лога

проблемы с записью отсутствуют из-за объекта "Scripting.FileSystemObject"? если да - то все остальные вопросы отпадают сами собой. с этим объектов я давно и плотно работаю разбирая логи внешней программы размерами по десятки мегабайт.

справочник.
с регламентной архивацией ( выгрузкой во внешний(-е?) dbf-файл(-ы?) + зачисткой выгруженного ).
с отдельной обработкой формирования каких нужно отчетов/выборок за какой нужно период - с использованием архивов.

(22) думал и так. период архивации месяц (больше и не надо). Вроде всё красиво - и тебе запросы и выборки и отборы с сортировками. Но смущает именно то что надо его чистить будет периодически или же держать долго.

В чём встала проблема. Крупный клиент - дистриб областного уровня по порядка 7-8 крупным торговым маркам мирового масштаба (пиво, мин.воды, нестле, марс и т.п.)

раз в квартал идёт тотальная сверка с вендорами на предмет правильности остатков на любой момент из квартала (они у себя там закрывают период). Малейшее расхождение и санкции. От объяснительной до лешения скидки и прочих радостей. крутится 8 баз. В среднем в день в каждой лупится порядка 1000 документов. Но кроме этого есть ещё умники "из бухалтерии и транспортного цеха" которые теоретически (оказывается и практически) что то изменить в старых документах. И Изменить не сейчас а например три месяца назад. А всплывает то сейчас. Я понимаю что можно достать данные из внешнего лога за тот период и прочитать их. Но как то некошерно что ли... смущаюсь ;)

если в текущий справочник религия не позволяет да и зачем тебе лишние транзакции в базе, пиши во внешнюю скл базу. Любой компонентой которая это может делать. Транзакции обрабатывай сам. В принципе можно для каждого юзера отдельную табличку заводить.

1. скуль (я бы сделал именно так)
2. запись в куда-то через ADO, используя те же запросы. Типа, развернуть какой-нибудь mysql, или сделать файлик аксесса.

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

+ (25) вот только я бы сделал отдельную базу для регистрации, а не таблицу в рабочей базе.

все видимо зациклились на субд)

(27) да отдельной проще

(23): никаких проблем. архивы - полные, выполняются хоть ежедневно (по ночам), причем чем чаще - тем быстрее выполняться будет.
ну и какие проблемы трехмечячной давности лог из архива поднять-то??? в дбф-архивах для этого ещё ништяковые индексы слепить... да хоть за десять лет назад!

(28) ну можно в файлик на диске текстовый. теоретически. но это не готично и проблема с разделением доступа к нему

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

(27) ну в общем то я так и думал. Курочить боевую базу размером в 20 гигов я не рискну ;)

(30) дата то когда полезли неизвестна. значит надо будет развернуть все за период, слепить до кучи и уже в ТЗ анализировать и искать

(31) тут чел в 18 заявил что с распределённой записью нет проблем. я предположил что из-за объекта "не 1С-ного". вот жду ответа

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

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

(33) 3. файлик при желании может прибить любой юзер. с скл базой это гораздо сложнее. Да еще не забудь, что писать в файл - это не самоцель. тебе еще анализировать надо данные. Представь скорость работы с файлом

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

(36) не прибьёт - нет доступа к папкам - всё в терминале крутится. А что касается анализа - то объект "Scripting.FileSystemObject" очень здорово и быстро обрабатывает большие текстовые файлы. Проверено (см 21)

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

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

(38) они не будут такими большими ... см(35) просто выбрал нужный диапазон и слепил отчет

(39) представь себе простейший запрос, например - все записи касающиеся объекта Х. И примени его к гигабайтному текстовому файлу.

(40) почему все считают что сиквел ту же сортировку сделает быстрее?

(42) ой вей. я понимаю тягу "старичков" к гигантомании но не настолько же ;)

максимум по одной базе за месяц метров до 100 не больше

(43) не скажи. если будет писаться в таблицу скуля (как я понимаю по малому знанию своему) то записи идут в режиме реального времени а значит изначально будут уже упорядочены по времени и сортировки не потребуют

(+45) или же в общий текстовый файл

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

(44) а если писать не только измененный объект (что банально и неинтересно), но и какие именно реквизиты при этом изменились - объем выростет и очень быстро.

никто тебе самому не мешает постобработку сделать и просто строить тот же индекс

(48) а в сиквеле он не вырастет?

(48) это смотря как писать
(47) можно про "индекс по текстовым файлам" подробнее

(50) отбор в большой сиквельной таблице по индексированным полям будет выполняться гораздо быстрее, чем в текстовом файле. Особенно это касается больших объемов данных.
Кто бы что ни говорил.

у меня лог изменений данных пользователями на sql в отдельной базе

(51) имя файла и строка, и строишь его как тебе будет нужно

(0)SQLServer. просто сделать (ADO). надежно. данные всегда готовы для обработки. и не надо ничего склеивать.

сейчас объем базы 67 гб за 3 года

Попробуем перевести беседу в более рациональное русло нежели война "тупоконечников" и "остроконечников". Если с записью в текст/dbf/mxl всё ясно и понятно мне, то если у кого есть - можно пример работы с внешней БД на скуле. Я так понимаю там будет две таблицы

1. таблица с ID объектов базы и их представлениях на момент первой записи (для того чтобы не терять объект при изменении  номера документа или даты)

2. таблица с фиксацией изменений типа

ID объекта|реквизит|было|стало|

читать из этой ТЗ я думаю смогу. Писать - попробую. Но всегда легче когда есть букварь или работа "соседа по парте" куда можно заглянуть

(57) ид объекта не меняется

(53) вооо пошла конкретика. Можешь по шагам расписать что и как делать (код отслеживания не нужен). Достаточно примера типа "есть ТЗ с изменёнными реквизитами и объектами, которым эти реквизиты принадлежат. Теперь пишем эту ТЗ в таблицу скуля так....."

не зависит ни от номера ни от даты, вытащить его можно из значениевстрокувнутр

(58) а то я не знаю. Именно поэтому мне и надо первая таблица чтобы по ней определить изначальное представление объекта а не текущее.

(60) я знаю!!!!!

я понял

(57) у меня была обработка по работе с аксессовским файлом тут http://1c.proclub.ru/modules/mydownloads/personal.php?cid=83&lid=2347
работа со скулем отличается разве что строкой подключения

(64) акцесс при записи не блокирует монопольно файл?

а, сорри, просто как пример

(66) да, там просто есть запись запросами в таблицу через подключение по ADO

(67) сенькс. Правильно ли я понимаю что вопрос "блокировки" скуль решит сам? я про одновременную (теоритически) запись со стороны двух юзеров

+ (64) простой совет как собрать строку подключения самому:
- создаешь пустой текстовый файл с расширением udl
- открываешь его двойным кликом и настраиваешь параметры подключения
- сохраняешь и открываешь получившийся файл текстовым редактором

(53) у меня для >=8.1, через подписки

структура основной таблицы tablelog:
uuid объекта, дата изменения, компьютер, пользователь, объект метаданных, старое значение, новое значение,режим изменения, доп. поля

(69) спасибо.
(70) ясно.

(68) да, такой проблемы вообще не должно быть даже для 20 пользователей

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

(73) ну нечто подобное и мне заказали

в принципе для тупого insert table ... values блокировок не наблюдается - 60 юзеров, ADODB

(75) а откуда они там?

(76) а разве транзакции кто то отменил? или я не понимаю процесса записи в таблицы скуля?

(77) у тебя инсерт - это атомарная операция, там не нужна транзакция, и если у тебя на таблице не висит миллион индексов, то ты не должен столкнуться с проблемой при последовательной записи в таблицу

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

(77) Кстати, насчет транзакций. Именно для логов это иногда зло. Например, в модуле проведения хотим чего-то в лог писануть, чтобы оно там осталось независимо от результата, а транзакция берёт, и откатывается. Получается облом.
Мы выкрутились, используя другое соединение, которое toy-гибкиеблокировки создаёт.

(80) писаться будет 100 % ПриЗаписи()

(81) да я понял, просто на будущее

А начать рекомендую с установки SQL developer edition, естественно с Management Studio и MSDN, локально на своём компе. Там для начала читать мануалы, и экспериментировать. А то вслепую работать это как-то не гуд.
Для начала почитать про CREATE TABLE, INSERT, ну и GetDate() по любому пригодится.

Ладно. всем спасибо. буду копать...

(82) почему не экспресс?

(84) это уже не важно, можно и экспресс
главное что легально и бесплатно

(80) А что мешает писать в лог и успешность завершения транзакции - тогда будет ещё и известно что делали, а не только что сделали.

(86) когда в SQL говоришь ROLLBACK TRANSACTION, то откатывается всё, в том числе все твои записи в лог

(0) вот примеры по SQL логу:
http://infostart.ru/public/21874/
http://infostart.ru/public/151268/

(87) Откатывается, только если ты в ту же самую SQL-базу пишешь. Кроме того, возможны сильные тормоза при "пересечении" записи логов.
И, самое главное, лог то есть журнал предполагает, что в него только пишется и откатить что-то назад - это нонсенс.

P.S. Просто не стоит путать понятие "журнал" и "дополнительная расшифровка операций".

(89) Да ну? Ну на, проверь

use LogDB
create table log (col1 int)
go

use WorkDB

begin tran
insert LogDB..log (col1) values (1)
rollback tran

select * from LogDB..log


Сколько строк в выборке?

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

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

(92) Свою таблицу на каждого пользователя - это неправильно, так как число пользователей может быть неизвестно на момент создания программы.
Можно разделить таблицы по типам записей, чтобы гарантированно не было пересечения и проще было строить выборки.

(92) единственная мысль во всем посте, с которой можно согласиться - это "вот такая бредовая мысль..."...
(93)+1. добавлю - "не надо плодить сущности сверх необходимого..."

(94) CREATE TABLE никто не отменял при заведении нового юзера
про сущности согласен
но это лог и он обычно растет довольно быстро и когда-то все равно его нужно резать
а здесь безболезненно все уже порезано практически без потери производительности и по мере не надобности можно просто drop'ать таблицы
только запросы чуть сложнее собирать.
т.е. если исходить из сущностей, то сущность конечно одна - лог, но обстоятельства бывают разные

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

И после того, как разделили на сеансы снова возникает вопрос - а не проще ли в файл - писать-то будет один процесс - и только в конец.

(97) :-) тоже имеет право на существование

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

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

(101) :-))
Блат. либо наглость.

просил пример - http://infostart.ru/public/16687/

для 7.7, причем даже с транзакциями