Обновляемый (и устойчивый) набор данных на основе объединения — возможно с ADO.Net?

#.net #ado.net

Вопрос:

Итак, допустим, у меня есть набор данных, основанный на:

 SELECT     TopicLink.*, Topic.Name AS FromTopicName, Topic_1.Name AS ToTopicName
FROM         TopicLink INNER JOIN
                      Topic ON TopicLink.FromTopicId = Topic.TopicId INNER JOIN
                      Topic AS Topic_1 ON TopicLink.ToTopicId = Topic_1.TopicId
 

С помощью старой школы ADO, используя набор записей, я мог бы изменять столбцы в таблице TopicLink и вызывать функцию сохранения() в наборе записей, и это вернуло бы его в базу данных. Неужели эта функциональность больше невозможна в ADO.Net, предположительно с командным строителем? Или есть обходной путь?

(Да, я знаю, что мог бы «просто» написать хранимую процедуру…но я ищу быстрое и простое решение, в основном аналогичную функциональность, которая была у нас в старом ADO или MS Access, где вы можете выполнить запрос с несколькими соединениями, привязать его к сетке в форме, и пользователь может обновлять и сохранять данные без какого-либо кода)

Ключевой момент здесь: я не хочу вручную писать инструкции INSERT, UPDATE и DELETE.

Ответ №1:

Я думаю, что вы можете достичь этого, предоставив свою собственную команду обновления для ADO.net Адаптор данных. Ознакомьтесь с образцом, представленным здесь.

Комментарии:

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

Ответ №2:

Насколько я понимаю, до тех пор, пока вы выбрали весь первичный ключ из каждой таблицы, которую будете обновлять, с вами все должно быть в порядке, так как ADO.NET будет знать, что делать с обновленными данными автоматически. Однако, если в ваших возвращенных данных нет первичных ключей, ADO.NET не будет знать, какие строки в таблицах ему необходимо обновить, и поэтому не сможет вам помочь, если вы не укажете свой собственный оператор ОБНОВЛЕНИЯ (как предложил другой ответчик).