В таблице есть поле типа IMAGE для хранения разного рода информации (изображения, бинарные массивы и т.д.). В это же поле я писал XML-структуры, которые конвертил из стринга в массив байтов, поскольку держать в этой же таблице поле типа TEXT посчитал неразумным из соображений редкого использования данного поля.

byte[] byteArray = System.Text.Encoding.Unicode.GetBytes(MyXmlString);

Проблема такая:
Понадобилось открывать XML, изредка встречающийся в этом поле, на SQL Server для получения разного рода информации. Процедура sp_xml_preparedocument на вход берет текстовый параметр (text, varchar, и т.д.), объвление в хранимой процедуре локальных переменных типа TEXT или IMAGE запрещено.
Итого: из поля типа IMAGE нужно получить строку в качестве входного параметра для sp_xml_preparedocument.

Может кто сталкивался с такой проблемой? Заранее спасибо.

Здравствуйте, _Senya, Вы писали:

_S>Может кто сталкивался с такой проблемой? Заранее спасибо.
можно попробывать такой вариант, правда только varchar(8000),и при конвертации в nvarchar нужно разобраться с кодировками.

declare @paramXML varchar(8000)
select @paramXML = cast(cast([FieldImage] as varbinary) as varchar(8000)) from dbo.table1    where (условие если надобно)

Здравствуйте, FantomGood, Вы писали:

_S>>Может кто сталкивался с такой проблемой? Заранее спасибо.
FG>можно попробывать такой вариант, правда только varchar(8000),и при конвертации в nvarchar нужно разобраться с кодировками.

FG>

FG>declare @paramXML varchar(8000)
FG>select @paramXML = cast(cast([FieldImage] as varbinary) as varchar(8000)) from dbo.table1    where (условие если надобно)
FG>

Спасибо за ответ, я не упомянул, что объемы значительно больше 8К, потому это и является проблемой. Параметр типа varchar потому и неприменим.

Ну неужели никто с этим не сталкивался?!

Здравствуйте, _Senya, Вы писали:

_S>Ну неужели никто с этим не сталкивался?!

да как-то оно не очень понятно для чего нужно. по сути "большие" типы данных типа text и image не предназначены для активной обработки сервером. они скорее просто для хранения. да и по сути, поле данного типа — указатель на "массаив данных".

в общем проще почитать:

Usually, text, ntext, or image strings are large (a maximum of 2GB) character or binary strings stored outside a data row. The data row contains only a 16-byte text pointer that points to the root node of a tree built of internal pointers that map the pages in which the string fragments are stored.

With Microsoft SQL Server, you can store small to medium text, ntext, and image values in a data row, thereby increasing the speed of queries accessing these values.

When the text, ntext, or image string is stored in the data row, SQL Server does not have to access a separate page or set of pages to read or write the string. This makes reading and writing the text, ntext, or image in-row strings about as fast as reading or writing varchar, nvarchar, or varbinary strings.

To store text, ntext, or image strings in the data row, enable the text in row option using the sp_tableoption stored procedure.

sp_tableoption N'MyTable', 'text in row', 'ON'

Optionally, you can specify a maximum limit, from 24 through 7000 bytes, for the length of a text, ntext, and image string stored in a data row:

sp_tableoption N'MyTable', 'text in row', '1000'

If you specify 'ON' instead of a specific limit, the limit defaults to 256 bytes. This default value provides most of the performance benefits: It is large enough to ensure that small strings and the root text pointers can be stored in the rows but not so large that it decreases the rows per page enough to affect performance.

Although in general, you should not set the value below 72, you also should not set the value too high, especially for tables where most statements do not reference the text, ntext, and image columns or there are multiple text, ntext, and image columns.

You can also use sp_tableoption to turn the option off by specifying an option value of either 'OFF' or 0:

sp_tableoption N'MyTable', 'text in row', 'OFF'

Здравствуйте, _MarlboroMan_, Вы писали:

_MM_>Здравствуйте, _Senya, Вы писали:

_S>>Ну неужели никто с этим не сталкивался?!

_MM_>да как-то оно не очень понятно для чего нужно. по сути "большие" типы данных типа text и image не предназначены для активной обработки сервером. они скорее просто для хранения. да и по сути, поле данного типа — указатель на "массаив данных".

Суть в слудующем:
Есть таблица Documents и есть таблица DocumentProperties — поля документов. (около 40 млн. записей на сегодняшний день). У некоторых документов есть прилагаемый к ним скан(ы) бумажного носителя. Для этих целей в таблицу полей добавлено поле IMAGE. Далее, понадобилось иногда к определенным типам документов хранить поднабор полей — XML-структуру (почти наверняка больше 8К — поле типа varchar отпало). Решили хранить в том же поле IMAGE — преобразовывать на Application Server в массив байтов при записи в базу и обратно — при чтении из нее. Все было хорошо до тех пор, пока не понадобилось открывать это поле на SQL Server (создание разного рода отчетностей). Вынести часть логики на BusinessRules можно, но код перестанет храниться централизовано — раз, критически упадет производительность — два, поэтому надо изыскать способ открыть его на SQL.

Здравствуйте, _Senya, Вы писали:

_S>Суть в слудующем:
_S>Есть таблица Documents и есть таблица DocumentProperties — поля документов. (около 40 млн. записей на сегодняшний день). У некоторых документов есть прилагаемый к ним скан(ы) бумажного носителя. Для этих целей в таблицу полей добавлено поле IMAGE. Далее, понадобилось иногда к определенным типам документов хранить поднабор полей — XML-структуру (почти наверняка больше 8К — поле типа varchar отпало). Решили хранить в том же поле IMAGE — преобразовывать на Application Server в массив байтов при записи в базу и обратно — при чтении из нее. Все было хорошо до тех пор, пока не понадобилось открывать это поле на SQL Server (создание разного рода отчетностей). Вынести часть логики на BusinessRules можно, но код перестанет храниться централизовано — раз, критически упадет производительность — два, поэтому надо изыскать способ открыть его на SQL.

UDF вполне подойдет для таких целей.

парси внутри ей соответсвующее поле и строй датасет.

работать будет не быстро, но будет.


что-то типа

create function dbo.ParserForMyTable(<здесь можно запараметризовать запрос к нужной табе>)
returns @ret table (<структура возвращаемой таблицы>)
begin
    -- пример из хепа для READTEXT
    DECLARE @ptrval varbinary(16)
    SELECT @ptrval = TEXTPTR(pr_info) 
         FROM pub_info pr INNER JOIN publishers p
                ON pr.pub_id = p.pub_id 
                AND p.pub_name = 'New Moon Books'

    READTEXT pub_info.pr_info @ptrval 1 25
    --конец примера из хепа для READTEXT
    
    --дальше расколбашиваешь @ptrval как угодно и кладешь в @ret
    insert into @ret (<...>) values (<...>)
    
end

и используешь в запросах аль еще где (можно джойнить, строить по этому делу курсоры и т.д., в общем таба как таба, только вставка и удаление отсутствуют):

select * from dbo.ParserForMyTable(<...>)

Здравствуйте, _MarlboroMan_, Вы писали:

_MM_>

_MM_>create function dbo.ParserForMyTable(<здесь можно запараметризовать запрос к нужной табе>)
_MM_>returns @ret table (<структура возвращаемой таблицы>)
_MM_>begin
_MM_>    -- пример из хепа для READTEXT
_MM_>    DECLARE @ptrval varbinary(16)
_MM_>    SELECT @ptrval = TEXTPTR(pr_info) 
_MM_>         FROM pub_info pr INNER JOIN publishers p
_MM_>                ON pr.pub_id = p.pub_id 
_MM_>                AND p.pub_name = 'New Moon Books'

_MM_>    READTEXT pub_info.pr_info @ptrval 1 25
_MM_>    --конец примера из хепа для READTEXT
    
_MM_>    --дальше расколбашиваешь @ptrval как угодно и кладешь в @ret
_MM_>    insert into @ret (<...>) values (<...>)
    
_MM_>end
_MM_>

_MM_>и используешь в запросах аль еще где (можно джойнить, строить по этому делу курсоры и т.д., в общем таба как таба, только вставка и удаление отсутствуют):
_MM_>

_MM_>select * from dbo.ParserForMyTable(<...>)
_MM_>

Проблема, собственно, в том, что этот @ptrval не пойдет на вход процедуре sp_xml_preparedocument — вот что надо сделать: надо на вход этой процедуре передать XML (который лежит в поле IMAGE) с тем, чтобы далее по этому XML построить таблицу.