Visual Basic, .NET, ASP, VBScript
Новости | Примеры | Библиотека кодов | НеЧаВо | VBA | Справочник по VB | Справочник по WinAPI | ActiveX контролы | Статьи по VB | Мастерская разработчика | Форум VBNet | Яndex bar! | Голосование | Полезные программы | Магазин VBNet | Рассылка | Конкурсы | Юмор | Чат | Реклама на VBNet | Автора! | Ссылки | Бета-тестирование | Послать пример на сайт
 

   
   
     

Форум - Работа с данными

Страница: 1 |

 

  Вопрос: Прямой запрос в БД посредством ADO .NET Добавлено: 25.06.10 13:44  

Автор вопроса:  Алексей
Добрый день.
Недавно "пересел" с VB6 на VB .NET 2008. Вроде разобрался, но в одном возникла проблема: как задать прямой запрос в БД?
БД - Access. В VB6 было все просто^

dim conn as new adodb.connection
conn.open "Строка соединения с базой"
conn.Execute("SQL запрос")

В итоге данной операцией возможно прямое создание таблиц в БД (и много чего ещё)

Как такую же констукцию организовать в VB 2008? Перерыл массу литературы но ответа так и не нашел. Может кто сталкивался? или подобное невозможно?

Ответить

  Ответы Всего ответов: 6  

Номер ответа: 1
Автор ответа:
 s12



Вопросов: 24
Ответов: 363
  Профиль | | #1 Добавлено: 25.06.10 14:39
Есть объект OleDbCommand которому при инициализации передается строка SQL запроса. А у этого объекта есть метод ExecuteNonQuery.
По моему так...
Пример на c#, oConn - объект connection
  1.  
  2. OleDbCommand cmd; string SQL = "Твой запрос";
  3.             if (SQL.Length != 0) cmd = new OleDbCommand(SQL);
  4.             try
  5.             {
  6.                 cmd.Connection = Connection.oConn;
  7.                 cmd.ExecuteNonQuery();
  8.             }
  9.             catch (Exception e) { MessageBox.Show("Ошибка выполнения запроса. \n" + e.Message.ToString(), "Ошибка!", MessageBoxButtons.OK, MessageBoxIcon.Information); }

Ответить

Номер ответа: 2
Автор ответа:
 Алексей



Вопросов: 1
Ответов: 2
  Профиль | | #2 Добавлено: 25.06.10 15:52
Большое спасибо. Перебил данный код под VB - все заработало.

Ответить

Номер ответа: 3
Автор ответа:
 Artyom



Разработчик

Вопросов: 130
Ответов: 6602
  Профиль | | #3 Добавлено: 26.06.10 19:48
Выполнение обычных запросов (ExecuteScalar, ExecuteNonQuery) делается так
  1. using (SqlConnection connection = new SqlConnection(connectionString))
  2. {
  3.     connection.Open();
  4.  
  5.     using (SqlCommand command = new SqlCommand(sqlQuery, connection))
  6.     {
  7.         command.ExecuteNonQuery();
  8.     }
  9. }


Вот для запросов которые возвращают набор данных
  1. using (SqlConnection connection = new SqlConnection(connectionString))
  2. {
  3.     connection.Open();
  4.  
  5.     using (SqlCommand command = new SqlCommand(sqlQuery, connection))
  6.     {
  7.         using (SqlDataReader reader = command.ExecuteReader())
  8.         {
  9.             while (reader.Read())
  10.             {
  11.                 // обрабатываем запись
  12.             }
  13.         }
  14.     }
  15. }


Для Oledb делается аналогично, только другие классы. Здесь все ресурсы корректно освобождаются, даже в случае ошибок (чего не выполняется в коде s12)

Ответить

Номер ответа: 4
Автор ответа:
 s12



Вопросов: 24
Ответов: 363
  Профиль | | #4 Добавлено: 26.06.10 20:55
Зато код "в случае ошибок" не грохнется (чего не выполняется в коде Steel Brand'а)
:)

Ответить

Номер ответа: 5
Автор ответа:
 Artyom



Разработчик

Вопросов: 130
Ответов: 6602
  Профиль | | #5 Добавлено: 27.06.10 09:23
Обработка ошибок не обязательно должна быть. А если должна, то не обязательно именно в этом месте.

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

Если же исключение не ожидается, или если неизвестно как реагировать на исключения, то в специальном обработчике нет необходимости. Максимум что можно сделать - запротоколировать исключение и сообщить пользователю о том что произошла ошибка (а это как правило делается где-нибудь в начале стека).

  1. catch (Exception e) { MessageBox.Show("Ошибка выполнения запроса. \n"  + e.Message.ToString(), "Ошибка!", MessageBoxButtons.OK, MessageBoxIcon.Information); }

Это не обрабокта ошибок, а заглушка. В VB6 вместо этого было
  1. On Error Resume Next

Перешли на VB .NET, а продолжаем писать в стиле VB6.

Не понятно какое исключение ты ожидаешь получить и не понятно как тебе нужно на него реагировать. Поэтому просто показываем MsgBox тому кто может вообще ничего в нем не понимать и даем работать вызывающему коду как ни в чем не бывало (при том что это может привести к разсогласованию данных, нарушению целостности БД, переводу приложения в сбойное состояние.


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

Есть код, который сохраняет в БД новый заказ и отправляет оповещение менеджеру по E-mail. При отправке сообщения что-то может пойти не так (SMTP сервер упал, поменяли настрйоки доступа к SMTP серверу). Хотя это и маловероятно, так как SMTP сервер обычно контролируется владельцем сайта, эта операция не является важной. Даже если отправка не удалась, заказ все равно сохранен в БД, и менеджер его увидит когда зайдет на сайт в раздел заказов. Для отправки E-mail можно поставить простую заглушку, которая сохраняет исключение в журнал и продолжает работу кода - никакого разсогласования не будет.

Если же при вставке новой записи в базу данных приложения произошла ошибка, то это во-первых, неожидаемо. Потому что наиболее вероятные причины - упал сервер СУБД, упала сеть до сервера СУБД, поврежден диск на котором находится БД, изменилась схема данных, вставляется запись с дублирующимся ключем, INSERT запрос с обишкой.
Во-вторых, непонятно что делать. Потому что какая бы причина не была, продолжать работу скорее всего нет смысла.
Если СУБД лежит, то приложение работать не может пока ее не поднимут.
Если поврежден диск, приложение не будет работать пока не заменят диск и не восстановят базу из резервной копии
Если изменилась схема данных, то нужно модифицировать код приложения чтоб он мог работать с новой схемой.
Если вставляется запись с дублирующимся ключем, нужно искать ошибку в коде. Возможно по ошибке одна и та же запись вставляется 2 раза, или один и тот же ключ берется для двух записей (вполне возможно в многопоточных приложениях с ошибками синхронизации потоков).
Если запрос с ошибкой, то нужно исправлять запрос.

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

Еще один пример - работа с транзакциями. При этом возможны ошибки. При завершении транзакции возникла несогалсованность данных, или дедлок, такие ситуации в принципе ожидаемы, и даже если корректно на них отреагирвоать нельзя, пользователю можно описать суть проблемы и дать возможность повторно выполнить операцию. Здесь впрочем ловится не Exception, а уже более конкретное исключение.

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


Вобщем обеспечить правильную обработку исключений на самом деле намного сложнее чем правильное и своевременное освобождение 3-х критических объектов.

Ответить

Номер ответа: 6
Автор ответа:
 s12



Вопросов: 24
Ответов: 363
  Профиль | | #6 Добавлено: 27.06.10 20:31
:)
Улыбнуло.
Вопрос: Прямой запрос в БД посредством ADO .NET

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

Ответить

Страница: 1 |

Поиск по форуму



© Copyright 2002-2011 VBNet.RU | Пишите нам