Транзакция при OLE-соединении с 1С 7.7 #262221

Есть код: [1C]

дык, эта... нету кода-то...

Есть код: Вопрос: почему в 1С 7.7 транзакция не активна, т.е. вся обработка идёт не в транзакции. Как при таком подключении правильно начать транзакцию?

Случайно нажал "Отправить"... :-)

Соединение1С77.Initialize(Соединение1С77.RMTrade, "/D""" + ИнформационнаяБаза.ПутьКИнформационнойБазе + """ /n" + Пользователь + " /p" + Пароль, "NO_SPLASH_SHOW")

Это ты к чему?

Как подключаться я знаю, подключение происходит нормально. Вопрос именно в транзакции.

изопенисуально эквифаллично однох#йственному

Очень информативное сообщение.

Коллеги! Неужели никто не знает?

где начать то транзакцию?.. в текущей, или в вызываемой?

ты вообще-то чего этим супер-кодом добиться-то хочешь?

(10, 11) Транзакция должна начинаться и в 1С 8, и в 1С 7.7. Т.е. в транзакции я переношу данные в 7.7, в транзакции они же должны фиксироваться, а в 1С 8 в транзакции фиксируется факт переноса данных. Если по каким-либо причинам произойдёт ошибка переноса, то должен произойти откат как в 1С 7.7, так и в 1С 8.

Так что, так никто и не знает? :-(

А зачем Соединение1С77.ExecuteBatch("НачатьТранзакцию");? Почему не Соединение1С77.BeginTransaction;

А разве у 1С 7.7 в режиме OLE Automation сервера есть такой метод?

Честно, не пробовал. А что выдает ошибку?

Ну, если ты имеешь ввиду Соединение1С77.НачатьТранзакцию, то да, такая конструкция не работает.

Кириллицей многое не работает.

Да кириллицей всё работает. Если мне не изменяет память, то вроде как ругалось на вызов процедуры как функции.

А как выглядела строка вызова. Полностью.

А вообще подозреваю, что разработчики могли не предусмотреть такой возможности.

Полностью строка вызова показана в начальном коде. Это было бы печально. Ещё бы знать это наверняка...

мне интересна строка "Соединение1С77.BeginTransaction;"

В таком случае не уверен что понял вопрос. Можно более развёрнутый вариант вопроса?

Мне интересна строка, на которую выдается ошибка. Я так понял, что это "Соединение1С77.BeginTransaction;"

Если действительно нужно полностью проконтролировать процесс загрузки, то можно перебрасывать через файл. Например, в 8.0 выгружаешь данные в файл и запускаешь 7.7 под определенным пользователем. В 7.7 прописано что, если база запущена от лица этого пользователя, то запускается обработка загрузки данных, после выполнения - завершение работы. В таком варианте проблем с транзакциями быть не должно. Если, честно, то всегда перебрасывал данные по OLE без использования транзакций и не имел при этом никаких проблем. Есть какая-то реальная необходимость использования данного механизма?

Да, изначально она так и выглядела. Сейчас проверил ещё раз, ошибку не выдаёт, но транзакция не отменяется при возникновении каких-либо ошибок.

OLE удобнее, нежели выгрузка/загрузка файла. Тем более файл будет достаточно большой, 1С 7.7 просто им подавится. А чтобы использовать предложенный вариант обмена нужно модифицировать конфигурацию 7.7. А я хочу этого избежать.

7.7 не подавится, а конфу переписывать, только если полностью автоматизировать. Если затавить пользователя дождаться выгрузки и запустить обработку по загрузке в 7.7, то ничего переписывать не нужно. А что за ошибки-то?

Предпологается что пользователь будет всё делать из одного места. Ему нужно только галками отметить переносимые документы, а всё остальное должна делать 1С. В других же вариантах слишком много лишних телодвижений. Собственно, всё уже работает, но пока без работающей транзакции. А ошибки могут быть любые: не хватает данных для переноса, некорректные данные, отсутствие соответствия объектов базы 7.7 и 8.1 и т.п. 1С ошибку то показывает, но транзакцию не откатывает.

А зачем откатывать. Не получилось выдал сообщение. А там либо остановился, либо дальше продолжил. Можно даже у пользователя спросить, типа "Abort, Ignore, Retry?". А так выдать полную информацию - пусть исправляет: довводит недостающую информацию, удаляет лишнюю и пр. Можно еще исключения прописать, что бы в простых случаях программа сама вносила изменения в данне...

Так ведь не все ошибки я могу отловить. Ладно это будет ошибка данных 8.1, а если ошибка происходит в подключенной базе 7.7? Достаточно проблематично отловить такую ошибку, определить её причины и соответствующим образом отреагировать.

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

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

Ну, тогда опять же . А потом, так ли сложно отловить ошибку подключенной базы? Даже без списка обязательных полей.

Еще могу заметить, что вариант предложенный в требует совершенно незначительных изменений в 7.7. А величину файла можно варьировать произвольным образом, если выгружать данные почастям.

Ну, тогда опять очень жаль если это так и есть. Хорошо, а как отловить ошибку подключенной базы? Как её идентифицировать? Может я от недосыпа сейчас туго соображаю, но тем не менее... А про вариант в ... Я стараюсь придерживаться принципа "Одна большая красная кнопка", которую нужно нажать пользователю и всё должно заработать. Думаю не мне тебе рассказывать о том, какими ленивыми или тупыми могут быть конечные пользователи. При таком варианте пользователю нужно совершать больше действий, а это приведёт к куче возмущений. Тем более, как я уже сказал, сам механизм переноса уже практически готов.

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

вариант и предусматривает одну кнопку. Дальше все автоматом. :)

+ я имел ввиду, что 8.0 сама запускает 7.7 После выгрузки

Но это опять же требует изменения конфигурации подключаемой базы. А я стараюсь всеми силами этого избежать. :-)

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

Да я это понимаю, но на нежелание изменять целевую конфу есть свои причины. Ладно, не уговаривай меня, я и сам прекрасно осознаю возможные варианты переноса данных. :-)

Мое дело предложить   ;-)

Можно еще из 7.7 попробовать подключиться...    ;-)

Что кстати эффективнее, с точки зрения контроля ошибок. Да и транзакции нужны только для загрузки...

Опять же переделка конфигурации. А информационных баз 7.7 несколько, поэтому удобнее с ними работать из одного места. Тем более что мне транзакции нужны как в подключенной базе 7.7, так и в вызывающей 8.1 одновременно.

А какие переделки при подключении из 7.7 ? Зачем транзакции в 8.1, ведь от туда качаешь? И очень может быть, что они работают. В С-П не написано ограничений на внешнее подключение. Да и вызывать их можно из внешнего подключения локально...

В 8.1 происходит регистрация факта переноса данных, сохраняются соответствия объектов разных ИБ. Естественно, если выгрузка данных не удалась, то фиксировать эти данные нет необходимости.

Собственно, регистрировать можно по факту. Если транзакция в 7.7 прошла успешно, то можно регистрировать. Опять же, если 8.1 можно менять (а кто сейчас работает на стадартной?), то транзакцию можно запустить локально. Если она, конечно, в таких условиях необходима( или при регистрации то же возможны ошибки?..).

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

Гуд найт. Желаю скорейшего решения проблемы.