Странный глюк проявляется, причем только на одном месте.

При запуске одной обработки (из самописной базы производства) производится запуск по OLE другой базы (самописной базы упаковки), затем выполняется в ней (в упаковке) одна процедура, получаем ТЗ, и переменная OLE сразу же обнуляется.
Такое происходит дважды за время работы процедуры.

Обработка запускается на разных рабочих местах (как на обычных компьютерах, так и на терминалках, работающих по RDP на серваках), но глюк происходит только на одном рабочем месте, работающем по RDP: при попытке инициализировать переменную выдается такая ошибка:

БДупак=CreateObject("v77.application"); : {\\PDC\1CBASE\MANUF\ERTS\ПЕРЕМЕЩЕНИЕСУБПРОДУКТОВ.ERT(4430)}: Неудачная попытка создания объекта (v77.application)

Опытным путем выяснили, что, если закрыть Производство, запустить процесс от имени администратора, и запустить эту обработку, то тогда, после закрытия процесса, запущенного от имени админа, пользователи могут спокойно работать с этой обработкой. НО! Только какое-то время. Затем ситуация повторяется.
Мало того, чаще бывает, что процесс 1с от имени администратора не запускается. Другие процессы - легко, а вот именно 1с - никак. Вводишь логин/пароль - процесс закрывается. Помогает в таких случаях только завершение сеанса, подключение повторное, сразу запуск 1с от имени админа (если запустить от имени пользователя - ситуация может повториться), запуск обработки, закрытие - и только тогда пользователь может спокойно ее запускать, но опять же - только некоторое время. Сколько времени глюка не будет - неизвестно, то несколько дней спокойно работают, то в течение дня пять раз мне звонят.

Пробовали создать другого пользователя - не помогло.
Создали перемещаемый профиль, подключились к другому серверу - не помогло.

Да, заметили такую вещь недавно (раньше то ли не обращали внимания, то ли не было) - процессы, запущенные по OLE, закрываются не сразу. Очень не сразу - может несколько минут пройти, пока закроется. Я уже обработку закрыл - а процессы висят. Причем, могут и вообще подвиснуть - не раз было, в последнее время, что вижу в таск менеджере несколько процессов, и явно OLEшных. Впрочем, их закрытие не помогало, обработка все равно не работала...

откажись от оли, будь мужиком!

пиши прямой запрос к сторонней базе

обнуляй все переменные, которые ссылаются на OLE объекты перед закрытием

(2) - в смысле, скульный запрос? Или что ты имеешь в виду?

да, забыл сказать, что это 7.7

(3) Обнуляю переменную сразу после возврата ТЗ, написал про это в (0).
Мало того, на всякий случай, обновляю и при закрытии обработки.
Глюк происходит независимо от того, закрывают ли пользователи обработку после выполнения, и независимо от того, закрывают ли они саму программу.

(6) Не обновляю, а обнуляю, ессно :)

в ТЗ-то что хранится? не ОЛЕ объекты?
--------
еще бывает при закрытии какой-нить модальный вопрос типа "Закрыть 1с?"

(8) Код материала, наименование, кол-во

(8) OLEшная база запускается у всех под одним и тем же пользователем, у которого не прописан каталог пользователя (с целью возможности одновременного запуска на разных местах), и ни у кого такой вопрос не возникает. Да и на этом месте вопрос бы возникал всегда, не?

Что, никто с подобным не сталкивался?

(4) в смысле, прямой.

А формат базы (sql/дбф) не имеет никакого значения.

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

..хотя мысль такая сегодня как раз возникла... заодно и ограничение на 2 минуты снимется, думаю...

что конкретно надо от внешней базы ?

если не удается создать объект, значит в реестре не видит v77.application.
Либо с правами, либо с виндой проблемы. Если не ошибаюсь подобная проблема возникала на windows 7, но она решаема - покапаться в гугле надо.

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

(15) Конкретно надо выбрать по определенным условиям документы одного вида, и из их табличной части получить ТЗ со списком материалов и кол-вом.

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

(16) Какие именно могут быть проблемы с правами, если после запуска в этом же сеансе 1с с правами админа и запуска той же обработки, запускается все нормально?

С админами пытались решить проблему, не получилось.
Кроме того, как уже говорил, пробовали к разным сервакам подключаться (думали, что проблема из-за версии винды на серваке - Win2003 x64, но попробовали на других - 2003x86, и в виртуалке пробовали запускать (2003r2) - везде глюки)...

(16), (18)
Ну приведите пример, плиз. Не понимаю я, как на 7ке можно, кроме как по ОЛЕ, подключиться из одной базы к другой?

(19) ну если в том же сеансе под админом 1с все нормально,
значит под другим логином в 1с нет  прав на использование OLE-сервера

(20) 1с++, либо по АДО..

Ну так, например,для дбф базы:

    ТекстЗапроса = "
    |SELECT
    |    СпрНаш.DESCR as Номенклатурка_ВЭтой_базе  -- наименование номенклатуры в  этой базе
    |    ,Спр.DESCR as Номенклатурка_ВУдаленной_Базе --наименование номенклатуры в удаленной базе
    |FROM $Справочник.Номенклатура СпрНаш
    |left join База2.@Справочник.Номенклатура Спр on СпрНаш.code = Спр.code
    |";
глПарсерВторойБазы(ТекстЗапроса,"База2",ПутьКБазе2);
ТЗ = Запрос.ВыполнитьИнструкцию(ТекстЗапроса);

(19) Вы не поняли. Запускаешь под юзером - может как работать, так и нет. Допустим, не работает. Тогда:
Закрываешь все 1с, завершаешь сеанс (напоминаю, это RDP сеанс) (иногда этого не требуется), входишь, запускаешь 1с от имени админа, запускаешь обработку (все ОК), выходишь из 1С, запускаешь от имени обычного пользователя - все работает (какое-то время).
Т.е. права, получается, есть. Но слетают. ну или какая-то иная причина.

(24) имеется в виду, что запускаешь 1с от имени доменного админа, а не 1с-ного.

(23) 1С++ все же позволяет подключаться к другой базе? Ясно, значит один вариант все же есть. (Просто я 1С++ использовал единожды только, и это было давно, соотв-нно, не знал о такой возможности...Жаль только, что для SQL и DBF команды по-разному писать приходится...)
Спасибо.
Но хотелось бы все же разобраться, в чем проблема? Ведь у нас полно машин, и на многих запускают эту обработку. И глючит только на одном компе. Прям заколдованное место какое-то...

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

(27) Не понял, что сравнивать и с кем?
А винду переустановить вряд ли получится, ибо это сервер. Рабочий. На котором работает куча народу. Да и смысл, если глючит и на другом сервере?

(6) А таблица значений - живёт. И даёт ещё одну ссылочку на тот самый процесс.

(26) И этот комп - тот самый сервер из (28)? 64-разрядный?
А в реестре смотреть _в момент глюка_ не пробовали?

(29) Думаете? Т.е. имеет смысл, когда ТЗ уже не нужна, ее обнулять?

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

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