История данных в 8.3.11 #810056

У кого то получилось включить? все последнее, на объектах включил вести историю, но история пустая. что еще потыкать?

я не пробовал, как то это упустил... Вот спрашивается, ну на..., за каким х... это надо, по сути объект становится периодическим, потому как (МенеджерИсторииДанных)  и соответственно методы.... базы и без того пухнут, а тут еще и эти фокусы )

Включал, работает.

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

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

Так оно меньше места занимать будет, чем подсистема версионирования из БСП

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

У меня все работает

У меня один вопрос. А не получится ли так же как и регистрацией изменений для планов обмена? Так же как и регистрация "История данных хранится в специальных таблицах той же информационной базы, для которой настраивается версионирование." При этом таблица регистрации одна общая без возможности наложить управляемые блокировки. И любые изменения в этой таблице сводят на нет всю параллельность работы. Т.е. если раньше мы могли распаралить работу, например по организации или по складу. То теперь при включении регистрации изменения блокирует всю таблицу целиком. Уже не получим ли мы с этой версионностью теже грабли?

А кто сказал, что эта таблица блокируется?

Ты про таблицу регистрации?  Мой опыт. Прикручивал я в БП риб. и когда таблица изменений пухнет (а она пухнет в любом случае когда параллельно по 10 организациям начинаю закрывать период и проводить документы за 3-4 месяца перед сдачей отчетов) начинаются ошибки блокировки при параллельной работе (т.е. перепроводка по одной организации вызывает транзакции в другой организации). Запускаешь обмен - полная транзакция по всем организациям. Прогоняешь обмен - все летает, до тех пор пока в таблице регистрации не наберется критическая масса. Пришлось отказаться от риба, после этого всё опять началось параллельно проводиться и никто друг другу не мешает. Или ты про таблицу где хранится история? Так это я и пытаюсь понять. Если в одну единственную таблицу будут параллельно писать 20 юзверей что будет? Какие блокировки накладывает 1С при записи/чтения? Почему в таблице регистрации 1с не смогла в параллельность записи, а в таблице истории можно писать параллельно? Разные студенты писали этот механизм, поэтому разное поведение?

Зачем в БП РИБ вообще нужен? Таблица изменений документа не лочит таблицу регистров, если ты не студент и не перепроверишь документы через ПолучитьОбьект. Простое перепроведение документа никак не повлияет на таблицу изменений. А вот если обработка что-то меняет в документе - другой вопрос. Тогда нужно делать отдельно запись документа и отдельно запись движений. И всегда можно через правила регистрации тупо не писать в узлы обмена.

Расскажи это писателем типовых. Я говорю исключительно про типовую БП 3.0 И да мне РИБ был нужен к примеру чтобы получить консолидированную базу, когда у филиалов свои юрлица и база находится у них на сервере. И нужна общая база со всеми данными. А по поводу таблицы изменений, я не знаю какие студенты пишут типовые, но я вижу результат их работы. И я не говорил что "Таблица изменений документа не лочит таблицу регистров", я как раз говорил обратное. Когда платформа пишет данные в таблицу изменений то в этот момент лочиться вся таблица изменений. И если на регистр я могу наложить управляемую блокировку и организовать параллельную работу, то таблица изменений одна общая и не управляемая. Т.е. если Вася пишет в регистр и платформа регистрирует эти данные в таблице изменений, то Петя может писать в этот же регистр, но не может писать в таблицу изменений. Тут платформа говорит "ожидание блокировки при выполнении транзакции" и Петя грустный идёт домой. Соответсвенно и возник вопрос, 1С переработали этот механизм или тупо скопипастили с таблицы изменений т.е. при параллельной работе и включеной версионности я увижу туже надпись про блокировки. И что значит "Простое перепроведение документа никак не повлияет на таблицу изменений." - ты сейчас про РИБ говоришь или про таблицу версий? Перепроведение должно зарегестрировать документы и движения для РИБа. И по поводу того что нужно делать, это не мне пиши, а разработчикам типовых. Это у них все через одно место написано (был как то опыт, когда типовая тормозила при проведении/пометки удаления документов. Гилев посмотрел на то что в это время твориться на скуле и сказал - а что ты хочешь это типовая, по хорошему тут надо всё переписывать, чтобы работало)

Славик свалил изо всех контактов уже как больше года. Таблицу версий не смотрел - делал сам во время "контракта" с Гилевым. В РИБ всегда писались  GUID тупо объекта, без ссылок, при групповом проведении они тупо писались, при выгрузке они ничего не блокировали - так как писались в привелигированном режиме  в режиме nolock. Если транзакцию ничего не блокировало в обычных таблицах - правила регистрации отрабатывали нормально. Когда их не было. А вот когда их ввели  - тогда начались проблемы. >>Перепроведение должно зарегестрировать документы и движения для РИБа. И по поводу того что нужно делать, это не мне пиши, а разработчикам типовых. А у тебя точно типовая? В 8.1 помню зависающие движения, в 8.2 не помню.  Все косяки на текущий момент связаны с кривыми настройками ИМХО. У меня сейчас кластер на 18 баз. От 10 до 300+ гигов. Все работает без проблем. Сколько баз во фрэше - хз, и тоже без проблем. Главное держать кэш в чистоте.

Так я и не говорю что он вчера смотрел Я пользователей типовых, а не писатель нетленок. Беру типовую, настраиваю по книжке - вижу результат. В частности когда запускался типовой обмен УРИБ по организациям, то в это время никто ничего делать не мог (что логично так как шла активная запись в таблицу изменений). БП 2.0 там в принципе нельзя было сделать общую базу так как ИП и комиссия блокировала всю база (т.е. если ИП-ник или комиссионер перепроводил базу, все остальные организации курили в сторонке) В 3.0 уже это все хозяйство жило в одной базе, но при этом раз в 3 месяца тупо умирала и одна организация начинала "мешать" работать другой, пока обмены не прогонишь (т.е. пока таблица изменений забита данными). Может быть к декабрю 2017 года что то и поменялось, так как я забил давно на УРИБ и пересадил всех в одну базу, в том числе и филиалы. Благо на сегодняшний день интернет позволяет это делать. А с чего ты взял что во фреше нет проблем? Ну во первых если мы говорим о 1cfresh то там не используется таблица изменений, так как по умолчанию риб отключен. Во вторых там используется деление по областям (т.е. отдельная колонка в таблице). Да и к тому же там нет такой интенсивной работы, чтобы 10 бухгалтеров в одной области параллельно проводили 50 тысяч документов

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