Передача большого SQL-запроса из программы

Есть ERP navision
из которой через 'Microsoft ActiveX Data Objects 2.8 Library' выполняется SQL запрос и обрабатывается результат
Проблема в том, что через метод Execute этой библиотеки можно передать запрос длиной 4000 символов.
Появились запросы большей длины.

Выполнение запроса из файла требует наличие на каждой машине утилит (ISQL / OSQL) - не подходит.

Как возможное решение есть идея создать таблицу с blob-полем, куда накидывать кусками код запроса, затем на стороне SQL-сервера итоговый запрос доставать и выполнять
Сказано-сделано.

Запрос накидываем кусками в таблицу [User Query] (ID - int (ID сессии), [Query Text] - blob - (текст запроса))

DECLARE @ptrval binary(16),

SELECT @ptrval = TEXTPTR(QueryText)
from dbo.[User Query]
where ID=@ID
UPDATETEXT dbo.[User Query].QueryText @ptrval NULL 0 @SQL;


Но когда пытаюсь считать,

SELECT @ptrval = TEXTPTR(QueryText)
from dbo.[User Query]
where ID=@ID
READTEXT dbo.[User Query].QueryText @ptrval 0 0;

результат в виде

0x73656C65637473656C65637473656C65637473656C656374


Вопрос - я вообще тем путем пошел ? Может есть более тривиально решение.
Если с путем все ОК - как из этой дряни итоговый текст запросы получить ?

select @@version
?

invm,

Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) (Build 3790: Service Pack 2)

dmites,

Может, varchar(max) ?

Может лучше подкорректировать запросы?
А то:

автор
Оптимизатор запросов SQL Server, возможно, сопоставит инструкции Transact-SQL из процедуры sp_executesql с планами выполнения из выполнявшихся ранее инструкций, обойдя тем самым дополнительную нагрузку по созданию нового плана выполнения.

автор
способность оптимизатора запросов SQL Server сопоставлять новую строку Transact-SQL с уже существующим планом выполнения снижается из-за постоянно изменяющихся значений параметров в тексте строки, особенно в сложных инструкциях Transact-SQL

monsenior,
Рад бы подкорректировать, но по бизнес-логике
запросом выбираю данные по списку товаров, предварительно загруженных пользователем из excel.

Пользователь, радуясь такой возможности, загружает список из 50 и более артикулов
и получаем конструкцию в запросе

where .... and ItemNo in ('1919191','9393939', ... 50 артикулов) and ....

dmites,
А если загрузить в таблицу и потом джойнить, то запрос будет коротеенькиммм

Гузы,

да можно и так
и универсальную таблицу сделать ID сессии / Универсальное поле
наполнять и джойнить с ней при выборке с условием в виде большого списка.

Но хотелось бы универсальное решение - как изящно протолкнуть SQL- серверу запрос
любой длины.

В студии можно ведь километровый сценарий написать и выполнить. Почему программно нельзя без перверсий ?

Почему blob без проблем дает запихнуть в себя текст и не дает его получить назад в том же виде ?

dmites, а почему varchar(max) вместо blob не подошёл?

Гм... Если речь идет о методе Execute объекта Command, то у этого самого объекта есть коллекция параметров, которые могут быть гараздо длиннее, чем 4000. А sp_executesql уже давно имеет параметер @stmt с тимом nvarchar(max).