LINUX.ORG.RU

MsSQL - аналог функции pack PHP

 , ,


0

1

Привет. Стоит задача с формы на php записать данные в удаленную MsSQL базу. Использую PDO. Имеется следующая проблема - на MsSQL сервере стоит ограничение на размер передаваемых данных, если записывать их через bind. Т.е. если я попробую содержимое файла передать таким образом

$stmt->bindParam(':content', $contents, PDO::PARAM_LOB);
то в столбец в базе запишется только первые 4000 символов

Если же я просто приклею содержимое файла к строке запроса

$dbh->query("insert into tbl_Files(ItemTypeID, Link, FileData, CreatedOn) 
values (
'{39A5B367-4A7A-473E-8F74-26977CB6DB67}', 
'".$value['NAME']."', '".$content_file."', '".$CreatedOn."');");
то поймаю ошибку, т.к. в строку запроса попадут бинарные символы. Хотя если читать файл в текстовом формате, то запись успешно проходит(но мне нужно передавать картинки и прочее)

Попробовал решить проблему через unpack, т.е.

$data = unpack("H*hex", $contents);
$dbh->query("insert into tbl_Files(ItemTypeID, Link, FileData, CreatedOn)values 
('{39A5B367-4A7A-473E-8F74-26977CB6DB67}', '".$value['NAME']."', '0x".$data[hex]."', '".$CreatedOn."'
);");
и все записывается успешно, но теперь на сервере необходимо каким-то образом провести обратную процедуру, т.е. перевести 16-ричные данные в обычное бинарное содержимое файла. Т.е. по сути мне нужен аналог функции пхп-шной функции pack. Сам столбец в базе имеет тип IMAGE. Версия сервера Microsoft SQL Server 2016

Может кто-то подскажет, в какую сторону копать в решении задачи?

А что мешает увеличить ограничение?

Как вариант - записывать несколько раз, блоками по 4000 символов.

Сервер не должен заниматься подобной ерундой, как преобразование входных данных.

FilosofeM ★★ ()
Ответ на: комментарий от FilosofeM

Спасибо за ответ.

А что мешает увеличить ограничение?

то, что там работает сторонняя команда, которая вообще очень неохотно идет на контакт, мотивируя тем, что у них на сервере все работает.

Как вариант - записывать несколько раз, блоками по 4000 символов.

А как это реализовать практически? Разве можно не целиком записать текст в столбец, а выбрать произвольную позицию и туда еще вставить кусок?

Сервер не должен заниматься подобной ерундой, как преобразование входных данных.

я планирую после записи вызывать хранимую процедуру, которая будет обрабатывать столбец. Большой проблемы не вижу

gwyllum ()

Не храни файлы в sql. Храни их название и путь к файлу на диске, где файл хранится под именем хэша его содержимого.

Если всё-таки очень надо хранить файл в sql, то перекодируй его с помощью base64 и записывай текстом.

Ivan_qrt ★★★★★ ()

Сделай хранимую процедуру в базе, которая будет делать insert с перепаковкой данных в бинарный формат, а из пыха вызывай эту хранимку.

Но по хорошему, просто измени ограничение. Я понимаю что база может быть не в твоём ведении, но если какой-то «гуру» решил сделать таблицу с полем image, но при этом установил ограничение на bind, то пусть теперь и трахается с этим сам. К тебе какие вопросы?

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от gwyllum

Как вариант:

update 
  tablename
set
  fieldname = convert(nvarchar(max),fieldname) + 'appended string'
FilosofeM ★★ ()
Ответ на: комментарий от vvn_black

чтение будет производится на стороне MsSQL, т.е. не средствами php. Я так понимаю, можно сделать так: 1. записываешь base64 строку 2. вызываешь хранимую процедуру, которая на стороне сервера перезаписывает колонку, декодируя записанную информацию

gwyllum ()
Ответ на: комментарий от gwyllum

вызываешь хранимую процедуру

Зачем так? Как сказали уже «cервер не должен заниматься подобной ерундой, как преобразование входных данных», БД без разницы формат в котором данные, это проблема клиента, как их интерпретировать. Т.е. кодирование/декодирование должно быть на клиенте.

чтение будет производится на стороне MsSQL

Данные же кто-то будет читать, какой-то клиент, вот пусть он их и декодирует.

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 2)
Ответ на: комментарий от vvn_black

Данные же кто-то будет читать, какой-то клиент, вот пусть он их и декодирует.

к сожалению, на той стороне заниматься такой фигней никто не будет. Одно дело просто считать блоб и записать его в файл, другое - разбираться как-что устроено. Повторюсь - нормальной коммуникации со второй командой нет. Наше дело записывать на удаленный сервер данные в готовом виде.

gwyllum ()
Последнее исправление: gwyllum (всего исправлений: 1)
Ответ на: комментарий от gwyllum

нормальной коммуникации со второй командой нет. Наше дело записывать на удаленный сервер данные в готовом виде.

Печаль.

vvn_black ★★★★★ ()
Последнее исправление: vvn_black (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.