Заинтересовался схемой максимально быстрого перепроведения в 1с 7.7 dbf, переписал модули проведения на использование прямых запросов, теперь проведение одного документа задним числом происходит очень быстро, однако столкнулся со следующей проблемой: если перепроводится некоторая произвольная последовательность документов задним числом, то ее нельзя запускать в транзакции, так как прямые запросы не могут получить обновленные данные. Надо запускать либо со сдвигом ТА, тогда используются стандартные методы 1с (ВыгрузитьИтоги), которые на ТА работают быстрее чем запросы, либо без транзакции, что получается медленно.
Теоретически, есть вариант: перед проведением рассчитать остатки по всем регистрам для всей используемой номенклатуры на первый документ из последовательности, начать транзакцию и при успешном проведении документа дополнять эту общую таблицу новыми данными, образовавшимися в итоге проведения документа. Однако, как написать такой универсальный запрос получения остатков, и главное, как оптимально осуществлять поиск в данной таблице для каждого документа, плюс заполнять новыми данными так чтобы было быстро - тут для меня пока все представляется слишком сложным, т.к. программирование 1с я осваиваю самостоятельно для своих прикладных нужд. Просто интересно, развивал ли кто-нибудь подобную идею на практике?

Второй момент - использует ли кто-нибудь анализ движений документа в модуле проведения с целью узнать, а надо ли его вообще перепроводить. По идее, можно легко считать все существующие движения документа + измененные периодические реквизиты, после этого получить таблицу новых движений и новых значений реквизитов, и если расхождений нет - то не перепроводить все заново, а просто успешно завершить процедуру проведения. Это актуально для распределенных баз, так как при перепроведении в центре получается объемный массив, который рассылается всем дочерним базам (который и загружается при автообмене достаточно долго), а смысла в нем мало, так как реально нужно было перепровести лишь небольшую часть документов. Имеет ли право на существование подобный прием, или я просто что-то не так понимаю?

размер базы dbf озвучте,  интересно какой у неё размер

Злой Бобр писал(а) 01. Апреля 2009 :: 07:30:


если мелочь, то накой тогда там оптимизация ?

ведь есть всякие патчи dbeng32 снимающие ограничение на 1ГБ dbf или 2 ГБ уж не помню, так что в итоге база может быть 6-8 ГБ

Den@ писал(а) 30. Марта 2009 :: 12:02:


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


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

Z1 писал(а) 01. Апреля 2009 :: 08:46:

Эх..., если б все было так просто... . Такое можно сделать только отказавшись от партионного учета. Что само по себе бросает в дрожь бухов, а если сделать на практике - ошалеют вкрай.
Иногда можно, а иногда и нет. Так что каждый должен найти свою "золотую середину".

Z1 писал(а) 01. Апреля 2009 :: 09:18:

Общий размер файлов *.dbf
Z1 писал(а) 01. Апреля 2009 :: 09:18:

Никто.
Z1 писал(а) 01. Апреля 2009 :: 09:18:

Плюс размер остальных *.dbf

Спасибо, kiruha, за советы по оптимизации, посмотрев внимательно и разобравшись с таблицами смог сильно оптимизировать регистры.

Насчет сабжа, предпринял следующее...

По размеру базы, она у нас маленькая, совсем. 4 магазина розничной торговли, один год работы - 100тыс документов. Миграция для удобства настроена на все базы...

Свернув документы по нужным реквизитам, без потери данных, удалось сократить количество документов до 24тыс.

Далее, занялся оптимизацией проведения. Проблема с необходимостью перепроведения в том, что по одной группе товара номенклатура загружается из двух больших прайсов разных поставщиков, и при этом многие позиции дублируются, но с небольшими расхождениями в наименованиях, из за чего создаются дубли. Так как данная номенклатура - DVD-диски, то для правильного ассортимента дубли в обороте недопустимы... А бывает так что каждый дубль уже побывал в обороте, соответственно - замена значения + нарушение последовательности при этом.

Без оптимизации, стандартными средствами 1с, перепроведение 24тыс доков занимало минут 30-40. Но основная проблема не в этом, а в том что итоговая выгрузка содержала около 4 мегабайт и загружалась на компьютерах на местах до часа, плюс получение большого файла по небыстрому интернету.

В каждом модуле проведения вместо "ДвижениеПриходВыполнить" и записи в регистр поменял на "НоваяСтрока()" в глобальной таблице для данного регистра. После формирования всех таблиц отправлял их в функцию для проверки - изменились ли движения документа. Если не изменились, то ничего не делаем, в противном случае в цикле для каждой таблице записываем движения документа.

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

Таким образом, полное перепроведение начало занимать ровно 5 минут с затратами на 1 документ 0,01 секунды. В выгрузки попадают только изменившиеся документы, а их очень немного при замене дублей.

Жаль, что подобную схему 1с не реализовала на уровне движка...

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