SQL Server - как "залить" изображения?

kost · 22.03.2009

public void ProcessRequest (HttpContext context)
{
SqlConnection myConnection = new SqlConnection(“YourConnectionString”);
myConnection.Open();
string sql = "Select Image_Content from ImageGallery where Img_Id=*ImageId";
SqlCommand cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.Add("*ImageId", SqlDbType.Int).Value = context.Request.QueryString["id"];
cmd.Prepare();
SqlDataReader dr = cmd.ExecuteReader();
dr.Read();
context.Response.ContentType = dr["Image_Type"].ToString();
context.Response.BinaryWrite((byte[])dr["Image_Content"]);
dr.Close();
myConnection.Close();

}

это все в файле Handler.ashx, а в GridView прописать:

<asp:TemplateField>
<ItemTemplate>
<asp:Image ID="Image1" runat="server" ImageUrl='<%# "Handler.ashx?id=" + Eval("Img_Id") %>' />
</ItemTemplate>
</asp:TemplateField>

но все равно не работает

, SQL запросы подлечить надо, видимо или *.ashx файл в config прописать. Не знаю, потом разберусь. Хорошо, хоть с папки изображения достаются. Не думал столкнуться с таким на SQl, в MySQL все намного проще решаtтся - ctrl+C ->ctrl+V

serg_ksa · 22.03.2009

В отличте от *.axd XTTПHandler'ов, *.ashx обработчики можно не регистрировать в веб.конфиге, но путь к файлу должен быть реальным. Проверь что у тебя правильный путь к Handler.ashx файлу - лучше используй полный путь к хендлеру: ~/Handler.ashx?id=.....

BFG-9000 · 22.03.2009

kost сказав(ла):
Не думал столкнуться с таким на SQl, в MySQL все намного проще решаtтся - ctrl+C ->ctrl+V

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

sergeime · 27.03.2009

kost сказав(ла):
public void ProcessRequest (HttpContext context)
{
SqlConnection myConnection = new SqlConnection(“YourConnectionString”);
myConnection.Open();
string sql = "Select Image_Content from ImageGallery where Img_Id=*ImageId";
SqlCommand cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.Add("*ImageId", SqlDbType.Int).Value = context.Request.QueryString["id"];
cmd.Prepare();
SqlDataReader dr = cmd.ExecuteReader();
dr.Read();
context.Response.ContentType = dr["Image_Type"].ToString();
context.Response.BinaryWrite((byte[])dr["Image_Content"]);
dr.Close();
myConnection.Close();

}

это все в файле Handler.ashx, а в GridView прописать:

<asp:TemplateField>
<ItemTemplate>
<asp:Image ID="Image1" runat="server" ImageUrl='<%# "Handler.ashx?id=" + Eval("Img_Id") %>' />
</ItemTemplate>
</asp:TemplateField>

но все равно не работает , SQL запросы подлечить надо, видимо или *.ashx файл в config прописать. Не знаю, потом разберусь. Хорошо, хоть с папки изображения достаются. Не думал столкнуться с таким на SQl, в MySQL все намного проще решаtтся - ctrl+C ->ctrl+V

И никогда не будет работать, пока ты на свой код не посмотришь с открытыми глазами, что ли... ну или дернул бы свой handler прям из браузера, handler.ashx?id=111. Ведь даже ж не попробовал, так ведь?

sergeime · 27.03.2009

BFG-9000 сказав(ла):
Ну вообще-то в мускуле ты тоже можешь заморочиться с подготовкой запроса и потом выполнением его с разными параметрами. Сделано для минимизации трафика и повышения быстродействия сервака.

И что, сервер будет помнить состояние "подготовленного sql запроса" между "http запросами" ?

BFG-9000 · 27.03.2009

sergeime сказав(ла):
И что, сервер будет помнить состояние "подготовленного sql запроса" между "http запросами" ?

А что, уже введена уголовная ответственность за использование пула коннектов?

sergeime · 27.03.2009

BFG-9000 сказав(ла):
А что, уже введена уголовная ответственность за использование пула коннектов?

Ты разницу между пулом коннектов и подготовленным запросом видишь?

fatalex · 27.03.2009

BFG-9000 сказав(ла):
А что, уже введена уголовная ответственность за использование пула коннектов?

sergeime сказав(ла):
Ты разницу между пулом коннектов и подготовленным запросом видишь?

стреляться на 20 (двадцати) метрах .. и нии... гкхм ... не волнует ...

BFG-9000 · 28.03.2009

sergeime сказав(ла):
Ты разницу между пулом коннектов и подготовленным запросом видишь?

Если набивая пул коннектов, ты кроме собсно коннекта еще и запрос подготовишь - то я действительно разницы не вижу

Надо кагбе ширее мыслить, а не так шо в пуле коннектов запросы обязательно тока в состоянии "коннектид"

sergeime · 28.03.2009

BFG-9000 сказав(ла):
Если набивая пул коннектов, ты кроме собсно коннекта еще и запрос подготовишь - то я действительно разницы не вижу
Надо кагбе ширее мыслить, а не так шо в пуле коннектов запросы обязательно тока в состоянии "коннектид"

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

BFG-9000 · 28.03.2009

sergeime сказав(ла):
Из пула коннект надо "чистый" получать, без всяких там команд и курсоров зависших.

Интересно, а кто сказал, что надо получать чистый? :confused:

Это такая 11-я заповедь?

Если мне будет нужно для приложения иметь пул из 100 запросов в подготовленном состоянии - почему бы мне не иметь такой пул?

Представь, что у тебя сервер приложений занимается выборкой из БД, только выборкой, причем однотипной. Ну например поиск по телефонному справочнику, где по закону разрешено только по ФИО+адрес искать. Менять ничего ненадо, запросы все одинаковые, зато нагрузка велика и требования к времени ответа жесткие. Что мешает заранее сделать 100 подготовленных запросов?

sergeime · 28.03.2009

BFG-9000 сказав(ла):
Интересно, а кто сказал, что надо получать чистый? Это такая 11-я заповедь?
Если мне будет нужно для приложения иметь пул из 100 запросов в подготовленном состоянии - почему бы мне не иметь такой пул?
Представь, что у тебя сервер приложений занимается выборкой из БД, только выборкой, причем однотипной. Ну например поиск по телефонному справочнику, где по закону разрешено только по ФИО+адрес искать. Менять ничего ненадо, запросы все одинаковые, зато нагрузка велика и требования к времени ответа жесткие. Что мешает заранее сделать 100 подготовленных запросов?

Ничто не мешает. Только это уже пул запросов, а не коннектов - не так ли?

dr. Unk · 28.03.2009

sergeime сказав(ла):
Ничто не мешает. Только это уже пул запросов, а не коннектов - не так ли?

Это уже контейрнерная перевозка.. тьфу.. хранимка..

dr. Unk · 28.03.2009

BFG-9000 сказав(ла):
Интересно, а кто сказал, что надо получать чистый? Это такая 11-я заповедь?

Это такое определение....
К чему приведет ваше решение.. я не буду обсуждать потому как флуд о жестконагруженных и мегаоптимизированных серверах богопротивен...
ЗЫ
назовем писю - ****** и будем лечить от триппера(С)

BFG-9000 · 28.03.2009

Собсно изначально вопрос был "будет ли сервер помнить состояние подготовленного запроса между ХТТП-звпросами". Я показал решение, при котором будет.
Еще могу привести варианты - например запрос будет лежать внутри сессионого бина в джаве

sergeime · 28.03.2009

BFG-9000 сказав(ла):
Собсно изначально вопрос был "будет ли сервер помнить состояние подготовленного запроса между ХТТП-звпросами". Я показал решение, при котором будет.
Еще могу привести варианты - например запрос будет лежать внутри сессионого бина в джаве

Ну я видел когда коннект и команды в ASP сессию складывали. За такое полагается немедленная кастрация через анальное отверстие. Возможно не понятно к чему это может привести, отвечаю - ADO коннект и команда это singlethreaded объекты, т.е. она заточены на тот поток в котором созданы. А IIS может выполнять запрос в любом потоке, то есть произойдет никому не нужный маршалинг, да и тот будет ждать пока поток в котором коннект был создан не освободится (он возможно занят другим http запросом). Короче ****ец серверу прийдет.
C пулом коннектов будет все ОК, потому что реально создается новый _объект_ коннекта на основе запуленного и открытого хэндла к серверу. То есть это дешево.

BFG-9000 · 28.03.2009

dr. Unk сказав(ла):
Это такое определение....

Это наверное придуманное тобой определение. Потому что НИКОГДА ты не будешь получать "чистый" коннект из пула (кроме первого раза).

dr. Unk сказав(ла):
К чему приведет ваше решение.. я не буду обсуждать потому как флуд о жестконагруженных и мегаоптимизированных серверах богопротивен..

Я понимаю. Вершиной твоей программистской мысли наверняка явлется сортировка методом пузырька. Все что выше этого - это уже "блажь заморская, антихристова лжа" (с) Довлатов. Ничего, как я уже тут писал, такие как ты нужны для стимулирования технического прогресса в области наращивания вычислительных мощностей

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

dr. Unk · 28.03.2009

BFG-9000 сказав(ла):
Это наверное придуманное тобой определение. Потому что НИКОГДА ты не будешь получать "чистый" коннект из пула (кроме первого раза).

Подмена понятий...

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

BFG-9000 · 28.03.2009

sergeime сказав(ла):
Ну я видел когда коннект и команды в ASP сессию складывали. За такое полагается немедленная кастрация через анальное отверстие. Возможно не понятно к чему это может привести, отвечаю - ADO коннект и команда это singlethreaded объекты, т.е. она заточены на тот поток в котором созданы. А IIS может выполнять запрос в любом потоке, то есть произойдет никому не нужный маршалинг, да и тот будет ждать пока поток в котором коннект был создан не освободится (он возможно занят другим http запросом). Короче ****ец серверу прийдет.
C пулом коннектов будет все ОК, потому что реально создается новый _объект_ коннекта на основе запуленного и открытого хэндла к серверу. То есть это дешево.

Я вобще-то высказывался иначально за мускуль, если ты уже забыл.
Притыренность очередной замшелой революции от МС от меня как-то далека

Давай еще работу с сокетами в MFC вспомним и скажем, что низзя создавать пул ТЦП-ИП соединений, потому что сокет в MFC заточен на тред в котором создан, а чтобы его отдать в другой тред надо выполнить деттач и аттач

Ты рассказал про частные проблемы, возникающие при неудачном архитектурном решении в определенной среде. В твоем примере если возникнет нужда и будет вычислительно оправданно - можно например крутить запросы каждый в своем потоке (т.е. в пуле будут лежать 100 потоков каждый со своим запросом внутри) и отдавать/получать данные через любой механизм межпоточного обмена. Навскидку пример - очень сложный сильно параметризованный запрос. Или например есть слабый сервер БД, который надо холить и лелеять и пусть будет вычислительно неоправданно применять предложенную мной архитектуру на сервере приложений - но зато будет приятно серверу БД.

sergeime · 29.03.2009

BFG-9000 сказав(ла):
Я вобще-то высказывался иначально за мускуль, если ты уже забыл.
Притыренность очередной замшелой революции от МС от меня как-то далека Давай еще работу с сокетами в MFC вспомним и скажем, что низзя создавать пул ТЦП-ИП соединений, потому что сокет в MFC заточен на тред в котором создан, а чтобы его отдать в другой тред надо выполнить деттач и аттач

Это было связано с обработкой событий от сокетов (они делались через очередь сообщений - потому заточенность на потоке). Ну MFC и не был предназначен для серверных компонент.
Сам хендл сокета, в тоже время - можно было использовать где угодно, это чисто Win32.

Ты рассказал про частные проблемы, возникающие при неудачном архитектурном решении в определенной среде. В твоем примере если возникнет нужда и будет вычислительно оправданно - можно например крутить запросы каждый в своем потоке (т.е. в пуле будут лежать 100 потоков каждый со своим запросом внутри) и отдавать/получать данные через любой механизм межпоточного обмена. Навскидку пример - очень сложный сильно параметризованный запрос. Или например есть слабый сервер БД, который надо холить и лелеять и пусть будет вычислительно неоправданно применять предложенную мной архитектуру на сервере приложений - но зато будет приятно серверу БД.

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

SQL Server - как "залить" изображения?

Привіт!