Необходимо хранить на сервере в базе данных файлы документов (doc). Решаю эту задачу на NET 4, C#, ADO, MSSQL2005Express. Поискал пути решения, и на данный момент собирался использовать для загрузки файла такой вариант:

Создаю таблицу на сервере:
 

Далее клиентское приложение предлагает пользователю выбрать файл для отправки на сервер. Пользователь выбирает файл, приложение берёт путь к файлу, составляет и отправляет sql-запрос:
 

Всё это вполне работает если служба sql-сервера и клиентское приложение выполняются на одной машине. Как только это две разных машины, то служба сервера не находит этот файл, так как на диске цэ той машины на которой выполняется служба нет такого файла. Это легко решаемо. Например, клиентская программа может скопировать указанный пользователем файл в папку с общим доступом и прислать в sql-запросе сетевой путь, либо скопировать файл в папку на сервере и так же прислать локальный путь в запросе.
Как мне кажется, эти варианты имеют недостатки. Например: после копирования файла на сервер отсылается запрос на загрузку этого файла в базу данных, но между окончанием копирования в выполнением запроса, файл по ошибке был изменён незвестным участником. Результат - нарушение целостности данных (загружен искажённый файл). Или такой вариант: файл был скопирован в сетевую папку с общим доступом, потом отправлен запрос на загрузку файла в БД, затем прерывается доступ к сетевому ресурсу, и запрос на загрузку не прокатит и вернёт ошибку. К тому же эти два варианта связаны с дополнительными требованиями для работы программы и дополнительными заботами. 
Поэтому я подумал о таком варианте: клиентская программа загружает в память файл преобразует его в строку вида 0x1298649337038... и выполняет sql-запрос:

Похоже это может прокатить, но наверняка есть ограничение на длину sql-запроса. Вопрос: какая максимальная длина sql-запроса для MSSQL 2005 Express ?

Даже если длины не хватит можно действовать так: клиентское приложение загрузит в память файл, разобьёт его на части, преобразует части в строки вида 0х12345, создаст в БД временную таблицу, загрузит в неё по частям все куски файла, запустит хранимую процедуру которая склеит части занесёт результат в постоянную таблицу и удалит временную.

Может есть менее трудоёмкие варианты решения?


Это сообщение отредактировал(а) Hobotanius - 27.10.2011, 10:00

Эммм... вроде bulk insert нормально работает и с UNC-путями...

А я разве говорил, что  bulk insert не работает с сетевыми путями? Где я такое говорил?! Не понимаю к чему относится ваше высказывание... :( 

К тому, что при расположении файла на удалённом ресурсе его по-любому надо принять на сервер... и я не понимаю, почему, вместо того, чтобы принимать сразу в БД, Вы стремитесь принять его в какое-то промежуточное хранилище, хотя чётко знаете, что это удлинит процесс и породит потенцию дополнительных проблем.

Просто не знаю как загрузить сразу в БД запросом openrowset bulk. 
Потому что запрос

будет построен на клиенте а выполняться на серваке. А на серваке такого файла нет. А там где этот файл есть не обязательно есть общий доступ. Поэтому я и думаю о том как обойти это... Пересмотрел варианты в инете, но так и не понял как они работают. Хотя вот щас нашёл пример OLE щас попробую переделать.

Ясен пень.


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

В текст запроса запихивать файл - идея однозначно плохая... а что, если в этом 'MyDocument.doc' окажется рисунок? или, как любят некоторые му ламеры, отсканенный документ на двадцать страниц в 600 dpi?

Загружай файл на сервер по FTP (само собой неанонимно, и оттуда файл должен быть доступен SQL-серверу), и оттуда забирай. А по крону FTP зачищай (скажем раз в 10 минут файлы старше получаса).

Нет этот вариант не радует. Этот вариант я уже описал в первом посте - прога просто копирует файл на сервак в папку с общим доступом и отсылает команду загрузки. А по ftp или по другим протоколам разницы принципиальной для меня нет. К тому же вы сами критиковали этот вариант:



Я нашёл тут пример реализации: http://nullpro.info/2011/chteni-i-zapis-dv...yx-fajlov-v-bd/
и попробовал переделать по образцу. Вот что получилось:


Однако sql выдаёт ошибку синтаксиса. :(

Неправильный синтаксис около конструкции "?".
Странно как же у автора такое прокатывало?

Это сообщение отредактировал(а) Hobotanius - 27.10.2011, 14:10

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


Почему? Это Ваша индивидуальная особенность?


Попробуйте получить запрос в том виде, в котором он отправляется Sql-серверу...

Да именно так, потому что нет возможности сечас изучать программную передачу по ftp. Пилотный вариант программы должен быть готов к началу декабря - первая неделя декабря. Я и так потратил месяц-полтора на изучение wpf и сейчас вроде как успеваю по срокам, но впритык. Поэтому мне легче и быстрее открыть файл на стороне клиента, а затем создать его копию на севаке и загрузить в БД.


Да это есть. Вот значение cmd.CommandText в момент возникновения исключения:


То есть такое ощущение, что строки:

ни повлияли на запрос. Это странно.

Однако, когда я выполняю этот запрос:

через SQL Manager, то ошибка которую выдаёт сервак звучит подругому, вот так:
"Отсутствует значение для одного или нескольких требуемых параметров."

Хотя столбцы допускают null.

Используйте штатный MS Inet Transfer Control 6.0. Изучение которого займёт от силы 10 минут.


Этот момент - исключения и прочее - лучше обсуждать в разделе "Базы данных под .NET" или около того. Я в оном не силён. 
Там же попробуйте спросить, как получить окончательный, отправляемый серверу, текст запроса, с подставленными в него значениями параметров.

Сделал запрос в поисковике - MS Inet Transfer Control 6.0 и С# MS Inet Transfer Control 6.0. Но к сожалению на первых пяти страницах информации о том как это использовать под C# не нашёл. Боюсь это займёт не 10 минут.



Вы имеете ввиду - совсем на другом форуме? Потому как на Винграде такого раздела я что-то не нашёл...

Добавлено через 8 минут
Уже нашёл... Сначала не там искал.

Решение найдено:


Спасибо, Akina, помог форум который вы подсказали.

Это сообщение отредактировал(а) Hobotanius - 27.10.2011, 16:43

Только проверьте, как оно будет себя мироощущать на файлах в несколько мегабайт размером. И что будет с таблицей БД при обвалах связи.