При разработке СОМ компоненты я столкнулся со проблемой. Есть Out-of-process СОМ компонента, которая представляет собой Windows Service и создана с помощью ATL.
В методе
HRESULT calculatePathsByDestination([in] LONG src, [in] LONG dst, [in] LONG dist, [out,retval] VARIANT* res)
мы возврощаем клиенту SafeArray массив в виде вариант (VARIANT). SafeArray создаём функцией SafeArrayCreateVector.
Клиентом для этого СОМ сервера является
SQL Server 2000 Extended Procedure. После вызова СОМ-метода в Extended Procedure мы удаляем с помощью функции SafeArrayDestroy полученный от сервера SafeArray для освобождения ресурсов. На 5 – 10 цикле обращений к SQL Server Extendet Procedure мы получаем критичискую ошибку в этой же процедуре на вызове функции CoCreateInstance!
Вид ошибки под SQL Query Analyzer:
«ODBC: Msg 0, Level 20, State 1
Stored function 'xp_distmet2_calcPaths' in the library 'xp_distmet2.dll' generated an access violation. SQL Server is terminating process 51.
Connection Broken»
Если закоментировать вызов
SafeArrayDestroy, то тогда Extendet Procedure работает корректно, не считая не большой утички памяти.
Мы пытались экперементировать заменая SafeArrayDestroy на функции SafeArrayDestroyData и SafeArrayDestroyDescriptor. Но, при вызове SafeArrayDestroyDescriptor мы получаем туже самую ошибку.
Интересно заметить, что абсолютно тот же самый код из Extended Procedure, перенесённый в отдельную тестовую программу работает абсолютно корректно с вызовами SafeArrayDestroy.
Может кто встречался с такой же проблемой?
Здравствуйте, dimaa, Вы писали:
D>Снимаю свой вопрос. 
А в чем причина-то была?
Здравствуйте, lgb, Вы писали:
lgb>Здравствуйте, dimaa, Вы писали:
D>>Снимаю свой вопрос.
lgb>А в чем причина-то была?
Всамом деле просто обычная не внимательность.
В Extended Procedure передавался _variant_t, а как известно у него деструктор удаляет SafeArray. В тестовых программах передавался простой VARIANT.
Поэтому прошу извинения за беспокойство.
