Никто не работал с 1С:Предприятие 7.7 (SQL, если это важно) через OLE
из T-SQL? Измотался весь, никак не проходит этап инициализации
Два абсолютно одинаковых куска кода в VBA работают, а в t-sql нет
Метод Initialize постоянно возвращает False и в итоге ничего не прет.

Помогите pls...

Код следующий... пути к конфигурации пробовал задавать и через обычные и через UNC.
Пробовал ставить NO_SPLASH_SHOW и не ставить - однофигственно
В любом случае в @property2 оказывается False.
Хотя если тоже стамое написать на VBA в property2 окажется True.
Сам 1c7vs.exe пускается...

-----------------------------------------------------------------
DECLARE @object int
DECLARE @hr int
DECLARE @property varchar(255)
DECLARE @property2 varchar(255)

EXEC @hr = sp_OACreate 'V77.Application', @object OUT
IF @hr <> 0
BEGIN
EXEC sp_displayoaerrorinfo @object, @hr
RETURN
END

EXEC @hr = sp_OAGetProperty @object, 'RMTrade', @property OUT
IF @hr <> 0
BEGIN
EXEC sp_displayoaerrorinfo @object, @hr
EXEC @hr = sp_OADestroy @object
RETURN
END

EXEC @hr = sp_OAMethod @object, 'Initialize', @property2 out, @property, '/D\server_bdc\1cdat$ /N OLE /P ole', ''
IF @hr <> 0
BEGIN
EXEC sp_displayoaerrorinfo @object, @hr
EXEC @hr = sp_OADestroy @object
RETURN
END

select 'property2',@property2

EXEC @hr = sp_OADestroy @object
IF @hr <> 0
BEGIN
EXEC sp_displayoaerrorinfo @object, @hr
RETURN
END
-----------------------------------------------------------------

упс... при постинге один слэш съелся - конечно в пути следует читать \server_bdc, а не \server_bdc

Народ... Ну попробуйте кто-нибудь? А?
Ну срочно нужно делать... Если 1c принципиально так не хочет, буду
по другому.

На сервере конечно... иначе не имело бы смысл городить огород через t-sql.
У меня такое впечатление, что у 1с крышу сносит

2Владимир: нет, то что ты советовал не помогло...

2All:
Итак, в результате разбирательств выяснено следующее:
1).Initialize принципиально не хочет понимать локальных досовских путей (хотя из командной строки все работает);
Либо я чего-то не допонял...
2).Работает только через unc пути;
3).В настройках баз должен быть обязательно прописан именно этот путь (иначе выкидывает окно с просьбой регистрации базы);
4).И самое главное - SQLСервер у меня стартует под эккаунтом отличным от администратор. А у меня на шару не было разрешений для sql сервера. А приложение на VBA стартовало от администратора. Но даже после правильного
проставления разрешений - первые два пункта так и остаются в силе.

Всем спасибо за помощь...

с пунктом 3 приминительно к unc путям я похоже поторопился

2Владимир:
Не, сейчас то все работает, скул стартует под аккаунтом отличным от domain admin и localsystem.
Насчет 1c - я не проверял, но должна стартовать нормально.
Вопрос не в этом - почему 1с из t-sql не хочет понимать локальные пути?

Ладно, но у меня есть еще вопросы
На одной машине код работает нормально, на другой с точно такой же
конфигурацией и версиями продуктов не хочет. После разбирательств выяснено,
что 1с в упор не хочет понимать русскоязычные названия методов и свойств, а только
хочет чтоб по английски. То же самое, но на VBA работает нормально...
Куда копать?

Хм... А как обращаться тогда к свойствам, которые не имеют
англоязычных аналогов (я только начал изучать 1с - поэтому могу быть не прав)?
Скажем .ПолнНаименование из Справочник.Контрагенты?
Пробовал использовать SetAttrib("ПолнНаименование") - те же яйца, только сбоку.
А насчет исходника - так он элементарный, открытие справочник
контрагентов и добавление туда новой записи. Так сказать пока тестовый вариант
для обкатки технологии Дальше будет уже сложнее...

Вообще, у тебя наверняка должны быть какие-то наработки и технологии
по вызову 1с из t-sql - не поделишься опытом?

Есть самописное приложение на билдере под mssql 7.0. С ним работают
менеджеры по оформлению кредитных договоров
Задача минимум - организовать в более-менее реальном времени (то есть
сейчас я пока думаю подвесить эту задачу на job, выполняющуюся каждый час, скажем)
выгрузку новых контрагентов и договоров из этого приложения в 1с, а обратно
загружать данные о проводках и платежах. В принципе можно работать и из 1с с sql
через Ole. Можно попытаться сделать экспорт в xml с последующим импортом.
Но имхо удобнее все ж таки будет первый вариант.

>А почему не хочешь перевести данные и логику по договорам вообще в 1С?

долго и муторно... у меня просто нет на это время.
к тому же данное приложение крутится и там, где в помине нет 1с

> может это проще окажется?

к сожалению нет

>Хотя, если работаете с типовой и она устраивает - лучше так не делать. Потом с обновлениями будет сложно.

в том то все и дело...

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

а вот про это можно подробнее? что такое msmq я себе представляю, но как с помощью нее
осуществить связь? или ты тоже предлогаешь связать все это дело через ole?

>или даже просто выбрасывание данных в файл на диске, а 1С:Пр, которое на отдельной машине болтается и где прописана в >коде ОбработкаОжидания(), будет наличие файла щупать и подгружать то что нужно

это самой простой и очевидный выход... осталось только найти свободную машину

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

хм... на это я пока не наталкивался. спасибо за предупреждение.

Еще будут варианты и мнения?