WRITETEXT
Эта функция оставлена только для совместимости. Ее заменила более мощная UPDATETEXT, которую я рассмотрю позднее.
Вот синтаксис функции WRITETEXT:
| WRITETEXT { table.column text_ptr } [ WITH LOG ] { data } |
table.column – таблица и колонка;
text_ptr – указатель;
with log – игнорируется для SQL Server 2000;
Data – данные. Их размер не может превышать 120 Кб.
WRITETEXT полностью перезаписывает содержимое колонки. Для операции обновления также актуальна проблема действительности указателя. Но здесь уже недостаточно просто установить коллективную блокировку на обновляемую строку, так как это может привести к взаимоблокировке, например, если две транзакции одновременно получают коллективную блокировку и пытаются сконвертировать ее в монопольную. Для предотвращения подобной ситуации необходимо наложить блокировку обновления. В следующем примере производится обновление бинарных данных в первой строке:
| declare @p binary(16) begin tran select @p = textptr(img) from blob_test (updlock) where id = 1 if textvalid('blob_test.img',@p) = 1 writetext blob_test.img @p 0x4034 commit |
Более подробно механизм блокировок в MS SQL Server и понятие уровней изоляции транзакций рассмотрены в предыдущем номере журнала.
UPDATETEXT
Эта более мощная функция обновления данных, чем WRITETEXT. Она также позволяет копировать данные из другой колонки (правда, нельзя указать размер копируемых в этом случае данных). Вот ее синтаксис:
| UPDATETEXT { table_name.dest_column_name dest_text_ptr } { NULL | insert_offset } { NULL | delete_length } [ WITH LOG ] [ inserted_data | { table_name.src_column_name src_text_ptr } ] |
table_name.dest_column_name – таблица и колонка.
dest_text_ptr – указатель на обновляемую область.
insert_offset – смещение в байтах, по которому будут изменяться данные. Если указывается NULL, данные будут добавлены к текущим данным.
delete_length – количество удаляемых байт. Если указывается NULL, данные будут удалены от смещения до конца. Для вставки данных необходимо указать значение 0.
with log – не имеет значения на SQL Server 2000.
inserted_data – вставляемые данные.
table_name.src_column_name – таблица и колонка, откуда данные вставляются.
src_text_ptr – указатель на исходные данные.
Следующие два вызова аналогичны:
| WRITETEXT table.column text_ptr inserted_data UPDATETEXT table.column text_ptr 0 NULL inserted_data |
Давайте рассмотрим пример. Предположим, я ошибся, набирая имя своей жены, и мне его сейчас необходимо заменить:
| declare @p binary(16) declare @l int,@idx int begin tran select @p = textptr(txt), @idx = patindex('%Rosa%',txt)-1, @l = datalength(txt)-(patindex('%Rosa%',txt)-1) from blob_test (updlock) where id = 1 if textvalid(' blob_test.txt',@p) = 1 updatetext blob_test.txt @p @idx 4 '[Correct name]' commit |
Пожалуй, это все. Осталось еще одна тонкость.
Данные в строке
Читая Books Online, я наткнулся на такое предложение:
After you have turned on the text in row option, you cannot use the READTEXT, UPDATETEXT or WRITETEXT statements, to read or modify parts of any text, ntext, or image value stored in the table.
Вот это да! Т.е. я не могу пользоваться функциями, приведенными выше, если таблица находится в режиме «данные в строке»? Это неправда. Хотя вот такой пример может убедить кого угодно:
| declare @p binary(16) declare @idx int,@l int select @p = textptr(ntxt), @idx = patindex('%is%',ntxt)-1, @l = datalength(ntxt)/2-(patindex('%is%',ntxt)-1) from blob_test (repeatableread) where id = 1 if textvalid('blob_test.ntxt',@p) = 1 readtext blob_test.ntxt @p 0 14 |
Он выдает ошибку:
You cannot use a text pointer for a table with option 'text in row' set to ON.
Дело в том, что в режиме «данные в строке» указатель становить неверным сразу же по окончании транзакции. Так как SQL Server по умолчанию находится в режиме автоматического подтверждения транзакции (auto commit), указатель перестает быть действительным сразу после выполнения запроса. Чтобы наш пример заработал, необходимо включить обе операции (получение указателя и его использование) в одну транзакцию. Кроме этого, SQL Server автоматически устанавливает коллективную блокировку в момент получения указателя для данных в строке, так что не нужно прибегать к каким-либо хинтам. Эта блокировка снимется после того, как указатель станет недействительным. Как я сказал, это происходит в конце транзакции или при использовании следующих команд:
create clustered index
drop clustered index
alter table
drop table
truncate table
sp_tableoption(‘text in row’)
sp_indexoption
Можно и вручную сделать указатель недействительным с помощью вызова функции sp_invalidate_textptr.
Если транзакция выполняется на уровне изоляции READ UNCOMMITTED, полученный указатель можно использовать только в операциях чтения. Операция обновления закончится ошибкой 7106: You cannot update a blob with a read-only text pointer.
В этом разделе я приведу примеры работы с большими объектами, используя ADO.NET и ADO. Начнем с простого.
Чтение изображения и вывод на экран с помощью VB6
Хотя VB6 уже не так популярен, как несколько лет назад, на нем все же очень удобно писать определенного вида программы. Я иногда просто удивляюсь, как много VS.NET переняла из среды VB6, вплоть до иконок. Программируя на C#, вы по прежнему в меню Project можете найти пункт References, а в списке событий формы – события OnLoad. Очень удобная технологий DataBinding, которую я и буду использовать в примерах, также благополучно перекочевала в дотнет. На самом деле, очень много знаний из «прежней жизни» вы можете использовать в новой среде. Вот только я не понимаю, почему совместимости в ADO.NET уделено меньше всего внимания. Например, тот же самый DataBinding не работает со старым ADO. Вместо этого нужно «заливать» ADO-шный Recordset в DataSet, и использовать уже его. Ну, хватит лирики, давайте перейдем к предмету разговора.
Алгоритм вывода изображения на экран из БД может быть таким:
Подготовка соединения;
Открытие соединения;
Выборка данных в Recordset;
Связывание изображения с помощью встроенной технологии DataBinding.
Вот фрагменты кода из демонстрационного приложения, реализующие этот алгоритм.
| 'Задаем провайдера conn.Provider = "sqloledb" sb.SimpleText = "Connecting to DB..." sb.Refresh 'Открываем соединение с БД conn.Open "localhost", "user", "psw" sb.SimpleText = "Ready" sb.SimpleText = "Loading image..." sb.Refresh Dim ra As Long 'Создаем Recordset Set rs = conn.Execute("select * from blob_test", ra) 'Производим связывание данных Set imgImg.DataSource = rs 'Здесь выполняется фактическая пересылка данных 'и вывод изображения на экран imgImg.DataField = "img" sb.SimpleText = "Ready" ... |
Если нужно просто сохранить графический объект в файл на диске, алгоритм несколько меняется. Вместо связывания данных нужно открыть файл на запись и записать в него данные. Однако все не так просто:
| 'Открываем файл как бинарный для записи Open "c:\temp_img.bmp" For Binary Access Write As #1 Dim b() As Byte 'Выделяем память под массив ReDim b(Len(rs.Fields("img").Value)) 'Копирование данных в массив b = rs.Fields("img").Value 'запись в файл Put #1, , b Close #1 |
В этом примере мне пришлось скопировать данные во временный буфер, так как инструкция Put добавляет к некоторым типам, экземпляры которых вы хотите сохранить, разные заголовки. Зачем это сделано, мне не совсем понятно; видимо разработчики хотели упростить реализацию сохранения/восстановления состояния переменных программы, однако это у них не очень хорошо получилось – для объектов эта инструкция не поддерживается. В случае сохранения таким образом:
| Put #1, , rs.Fields("img").Value |
в файл запишется одному лишь богу известный заголовок, который будет мешать воспринимать этот файл как нормальный bmp. Поэтому я вынужден копировать данные в дополнительный массив байтов и сохранять уже его.
Для чтения графической информации из файла можно воспользоваться инструкцией Get.
Все идет хорошо до тех пор, пока не понадобится читать/писать бинарные данные небольшими блоками. Здесь на помощь приходят следующие методы:
AppendChunk – применим к полям с атрибутом adFldLong. Если метод вызван первый раз с тех пор, как вы редактируете текущее поле, данные перезаписываются. Иначе - метод добавляет данные к существующему значению. Другими словами, если вы только начали редактировать поле, вызвав метод AppendChunk, содержащиеся в нем до этого значения будут потеряны. Однако последующие вызовы метода будут добавлять данные к существующему значению. Как только вы начнете редактировать другое поле, возможность добавлять данные исчезнет. Этот метод также можно вызвать для параметров с установленным атрибутом adParamLong. Для параметров данные всегда добавляются к существующим.
GetChunk – применим к полям с атрибутом adFldLong. Возвращает заданное количество байтов с позиции, на которой закончилось предыдущее считывание данных. До тех пор, пока вы не перейдете к работе с другим полем, данные будут считываться последовательно. Если вы начали работать с другим полем, а потом вернулись к этому, данные снова будут читаться с нулевого смещения.
Эти два метода позволяют работать с порциями (chunks) данных. Например, вот такой код позволяет считать всего лишь первые 100 байт данных:
| Dim b() As Byte b = rs.Fields("img").GetChunk(100) |
Это все замечательно, но как же рекомендации MSDN использовать более гибкий объект Stream? Сейчас мы и до него доберемся.
Работа с изображением с помощью Stream на С++
Я выбрал С++, так как с VB6 мы уже поработали (хорошего помаленьку), и потому, что большинство вопросов касается именно С++. (На RSDN ходят настоящие индейцы.)
Алгоритм действий примерно тот же, что и в предыдущем примере:
Подготовка соединения.
Открытие соединения.
Выборка данных в Recordset.
Создание и открытие объекта Stream.
Чтение данных в Stream.
Работа со Stream.
Код реализации алгоритма приведен далее, а сейчас я бы хотел остановиться на шестом пункте, так как он выглядит слишком расплывчато, а мы, программисты, чужды неопределенности.