База DBF плюс штатный УРБД, VFPRO OLEDB. Прямые запросы для получения данных использую уже не первый год, проблем не возникало.
Рассматриваю возможность использования драйвера фокса для изменения реквизитов справочников и документов (без добавления новых строк в их таблицы).  

Выигрыш времени в тестовом варианте (база по сети, более одного подключения) составляет  от 3(когда идет добавление строки в  1SUPDTS) до 60 (когда строка уже есть) раз.

Не хотелось бы повторять известные ошибки (особенно на рабочей базе) и изобретать велосипед.

Вопросов много, вот некоторые:
1. есть ли положительный опыт прямой модификации данных, особенно интересен вариант в сочетании с УРБД.
2. если в полях, по которым строятся индексы не использовать кириллицу, будут ли правильно записываться инд. файлы.
3. будут ли правильно делить доступ на запись (как к dbf так и к cdx) фокс и 1с
4. т.к. УРБД. то нужно модифицировать и таблицу справочника/документа и 1SUPDTS, соответственно как обеспечить их совместную запись, т.е. если запись одного не состоялась, то и второй не записывать.
5. м.б. кто-то поделится рабочим куском кода модификации 1SUPDTS

п.с. Прошу прощения, получилось много слов …

А в чем основная сложность? В УРБД?
Если я правильно понял из других источников, фокс провайдер блокирует таблицу на время выполнения команд INSERT/UPDATE/DELETE, только непонятно как к этому отнесется 1С (хотя на "сервере", где лежат файлы базы, 1С может быть вообще не установлена и при этом разные копии 1С имеют доступ одновременно).

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

Нужно изменить индексируемые поля типа «дата» и «число» уже существующего справочника. При этом сохранить целостность данных и правильность индексов (насколько я понимаю, фокс это умеет).
Кроме того, нужно, чтобы при очередной сессии обмена данными (авто раз в 10 мин) элемент попал в файл обмена.

Реализуется вторая часть путем модификации таблицы 1SUPDTS: добавления элементарной строки (строк применительно к центральной ИБ, если несколько периферийных) или сброса в ‘      0’ поля DWNLDID в существующей строке.

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

Да, я это понимаю, но разве это замечание не относится к символам кириллицы?
Сейчас не могу найти, где-то уже обсуждалось, что при установке Collating Sequence=MACHINE отличие, насколько я помню, только в положении "ё".

В данном случае речь идет о модификации справочников не использующих в индексах поля содержащие кириллицу.

Betas писал(а) 05. Мая 2010 :: 17:19:

Сложность в том что и тебе и 1с для изменения надо блокировать и таблицу справочника и таблицу 1SUPDTS
Возможна ситуация ты блокируешь одну таблицу 1с другую получишь что-то типа "мертвой блокировки sql"
Может получиться что твои блокировки будут игнорироваться 1с и наоборот блокировки 1с будут твоим драйвером игнорироваться
получишь нарушение целостности данных.

Z1 писал(а) 06. Мая 2010 :: 04:45:


В этом справочнике нет отбора и не будет, мне достаточно для индексов сортировки. Также в нем нет наименования и кода, соответственно не будет "плохих" символов для индексирования.

Что касается понимания чужих блокировок 1С и фоксом (согласен один из ключевых вопросов) надеялся, что кто-то с этим сталкивался. Если нет (хотя странно, проблема ведь возникает и при отсутствии УРБД), попробую как то выяснить это экспериментально.

Если с блокировками все ОК, основная проблема будет - как обеспечить обязательность модификации 1SUPDTS. Хорошо бы транзакцию, но по большому счету достаточно просто гарантировать запись в 1SUPDTS. Допустим, как крайний вариант, отловить ошибку записи и и штатным Записать()...

Размер файла dbf примерно 2 Мб, количество записей тысяч 20.

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

Данные в описанной ситуации конечно будут не те, но синхронизация сохранится. А не те данные в распределенной базе (если не предусмотреть спец. мер, например делить документы на более мелкие документы и справочники) получаются и так не редко.

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

Запись в таб. справочника возможна только в загрузке обмена.
Вмешиваться в работу штатного механизма обмена пока не планирую.

Речь идет о модификации справочников и документов в сессии пользователя и в ЦБ и в ПБ.

Ну при проведении документа как минимум блокируются три таблицы
1sjourn  ra   rg

При смене даты вне периода должны пересчитаться  rg
c ПрежДаты  до ТA   -ra
c НовойДаты до ТА  +ra

Цитата:
как то очень загадочно.
Непонятно вы отказались от регистра и пользуетесь вместо него документом.

Приведи полную структуру регистра все поля и краткое его назначение.



Даже если Ваше ручное изменение и получиться в другие ПБ данные будут поступать через штатный механизм УРБД.

Опять же как же со скоростью если изменения этого регистра придут из другой ПБ.

Betas писал(а) 06. Мая 2010 :: 08:12:

Так зачем вам использовать вообще проведение. сделайте этот документ не имеет движений
ДатаДок это дата создания документа
РеквизитШапки  СвояДата - дата "РеальногоДвижения"
Если СвояДата - не задана то документ "Не проведен"
Выигаете у штатного механизма время на проведение перепроведение документа. Да но тогда придеться менять все отчеты.

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

На 16. Все бы хорошо, но "реквизитШапки  СвояДата" не будет иметь индекса, а это очень замедлит выборку. Можно конечно руками дописать 1Cv7.DD, но это нужно делать каждый раз и во всех базах.

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

Спасибо, но как это сделать?
Дополнительные индексы в 1sjourn строятся только по общим реквизитам вида "справочник", или я ошибаюсь?

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

Кстати, я неправ и CLOSED вообще не участвует в индексах, использую IDDOCDEF,DATE,TIME,IDDOC.
Получается выход такой: документ вообще не проводить, соответственно не нужно будет перепроводить при смене ДатаДок, выбору по прежнему делать по ДатаДок, а в качестве флага использовать реквизит шапки.

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

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

Betas писал(а) 06. Мая 2010 :: 09:21:

Оно тебе надо ...
Вроде все и так решается
сам же сказал
Цитата: