Собственно говоря, проблема со вставкой данных (Insert). Есть необходимость самому прописать обновление данных, т.к. то, что отображается в гриде - результат объединения нескольких таблиц + некоторые проверки непосредственно в селекте... и т.д. Короче, я посчитал, что проще по примеру VS2003, а возможно и VS2005 в пакет инструкций добавлять Select (SelectCommand.CommandText), в котором ID = identity. Сохранение производится стандартно: 


Сохранение производится нормально. Однако, пока не удается полученную из БД строку подставить вместо обрабатываемой. 
Пробовал так (CmdIns - сохраненный объект SqlCommand для вставки данных, cnn - SqlConnection, tbl - обновляемая таблица):


А значение ID обязательно надо иметь для последущей работе клиента с данными... 

Добавлено через 5 минут и 26 секунд
Может после заполнения таблицы удалять Primary Key?

Papirus, 
Честно говория ничего не понял. 

Куда нужно подставить строку из БД?
Если


Так очисти DataGrigView  и заполни снова, но уже после обновления БД.

Значит такой корявый у меня язык. Постараюсь исправиться.

Источником данных для грида является таблица предварительно созданная (Dim tbl as New DataTable) и заполненная с помощью датаридера. 
Пользователь внес свои изменения. Что-то добавил, что-то удалил, а что-то модифицировал. Щелкнул кнопку "Сохранить". Процедуру сохранения данных смотри в 1-м посте. В БД "улетает" штук 5 значений, в основном ID из других таблиц, а в гриде должно отобразиться штук 15. Если  сформировать объект комманд вида 

В результате получим из БД строку с нужными значениями, в т.ч. и сгенерированным ID (строку получаем можете не сумлеваться). Таким образом, задача сводится к тому, чтобы в таблице - источнике данных для грида отобразились все эти значения. Один путь, как я уже говорил, не срабатывает из-за того, что поле ID этой самой таблицы ReadOnly и rw.ItemsArray = tb.Rows(0).ItemsArray выдает ошибку. А второй путь tbl.Merge(tb) приводит к тому, что записей в копии таблицы на клиенте становится 2 - одна исходная, которая обрабатывалась, заполненная частично, и только нужными числовыми значениями, а вторая - полученная из БД. Во втором случае вопрос стоит куда девать эту первую уже не нужную запись? rw.Delete() останавливает цикл обработки по ошибке... что-то там с Enumerator' ом коллекции.

Т.е. очистить таблицу и заполнить заново? И так при каждом сохранении?  

Papirus, 
SQL- команда INSERT INTO добавляет строку в таблицу БД.
А вот команда SELECT позволяет получить данные из БД.
Это я к 





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


И потом зачем DataReader, а не  DataAdapter?

Напиши SELECT команду к БД, выполни ее заполни таблицу в ДатаСет и отобрази ее в гриде.
Юзер внес какие-то изменения( я так понимаю новые данные раз надо добавлять строку в БД), ты сохранил это в БД. (в твоем случае INSERT команда).
Далее тебе нужно видеть что же там получилось?(так как БД генерит ID) Для этого нужно обновить таблицу в ДатаСет, а для этого по новой выполнить SELECT команду к БД. Перед этим очистить таблицу в ДатаСет.
Все. ADO.NET   


Это сообщение отредактировал(а) thomas - 2.7.2007, 12:06

Этого-то как раз и хочется избежать. Заполнять каждый раз при сохранении одной-двух-трех записей всю таблицу (пока 7-8 тысяч строк), имхо не производительно, да и после сохранения каждой записи мне нужен ID для обновления связанных таблиц.
При этом датасетов у меня нет и каскады затевать тоже как-то "влом".

Papirus, 
У меня только один вопрос

А нужны ли все они юзверю, а? Сколько строк он может увидеть на экране? Я думаю что, стандарт сейчас 1024х768, а не как у меня 1200х1600 (20" и повернут на 90). Так что много он не увидит, да и я тоже.

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

выполни метод ExecuteScalar() и получишь свой ID.


Очень интересно ...    

Это справочник товаров и их составных частей. Пользователь должен видеть их все. Он так хочет. Списком. Хотя и предусмотрена группировка и отображение в виде дерева с подгрузкой списка по типам.

Это-то как раз и была суть моего вопроса (см. мой пост от 02.07.2007 11:27). Если, как я писал выше, CommandText включает инструкцию Select 

то после выполнения InsertCommand.ExecuteReader получаем назад нужную строку со всеми потрохами... В том числе и со сгенерированным базой ID. И потом этот ID мне нужен не просто в виде переменной, а как значение соответствующего свойства DataRow, чтобы пользователь мог продолжить добавление/удаление/редактирование комплектующих (т.е. данных в подчиненных таблицах) и самой этой записи...

"Это же БУБЛЬ-ГУМ!!!!" (с)    Это ж VS2005 - здесь источником данных м.б. отдельная DataTable, не связанная с датасетом. И при этом не надо тянуть xml-структуру датасета, что бывает иногда тормознуто.

ПыСы. Проблемку я вроде решил. Если кому интересно могу сообщить как.

Papirus, 
Вы меня конечно извините, но

Это БСК.


Читаем здесь.


Читаем здесь.

Архетиктура ADO.NET.

DataSet class.

DataTable class.


Интересно, откуда Вы тянете структуру ДатаСет, из Базы Данных?     Ню-ню.   

ЗЫ "Бред Сивой Кобылы" = любимая призказка моего преподавателя по специальности в моем первом высшем учебном заведении.

ЗЫ ЗЫ 
 Я рад за Вас.   

Это сообщение отредактировал(а) thomas - 4.7.2007, 08:29

Ничего не БСК. Источником данных действительно может быть DataTable. Причем в случае использования одной таблицы даже рекомендуется использовать именно DataTable, а не DataSet.

Idsa, 
А где находиться эта DataTable, которая является источником данных? 

В оперативной памяти 

Смотрим в MSDN справку по свойству DataGridView.DataSource:


thomas, обрати внимание на пункт 2.

Idsa, 
то что таблица в памяти это не вопрос.
Я имею ввиду, то что DataTable после ее создания помещается в DataSet. 

А в приведенной цитате пункт 2 я понимаю так
ДГВ поддерживает следующие интерфейсы: IListSource интерфейс такой как (such as) DataTable и DataSet классы.

И так понятно что ДГВ связан с определенной таблицей в ДатаСет.

Из всего что я на данный момент прочитал в msdn и в книгах по ADO.NET. а так же чего нам рассказывал препод в вышке

Существуют: 
Источник данных(БД, файл Excel, xml, текстовый файл) + различные типы провайдеров данных + датаадартеры + датасет
А в датасет может быть одна или много таблиц или 0 таблиц. 

Архитектура ADO.NET

Это сообщение отредактировал(а) thomas - 4.7.2007, 16:56

thomas, вот ты пишешь:

Действительно, DataSet не что иное, как обертка над DataTable. Но если нам не нужны навороты DataSet, почему бы не сэкономить память и не повысить производительность, использовав непосредственно DataTable?!

Далее ты пишешь:

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

Если мне так и не удалось тебя убедить, создай Windows-приложение, создай объект DataTable, затем выполни dataAdapter.Fill(dataTable) и прикрути к DataGridView: DataGridView.DataSource = dataTable.

Можно и без датаадаптера.   




В VS2003 без этого действительно никак, а в 2005 - запросто.
Рекомендую к прочтению: С.Малик "Microsoft ADO.NET 2.0 для профессионалов"

"Забудьте чему Вас учили в школе, как кошмарный сон!!!" (с)