Пакетная передача обновлений (Insert) в базу данных посредством DataAdapter.Update

Здравствуйте, господа
Кто-нибудь имел дело с пакетной передачей обновлений (а конкретно вставок) в базу данных посредством DataAdapter.Update с возвратом обновленных значений (актуализированных через @@IDENTITY) первичных ключей в исходные DataRow и с количество передаваемых за одно обращение к базе строк > 1 ?
Вцелом код решения у меня есть и успешно работает. А проблема возникла, именно когда я захотел увеличить размер передаваемого пакета с одной строки до, например, DataAdapter.UpdateBatchSize = 5
Если кто направит в правильном направлении за решением - буду очень благодарен

0

Вопрос на засыпку. А накуа?
Если, как Вы пишите, имеете дело с DataRow, то смело можете собирать их в таблицы, а таблицы в 1 датасет. Вот Вам и решение всех проблем. Датасет сериализуете в xml, а саму строку xml-ную передаете 1-им параметром в хранимку сиквелу. На стороне сиквела через xQuery десериализуете, и обновляете все свои таблички. Оттуда же, с процедуры можете вообще десяток селектов вызвать в коллбек шарпу. И не нужно выдумывать десяток велосипедов.

1

hoolygan, спасибо за профессиональный вариант.
Но коллбэк не проканает - я кодю из-под VB.NET
Да и с обновлением через хранимые процедуры еще не разобрался. Хотя признаю, что Ваш вариант самый верный.
Просто и само приложение и база сейчас на стадии разработки. И поэтому каждый раз переписывать процедуры обновления вслед за модификацией схемы данных таблицы тоже, на мой взгляд, не удобно.
Поэтому пока временно работаю через адаптер.
Что, по моему варианту обновления все плохо ?

0

Bars4, а разве у vb.net нету тасков? а у тасков точно есть коллбеки (ну эт я их так по-привычке называю). Собственно говоря, можно же после отработки апдейта запускать селект. Да и адаптерный метод update всегда переопределить можно под себя, просто прописав в нем вызов хранимки.
А по поводу того, что переписывать.... ну тут не без этого. Расширяете/урезаете функционал - переделываете под себя
Но Вы не с того начали работу. Сначала делайте модель данных, а потом крутите БД. Может тогда проще вообще на EF делать? Ноэто так, к слову.

0

hoolygan, ты рушишь мой мир.
Я теперь не понимаю, что мне дальше делать...
Останавливать всю работу и садиться за буквари?

0

Bars4, ну я бы все-таки сел с ручкой, бумажкой, и продумал модель данных, чтобы впоследствии не сильно переписывать ))
Смотря для чего это все делается. Если для еденичного случая с 1 формой, и 2мя контролами - то наверное пофиг. А если что-то серъезней - то без модели будет тяжело поддерживать проект. А это как бы самое главное, потому что доработок/хотелок всегда на 100500 процентов больше, чем первоначальных задумок.

1

hoolygan, Конечно, хотелось бы, чтобы проект получился жизнеспособным и развиваемым. Но по модели - даже не буду пытаться продумать и зафиксировать на бумаге (пытался, но потом понял, что многое решается по ходу реализации проекта) , ибо для этого надо иметь критический опыт и навыки проектирования БД.

Но если ты говоришь, что бурундук - птичка, значит бурундук - птичка...как бы не хотелось оттянуть это "до лучших времен" - придется пытаться переходить на процедурное обновление.
А тебе придется побыть дебаггером в этом нелегком деле...

0

Сообщение от Bars4 Кто-нибудь имел дело с пакетной передачей обновлений (а конкретно вставок) в базу данных посредством DataAdapter.Update с возвратом обновленных значений (актуализированных через @@IDENTITY) первичных ключей в исходные DataRow и с количество передаваемых за одно обращение к базе строк > 1 ?

Всё это уже реализовано в DataAdapter. Если он у вас правильно "приготовлен"(создан с помощью мастера или класса SqlCommandBuilder), то в команде INSERT не только прописана вставка данных, но и возвращение ключевого значения.

0

Igr_ok, да, все команды вставки, обновления и удаления у меня уже заряжены в DataAdapter и адекватно работают.
Просто если объем обновлений за раз составляет несколько тысяч строк, тогда, из-за построчной передачи обновлений, наблюдается заторможенность обновления.
Вот поэтому я и хотел обернуть обновления в транзакции по несколько строк за раз, например по 100. Как это реализовать и какие параметры .UpdatedRowSource и .UpdateBatchSize адаптера выставлять не пойму

0

Bars4, для вставки большого кол-ва записей есть SqlBulkCopy: https://msdn.microsoft.com/ru-... 10%29.aspx

1

Igr_ok, да, похоже на то

0

Bars4, заторможенность обновления связана всегда в первую очередь с тем, что адаптер работает в синхронном режиме. Отпускайте его в асинхронность - и торможений не будет. Пока пользователь "раздуплится" - обновление уже произойдет.
А вот это SqlBulkCopy - хорошо только в 1-ом случае - если нужно строки гнать только в 1-ну таблицу. Когда же начинается логика работать внутри сиквела - начинают выдумывать десяток костылей, особенно, если есть связанные таблицы по Identity. Если просто нужно, например 1 таблицу скопировать в сиквел в 1-ну целевую таблицу - то пользуйтесь балком, если же нужно распихивать по десятку связанных таблиц (а чаще всего именно так и происходит в средне/больших проектах) - то никакой бал не поможет, даже больше - он вреден. Там либо EF, либо хранимки.
Объясню почему.
Напр, у вас проект, который Вы скомпилировали и раздали пользователям (5-20-50-1000 человек), а через неделю новая хотелка - "хочу когда поставлю галочку, чтобы у меня вот тут добавилось поле и сохранялись данные с вот этого комбобокса". И начинается.... пересборка проекта, изменение логики, и опять раскидывание на всех пользователей. Или же - изменение в хранимке, а пользователелям уже все работает, и они ничего не почуствовали. Вот как-то вот так вот.

1

hoolygan, да, обновления я передаю сложноструктурные, состоящие из каскада связаных подчиненных таблиц, в т.ч. самоподчиненных (отношение "слоновье ухо").
Но! В самой процедуре отправки обновления у меня все разложено по полочкам - последовательно потаблично в нисходящем по структуре порядке Select-ом выдергиваю строки .Added, .ModifiedOriginal и адаптером обновляю в базу с возвратом актуализированных ключей и других пересчитанных сервером данных через параметры.
С удаленными строками та же потеха, только в восходящем по структуре порядке.
А после возврата обновленных ключей - они каскадируются силами DataRelation.
Так вот в такой моей ситуации признается ли такое обновление однотабличным и нормально ли будет применять балк в этом случае (хоть и в качестве временной меры) ?.
А про хранимые процедуры я даже и не спорю - это правильная идеология и о ней пишут во всех букварях. И когда приложение уже поставлю на ноги обновляться буду только через хранимки. Но прямо сейчас переход на ХП потребует от меня времени на написание и отладку (если только найдется работоспособный пример двунаправленного обновления структурного DataSet через ХП, который можно освоить за день).
На сегодняшнем этапе разработке адаптер, по моему скромному мнению, при его правильном конфигурировании может показать неплохую производительность. Но только почему-то после обертывания .Update в транзакцию и установке .UpdateBatchSize > 1 возврат обновленных значений из БД через параметры перестает работать. И это как-то связано с .UpdatedRowSource.

0

Bars4, бедный Ваш клиент если он сам мержит таблицы, создает отношения, раскладывает по полочкам
Пробуйте, я не скажу по поводу балка в таком случае, как он себя поведет - может быть Вы и расскажите об этом для последующих поколений.

0

hoolygan, я уловил Ваш сарказм
Ну я просто делаю так, как написано в литературе по ADO.NET.
Разве мог я предположить, что это все окажется курам насмех...
Какую книгу я должен взять в руки, где изложены приемы создания клиента в "правильном" стиле ?

Добавлено через 8 минут
З.ы. И кстати, как Вы поняли, я не мержу, а возвращаю значения через параметры - разве это не правильно ?
И что, можно обойтись без DataRelation для отображения Master-Detail гридов, один из которых еще и TreeGrid...
Правда, вы рушите мой мир. Возможно это пойдет мне же на благо...

0

Bars4, совершенно, кстати, не сарказм был. Самый сейчас вот банальный пример из своей работы расскажу. Есть форма, в ней 8 вкладок, в каждой из них от 1 до 4-ех связанных таблиц. Все это договор, а в нем пару десятков контролов и таблиц. В некоторых таблицах колонки -это checkedComboBox, т.е. еще и связанные таблицы на каждую строку. Это предисловие. Ну соответственно все контролы забиндены в классы, т.е. есть общий класс договора, у него связи с остальными классами, в общем - просто модель данных. Когда договор идет на сохранение, то работа клиента - это просто сериализовать класс договора в xml-ку, примитивная работа на доли секунды. Все, дальше запускаю обыкновенную команду на сиквел, которой передаю название процедуры и xml-ку. А уже на стороне сиквела у меня хранимка на полторы тыс строчек, которая распарсивает, складывает, обновляет, удаляет, ну вы поняли. После того, как хранимка отработала - запускаю метод шарпа, который заново запращивает данные с сиквела. Ведь мало ли что при этом у меня там изменилось, может справочники добавились, может другие пользлватели что-то добавили.
Поэтому во всех книжках пишут не возвращать параметры при апдейте, а полностью перечитывать все.
Но это так, к слову было. Т.е. я не сарказничал, а рассказывал, как сделано у меня. Может тоже неправильно, я не буду доказывать, что так должно быть. Но точно скажу, что после обновления нужно запускать процесс считывания. Эра однопользовательских программ закончилась лет 30 назад, и нужно учитывать, что менять может не 1 пользователь

1

Bars4, скорость bulk copy достигается за счет отказа от логирования в SQL Server, так что это вам не поможет.

1

Igr_ok, спасибо, принял)

Добавлено через 16 минут
hoolygan, это я дуркую

Сообщение от Bars4 я уловил Ваш сарказм

hoolygan, вот уже сутки перевариваю Вашу мысль по способу обновления и понимаю, что он - весьма хорош.
Я себе уже набросал план модификаций версий процедуры по повышению производительности передачи обновлений в БД.
Так одной из модификаций моей процедуры станет запуск передачи обновлений по одному процессу на каждую таблицу и на каждый тип обновлений.
А следующий вариант - уже будет Ваш.
И вот тут я бы уже набрался наглости просить какие-нибудь образцы кода клиента и процедуры , чтобы понимать с чего начинать (или в личку, если это комм. тайна).

0