Как программно зарегистрировать изменение объекта УРБД? #374097

Добрый день господа! Есть центральная база(ЦБ), есть периферийные базки(ПБ). Есть справочник, допустим "Контрагенты"(КА). Признак миграции - "Место создания и центр". Т.е. КА, заведенные в ЦБ, остаются в ней, КА, заведенные в периферийной базе, остаются там и мигрируются в ЦБ. Теперь вопрос - завел в ЦБ КА, хочу его насильно выгрузить в ПБ №5(например). Как это можно сделать ИЗ КОДА 1С? Вариант с ручной правкой 1supdts я знаю, но нужен вариант в коде 1С. Ведь 1С как-то сама делает это, мож есть какие-нибудь недокументированные функции?

никак

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

прямым запросом добавить запись в таблицу 1SUPDT (или как то так) с ID объекта

РегистрацияИзменений(<ВклВыкл>) Синтаксис:РегистрацияИзменений(<ВклВыкл>) Назначение: Включить / выключить режим регистрации изменений объекта Возвращаемое значение:  Функция возвращает установленный до ее вызова режим. Параметры: <ВклВыкл> - (Число)  Число 1 если изменения должны регистрироваться, 0 - если изменения не должны регистрироваться. Если параметр не указан, то режим не изменяется. Замечание: Особенностью вызова данного метода является то, что он действует с момента своего вызова и до перепозиционирования объекта. Т.е., его следует вызывать после того как объект выбран, и до записи изменений. После следующего позиционироваия объекта режим снова будет установлен в соответствие с режимомв метаданных.

это максимум

и какое отношение это имеет к вопросу автора?

брехня.

Можно и зайца научить курить. автору это не подходит.

+9 кроме того. в дальнейшем штатная перезапись данного элемента в ЦБ не повлечет его отправку в ПБ. И вообще не понятно, как система среагирует, если такой элемент перепишут в ПБ.

rs_trade, А если ЦБ на DBF? Доступ к 1supdts не получишь.... ДенисЧ Это в 7.7 такая функция? не могу найти в синтакс-помощнике...Где можно про нее почитать?

РегистрацияИзменений Синтаксис: РегистрацияИзменений(парам) Параметры:  Парам (число) 1 - регистрировать изменения, 0 - не регистрировать изменения. Если параметр не указан, то регистрация не изменяется. Назначение:  Включить или выключить регистрацию изменений для конкретного объекта. Замечание1  Особенность вызова данного метода - он действует с момента своего вызова и до перепозиционирования объекта. Его нужно вызывать после позизионирования объекта, но до записи изменений. После следующего позиционирования объекта режим снова будет установлен в соответствии с режимом, выбранном в метаданных (т.е. установленный для предыдущего позиционирования режим сбрасывается). Замечание2  Метод РегистрацияИзменений доступен только для объектов типа "Справочник" и "Документ", созданных функцией "СоздатьОбъект". Возврат: Число - 1 - да, регистрация производится. 0 - нет. Возвращается установленный до ее вызова режим. Пример:

1. да все можно, но см и последствия. 2. тебе это не поможет. Это всего лишь флаг при программной перезаписи для объекта регистрировать его изменения или нет

mishaPH все будет нормально:) я уже много раз выгружал объекты, созданные в ЦБ в ПБ(через правку 1supdts). ДА, после этого изменения в ПБ этого объекта не вернутся в ЦБ, но хоть что-то...

так мне надо РегистрацияИзменений, да притом еще указать в КАКУЮ базу выгрузить этот объект...

эх. ну жги дальше. только потом не жалуйтесь на глюки и нестыковку. когда у тебя манагер изменит в ЦБ ИНН или еще какой реквизит например сумму кредита. а в ЦБ об этом знать не будут. Такие примочки могут и не сработать по каким-то причинам.

Я тебе уже сказал, что это такое и тебе оно не поможет

Да никак, только правкой файлика...

Чем тебе способ в не подходит?

а тогда еще вопрос, из-за которого и возник собсвтенно этот... Дело в том, что в ПБ заводили КА нормально, но в какой-то период времени КА почему-то заводились без признака ИБ. Ну т.е. КА №1 имел ID "1005" (база 005), второй "2005" и т.д. А потом вдруг появляются КА с ID "3   ", "4   ", потом снова "5005", "6005" и т.п. Как будто 1С "забывает" дописывать в ID код базы-родителя. Кто с этим встречался? можно это исправить?

mishaPH мне нужен вариант с DBF

а с пустышками - поздно:) да и мне нужно довыгрузить СУЩЕСТВУЮЩИЙ объект, а не ноый

С таким не встречался глюком. Не может база забыть что она в УРБД. А что ты под ID понимаешь? Код элемента в справочнике? И что? создай таким образом новый, сдублируй со старого. замени в доках на новый заменой.

то куча сообщений, то тишина:) никто ничего не подскажет?:)

с УРБД вариантов не много. Штатных вообще единицы

mishaPH попробую вариант с пересозданием элемента справочника и его заменой в документах, делать нечего.. Просто надеялся, что найду в API 1C недокументированную функцию, которой собвственно и делается такая операция. Ведь в SQL-базе есть специальная процедура _1sp_RegisterUpdate, которая все это делает, я думал есть аналог в DBF...ведь 1С делает это действие(регистрацию изменений) вне зависимости от платформы..

нет к сожалению. 1с не стали развивать в 7ке штатные средства. Ибо 8ка нафиг уже не нужна была бы.

Слишком смелое заявление для человека, давно работающего с УРБД Так не бывает. Если только над базой не извращались. Хоть ДБФ, хоть сиквел - способ принудительной выгрузки туда, куда выгружаться не должно, только один - через доступ в таблицу 1supdts.

MikeWare Бывает, к сожалению...КА создавали вместе с документами. Так вот КА имеет ID"3   ", а тут же созданные документы по этому же КА - ID "25005"(с кодом ИБ). Насчет однозначности правки 1supdts - если база SQL, 1C создает себе процедуру _1sp_RegisterUpdate, с ее помощью можно выгрузить любой объект в любое время(имею ввиду работающий юзеров) в любую базу. Неужели в dbf-версии нет аналога?

в случае сиквельной версии 1с перекладывает задачу регистрации на сервер БД с помощью этой процедуры. а файловая 1с сама по себе является "сервером БД". Можешь, конечно, отловить вызов функции регистрации.... Только вот давно бы взял и сделал добавление записи. Спрашиваешь дольше...

1. Что не так? есть стандартный метод в коде 1с? или по..ть захотелось?

Написал бы - "штатно - никак" - вопросов бы не было...

где-то когда-то встречал обработку по работе с 1supdts для DBF но все это не штатно. да и тебе самому сделать не сложно. Добавить запись в него о выгрузке определенного элемента.

Ответ был на вопрос.

MikeWare "взял и сделал добавление записи." - имеешь ввиду 1updts? а как получить к ней доступ в DBF-версии? Она ж заблокирована для изменений, потому что ее открывает 1С...Или как-то можно?

Описанная тобой ситуация - не глюк. Объекты с ID "3   ", "4   " были созданы в БД ДО того как сделали распределенку.

АДО. примеры смотри на форуме 1с++ Анриал. Это периферийная база. она не может быть нераспределенной.

оба на. а как они туда попали? или ПБ когда-то была не цб? Вообще есть вариант, когда ЦБ была еще не распределенка, насоздавали там что-то. Затем сделали УРБД а у справочника миграция была "все". Но вот я не уверен, что в этом случае система действующим элементам не присвоит "префикс" ЦБ

не спорьте, объекты с ID "3   " и "4   " ТОЧНО БЫЛИ СОЗДАНЫ в ПБ. Проверено. Как доказательство - ведь объекты 1 и 2, 5 и 6 имеют префикс 005 и они находятся в одном числовом ряду (1,2,3,4,5,6).

это _НЕ_ доказательство...

+Вообще, кинь сюда записи сислога, где эти объекты записывались сызнова...

MikeWare да нет особого желания (и времени) разбираться почему они там так появились...Есть необходимость исправить:) Намекни пожста в двух словах, куда копать - в сторону доступа к DBF через АДО даже при открытой 1С или в сторону работы с АДО не открывая 1C? спасибо всем участвующим! "Ваше мнение очень важно для нас"(с) :)))

да "хоть боком, хоть раком". При закрытой 1с сделать быстрее, чем объяснять - объект xbase. а при открытой (в немонопольном режиме ) - через фокспрошный драйвер, за инфой - на форум/доку 1с++...