Работа с SqlCommandBuilder

Здравствуйте, уважаемое сообщество!
Хочу спросить о применении SqlCommandBuilder. Проблема заключается в том, что после обновления таблицы на сервере с помощью комманд генерированных SqlCommand Builder в приложении не обновляются автоинкрементные поля таблицы, следовательно если обновлять таблицу, а затем например ее дочернюю таблицу, то машина ругатся - нарушено ограничение(естественно записи родительской таблицы зафиксированы на сервере, а в локальной базе в датасете стоять прежние поля). SqlCommandBuilder вообще штука капризная как о ней говорят. Ещё хочу спросить попутно - если требуется в различных формах создавать SqlDataAdapter в ручную, как соответственно назначать им соединение, где прописать это глобальное соединение. Вроде логично сделать свой класс, который содержит и параметры соединения и методы установления соединения со всеми обработками ошибок и т.д., а затем назначать его SqlCommand, SqlAdapter и т.д. Многие люди, даже не новички в программировании, но новички в ADO.NET, не понимают логику работы с соединениями. Что делать в дизайн тайме, если логично иметь одно соединение, а не плодитьих на каждой форме!
Спасибо!

0

Roman83, в дизайн тайме я бы вам вообще не советовал делать такие вещи. Как вы уже сказали - лучше написать свой класс, где будет и подключение и отключение, и остальные манипуляции с СУБД.
P.S. В чем конкретно вопрос?

0

Опишу подробнее!!! Я написал такой класс, помимо работы с соединением он может выполнять комманды, возвратить набор данных по переданной в качестве параметра хранимой процедуре или запросу(ну вообще что потребуется, то там реализовывать и надо как я понимаю). Получил набор данных содержащий две таблицы. Теперь мне надо с ним работать, я начинаю заполнять локальные данные вызовом NewRow() и т.д. Пока проблема возникла с отложенными изменениями, как сохранить этот набор - решение при таком подходе должно быть таковым - раз есть класс надо через него, но у меня нет DataAdapter вне класса, я могу объявить его в классе и реализовать подпрограмму сохранения передавая ему ту или иную таблицу или весь датасет, но при этом адаптер надо настраивать в ручную, я пытаюсь использовать SQLCommandBuilder он добавляет данные в базу, но не обновляет записи в локальных таблицах, вследствии чего на месте автоинкрементных полей остаются -1,-2 и т.д. - а это не есть хорошо.
Как вы уже догадались,я новичок в этом деле - как работать с таким классом, реализующим соединение не могу додуматься, это же все адаптеры вручную настраивать или что... Может у Вас там код такого класса и примеры использования есть или ссылки какие-нибудь? gjltkbntcm. Мне не в коммерческих целях

0

Roman83,
Ну здесь вариантов куча...
1. Если вы так хотите использовать SqlCommandBuilder - используйте его. Для обновления данных в локальных таблицах - подтяните заново просто эти таблицы и все. Как то так...
2. Можно просто после каждого изменения в данных вызвать, например, соответсвующую хранимку для таблички. (Добавил строку - вызвал хранимку InsertIntoTable1)

все это конечно реализовывается в вашем классе...

0

Сейчас у меня все через хранимые поцедуры и делается - добавил запись - изменил в базе, а конструктор класса принимает имя хранимой процедуры - только я вот думаю это корректно или нет, изменил в локольных таблицах - сразу дергать сервер, вроде азбука ADO.NET советует с отсоединенными данными больше работать. Это я должен может вставить хранимой процедурой а затем опять методом Fill все выбирать - я не знаю может так и надо, но на первый взгляд это не хорошо гонять от сервера данные. Сейчас я добавляю в локальную таблицу запись и вызываю хранимку т.е. иду параллельно изменяя локальные записи и записи на сервере, на первый взгляд такая ручная синхронизация не очень нравиться. И ещё вопрос, почему когда в дизайн тайме адаптер далаешь - он обновляет мои автоинкременты, а если вручную - то нет(как Вы советуете надо очистить таблицу и снова ее наполнить методом Fill)?

0

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

0

Благодарю за ответ. Скажите:
1) На Ваш взгляд хранимые процедуры или передача через адаптер лучше (я думаю хранимые процедуры - на то они и ХРАНИМЫЕ);
2) Нормальный вариант - согласование данных: заполнение из текстбоксов и т.д. локальной таблицы и тут же вызов хранимки с параметрами из текстбоксов(если вставка, то еще возврат инкрементированного поля и присвоение ключу в локальной таблицы), так вроде и к серверу по каждой записи обращаешся и Fill не дергаешь;

0

1. Хранимые чем хороши - они не вшиты в код приложения. И если что то в базе меняется, то, скорее всего, достаточно будет подредактировать хранимку. А если запрос в приложении, то придется пересобирать приложение (что не есть good)
Но с использованием хранимок тоже я думаю не стоит борщить, и закидывать запрос вида
select id from table1
в хранимку

2. А здесь уже, как я говорил, вариантов куча. Все зависит от задачи... Когда можно вообще данные не дергать, когда их нужно постоянно дергать - это уже частные случаи.

0