dev.net.ua

Как, используя DataSet и DataAdapter, после того как я сам добавляю в DataSet строку без первичного ключа (и возможно некоторых других полей которые генерируются в базе автоматически), обновляю DB используя метод Update адаптера, получить эту строку с остальными значениями? При этом не используя дополнительные вызовы к базе и желательно не делая пакетного запроса в Insert команде адаптера типа

             @"INSERT INTO T_LAB_ITEM(lab_item_group_id, name_id, name_description) VALUES (@lab_item_group_id, @name_id, @name_description);
 SELECT lab_item_id, lab_item_group_id, name_id, name_description, unitsFROM T_LAB_ITEM WHERE (lab_item_id = @@IDENTITY)";

у меня нетипизированный  DataSet!

---

С уважением, Вячеслав

Вопрос по тому, как выбрать автогенерируемые поля из базы или как их получить в DataSet'е?

Если первое и СУБД SQL Server 2005, посмотри в сторону OUTPUT clause для INSERT/UPDATE/DELETE запросов.

Ссылка в BOL: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/41b9962c-0c71-4227-80a0-08fdc19f5fe4.htm

Вот неплохой пример: http://blogs.msdn.com/sqltips/archive/2005/06/13/output_clause.aspx

kosinsky:

Вопрос по тому, как выбрать автогенерируемые поля из базы или как их получить в DataSet'е?

Если первое и СУБД SQL Server 2005, посмотри в сторону OUTPUT clause для INSERT/UPDATE/DELETE запросов.

Ссылка в BOL: ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/41b9962c-0c71-4227-80a0-08fdc19f5fe4.htm

Вот неплохой пример: http://blogs.msdn.com/sqltips/archive/2005/06/13/output_clause.aspx

К сожалению, SQL Server 2000.

---

С уважением, Вячеслав

Тогда можно написать тригер, который будет делать SELECT * from Inserted и при помощи опции disallow results from triggers, разрешить ему возвращать ResultSet в вызывающую сессию.

Недостаток, что эта опция действует на весь сервер.

kosinsky:

Тогда можно написать тригер, который будет делать SELECT * from Inserted и при помощи опции disallow results from triggers, разрешить ему возвращать ResultSet в вызывающую сессию.

Недостаток, что эта опция действует на весь сервер.

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

---

С уважением, Вячеслав

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

 

kosinsky:

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

 

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

---

С уважением, Вячеслав

1.  Производительность
1. Больше данных передаеться по сети
2. Больше вероятность перекопиляции запроса, она почти 100%
2. Нужно иметь права на таблицы куда будет делаться обновление. А в ситуации с sp, можно построить, так называемую row level security, используя ownership chain (2000 и 2005) или EXECUTE AS (2005)
3. Качество кода
1. Если нужно вызвать во многих местах, то будет дублирование
2. Больше вероятность написать запрос поддерженный SQL Injection, т.к. можно полениться и гдето сделать конкатенацию вместо параметра

 

 

1.  Производительность
1. Больше данных передаеться по сети

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

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

Это скорее зависит от программиста, чем особенность батча, хотя, конечно если их много, но у меня не более 5.

 

---

С уважением, Вячеслав

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

Я про размер запроса который отсылаеться.

А вдобавок к этому надо заново открывать соединение с базой для отдельного вызова хранимой процедуры, не будут это такие же расходы что и на разбор батча?

Зачем заново отсылать соединение, кол-во открытий закрытий соединений и для батчей и для SP одинаково.

Это скорее зависит от программиста, чем особенность батча, хотя, конечно если их много, но у меня не более 5.

Человеку свойственно ошибаться, а програмисту писать код за который потом стыдно. . Вы в себе уверенны на 100%? А в других учасниках проекта? Я нет, даже в себе.

По этому предпочитаю пользоваться (заставлять членов своей команды) sp, и быть уверенным, что даже случайно не устрою SQL Injection. Проще, автоматически проверить, что все обращения к БД идут через sp или view, чем выполнять ревью кода на SQL Injection.

 

kosinsky:

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

Я про размер запроса который отсылаеться.

А вдобавок к этому надо заново открывать соединение с базой для отдельного вызова хранимой процедуры, не будут это такие же расходы что и на разбор батча?

Зачем заново отсылать соединение, кол-во открытий закрытий соединений и для батчей и для SP одинаково.

Это скорее зависит от программиста, чем особенность батча, хотя, конечно если их много, но у меня не более 5.

Человеку свойственно ошибаться, а програмисту писать код за который потом стыдно. . Вы в себе уверенны на 100%? А в других учасниках проекта? Я нет, даже в себе.

По этому предпочитаю пользоваться (заставлять членов своей команды) sp, и быть уверенным, что даже случайно не устрою SQL Injection. Проще, автоматически проверить, что все обращения к БД идут через sp или view, чем выполнять ревью кода на SQL Injection.

На самом деле обращения идут с использованием sp и без техники где возможна SQL Injection, а про свойственно ошибаться это понятно.

---

С уважением, Вячеслав