Стандартный механизм 7-ки хранения журнала документов меня не совсем устраивает. Причин на то несколько:
1. Хранение всей информации по дате и времени документа в журнале
2. Отсутствие возможности эффективного отбора документов по критерию не являющимся колонкой таблицы журнала
3. Отсутствие возможности эффективного построения журнала документов по нескольким видам документов.

В связи с чем есть идея организации отдельной таблицы для хранения информации по данным документам. В принципе для DBF насколько понимаю можно использовать SQLite, для SQL собственно SQL Server.
Правда вот как это все организовать я пока не придумал.

Среди идей есть вот какие мысли:
1. Программист в среде 1С будет задавать список журналов для самостоятельной организации. После чего в модальном режиме необходимо будет провести сервиснуб обработку для заполнения журналов.
2. Перехватчиком организовать перехват событий записи, удаления и изменения документов после чего прописывать данные измерения в соответствующие таблицы.
3. Отображение организовать при помощи ТП и соответствующих поставщиков данных.

З.Ы. это просто идея родившаяся у меня от нех#р делать в момент 5-ти дневного проживания на природе. [s]Если у кого есть мысли, критика и т.п. я готов выслушать. Наработки если таковые имеются тоже не помешают.
Так же  мне нужна помощь по работе с SQLite базами, поскольку пока я ни разу их не трогал. Только для запросов.[/s]

Пускай все так и остается. 

План глобальный конечно. Собственно про хотелки я и говорю, но вот только мои "хотелки" завязаны на 1С-овских "телодвижениях".

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

В общем что мы знаем об 1С 7.7 при работе с документами?
1. Есть таблица journ - Журнал документов, где есть все документы и общая информация вроде реквизитов с признаком отбор, значения общих характеристик (пометка удаления, дата, номер, префикс и пр.)
2. Есть таблицы dh - таблицы реквизитов шапки документов и итоговых реквизитом Мн.ч. с признаком итог по колонке
3. Есть таблицы dt - таблицы реквизитов многострочной части...
4. Есть таблица crdoc - подчиненность документов + графы отборов

При организации поставщика данных для ТП можно пойти двумя путями:
1. journ + dh
2. crdoc + journ + dh
Хранения информации по графам отбора в crdoc меня вообще мало вставляет (хватит того что подчиненность там), а постоянно для получения даты, номера, пометки ползти в journ, а потом получать реквизиты из dh - тоже не самое приятное занятие, особенно когда речь идет о журнале документов с более чем 3-4 видами. А представляешь если еще и отбор по реквизитам шапки (т.е. coalesce(x,x,x)) ... в общем вот это мне и не нравится.

Идея в том что на sqlite организуется БД, которая по выбранным журналам считывает информацию из БД, сохраняет у себя структуру, реквизиты + создает таблицы указанных журналов скажем с полями date, time, iddoc, docno, dnprefix, + значения граф журнала. И есть КОП которые организует запись документов в эту базу данных.

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

Есть еще одна проблема - программные изменения документов. Которые перехватчиком не ловятся. Можно по разному морочить голову да что-нибудь изобретать, мне кажется самым простым и оптимальным вариантом будет просто создание кнопки "Обновить" в новом журнале. Вот в восьмерке журналы без автообновления - и ничо, привыкли.
Обновление доп таблицы одним запросом будет достаточно быстрым даже при десятках тысяч документов.

JohnyDeath писал(а) 27. Июля 2009 :: 06:10:


Поле verstamp отклоняю сразу, причину ты назвал правильную .
Сегодня вечером расскажу вариант реализации который пока зреет в моей голове.

vandalsvq писал(а) 25. Июля 2009 :: 17:08:

хм. а можно не в тему вставить свои пять копеек?
какая разница между тем, что в квоте и 1scrdoc? Вернее, в чем преимущество?
1scrdoc - штатная таблица, с вполне сносными индексами. В метаданных(конфигурации) можно прописать интересующие отборы, и 1С будет сама складывать туда все что нужно из dtXXX, dhXXX.
В табличном поле(великолепная штука для 1С) можно прописать отбор по нескольким графам. И не нужно никаких дополнительных баз данных, КОП, отлова событий изменения и прочих велосипедов. Это слишком сложно.

вот так, пошел дальше пить пиво