Как выполнить SqlCommand для инсерт или апдейт?

Winnipuh
Дата: 12.05.2006 15:41:07
Суть:

перед тем как сделать инсерт или апдейт формирую строку просто:
strInsert = "insert into dbo.barcode1(rno,sno,bcode,bname,wt,noofpack,ptype,rno1) values({0},{1},'{2}'....";

Проблема в том, что строки бывают типа такого "O'Connor" и естественно ошибка.

Как обойти?
BodyaComUa
Дата: 12.05.2006 15:49:35
Используйте параметры. Значения, которые вставляете, передавайте параметрами.
values(?,?,?...
lustig
Дата: 12.05.2006 19:08:17
2BodyaComUa: ИМХО параметры стоит юзать когда без них никак (блобы, например).
2Winnipuh: Так надо такие строки преобразовывать O'Connor -> O''Connor (две одинарных кавычки). Я использую самописную ф-цию обертку, условно PrepareStringForQuery, она, кстати, добавляет начальную и конечную кавычки, чтобы не писать '{2}', а {2}, борется с одинарной кавычкой (добавляет еще одну), отстреливает табы, энтеры и любую другую необходимую обработку. Если надо что-то добавить - все в одном месте.
BodyaComUa
Дата: 12.05.2006 19:23:53
2lustig
Тогда такая функция должна проверять наличие таких слов, как DROP, DELETE и т.д. и т.п.
Изменением одной кавычки на двойные кавычки - меняет значение.
Использование параметров - более универсальный способ.
Хотя раньше сам использовал динамически сформированные запросы.
lustig
Дата: 15.05.2006 09:38:31
2BodyaComUa:
BodyaComUa
Тогда такая функция должна проверять наличие таких слов, как DROP, DELETE и т.д. и т.п.

А вот это не понял. Это ж зачем она должна такое проверять) Я с перепугу проверил, так DROP прокатил, пожалуй все остальные ключевые слова скуля проверять не буду...
Если я передаю строку (в одинарных кавычках), то проверять нужно только на такую же кавычку в строке, чтобы сервер не воспринял ее как символ конца строки и ВСЕ. Про табы и ентеры я написал для примера, в моих задачах, например, это недопустимые символы. Используя такую функцию, я могу реализовать нужную мне обработку строк перед вставкой в базу, ну и как плюс отказаться от параметров. А это плюс тоже немалый.

BodyaComUa
Хотя раньше сам использовал динамически сформированные запросы.

А я как раз наоборот, начинал (еще в Delphi) с параметров. Обычно эволюция идет именно по такому пути, т.к. параметры для новичка легче.
BodyaComUa
Дата: 15.05.2006 10:31:43
[url=http://]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconsecureadonetcodingguidelines.asp[/url]

Рекомендую прочитать.
Там банальный пример:
string selectString = "SELECT * FROM Customers WHERE CustomerID = " + custID;
custID = "1;DROP TABLE Customers"
BodyaComUa
Дата: 15.05.2006 10:37:53
Новичком себя не считаю:-) Все же 3 года пишу уже на C#.
При использовании параметров также не приходится думать о форматировании разных типов (особенно при работе с датами). Для всех типов подход одинаковый. Имя параметра, тип, значение и т.д.
winsky!
Дата: 15.05.2006 11:41:24
lustig
2BodyaComUa:
BodyaComUa
Тогда такая функция должна проверять наличие таких слов, как DROP, DELETE и т.д. и т.п.

А вот это не понял. Это ж зачем она должна такое проверять) Я с перепугу проверил, так DROP прокатил, пожалуй все остальные ключевые слова скуля проверять не буду...
Если я передаю строку (в одинарных кавычках), то проверять нужно только на такую же кавычку в строке, чтобы сервер не воспринял ее как символ конца строки и ВСЕ. Про табы и ентеры я написал для примера, в моих задачах, например, это недопустимые символы. Используя такую функцию, я могу реализовать нужную мне обработку строк перед вставкой в базу, ну и как плюс отказаться от параметров. А это плюс тоже немалый.

BodyaComUa
Хотя раньше сам использовал динамически сформированные запросы.

А я как раз наоборот, начинал (еще в Delphi) с параметров. Обычно эволюция идет именно по такому пути, т.к. параметры для новичка легче.

приведите аргументы против использования параметров
lustig
Дата: 16.05.2006 13:54:56
BodyaComUa
Новичком себя не считаю:-)

А я это и не утверждал. Я сказал, что для новичка - легче работать с параметрами. Пока разберешься как строку формировать, какие специальные символы, dateformat и т.д., то может охота учиться пропасть. А параметры: написал value = ... и ни чего знать (понимать) не надо.

BodyaComUa
Рекомендую прочитать.
Там банальный пример:
string selectString = "SELECT * FROM Customers WHERE CustomerID = " + custID;
custID = "1;DROP TABLE Customers"

Пример, действительно, банальный.

Во-первых, если CustomerID - строка, то где кавычки, а если их поставить, то опять ничего военного. Если CustomerID - число, то что это за NumEdit такой, в который можно ввести "1;DROP TABLE Customers"?

Во-вторых, чтобы DROP выполнять надо нехилые права иметь:) Если всю работу с данными вести искл. через ХП (а так и надо), то у юзера в принципе ни на что кроме выполнения определенного круга ХП прав нет.

В-третьих, для win приложений пример вообще надуманый. Если я настолько умный, что про DROP знаю, и у меня есть на него права (мы же исходим из этого:)), то я поставлю себе QA или за 5 мин. сваяю прогу выполняющую произвольные запросы и из нее запущу этот же DROP. Разве что от пользователя скрыть реальный логин.
lustig
Дата: 16.05.2006 14:18:34
winsky!
приведите аргументы против использования параметров

Ну понятно, что ничего, что заставит всех бросить параметры я не приведу:) Напишу лишь:
- Удобно тестировать. Я вижу конечный запрос, который пойдет к базе еще до того, как это фактически случится. Понятно что есть профайлеры и т.д. и т.п.. Но согласитесь, это из пушки по воробьям. Так скопировал запрос из отладчика, вставил в QA...
- Ипользование параметров обязывает к некому синтаксису зависящему от объектов доступа к данным. Может, кому сегодня покажется смешным, но пример:
Delphi переход с BDE на ADO. Кто параметры не юзал, тот поменял TDatabase на TAdoConnection и TQuery на TADOQuery (как правило в одном месте на модуле данных). А кто юзал... Синтаксис немного другой у параметров стал. Так и здесь может быть. Есть же в vs2005 и DataGrid и DataGridView. Может на смену ADO.NET тоже что-то прийдет. Аналог коннекшна и пр., думаю не зыблем, а вот параметры - не знаю.
- Чисто формально - медленнее:) (не надо закидывать камнями).
- Лишняя прослойка, "черный ящик" и в том же духе...

Еще раз повторю это ИМХО...