Работа с ADO и обновление DataSet (MS SQL)

← →
KSergey (2003-10-06 14:37) [0]

Люди!
Проблема, думаю, знакома многим. MS считает, что движок ADO супер умный и он сам сообразит какие команды отправлять на сервер в случае обновления записи.
А вот и нифига! Я уже не говорю, что бывают объективно необхновляемые RecordSet"ы, но даже и с обновляемыми геморроя не оберешься.
Вот Borland поступила все же мудро: сделала UpdateSQL - и голова не болит (ну во всяком случае, все можно победить, проблемы - только руки свои винить). А в ADO такого, как известно, нет (исключая компоненты Volga, но это уже обертка над ADO).

Вопрос: может поделится кто-либо технологией, как с этой бякой борется, а? В частности, при добавлении новой записи, да и обновлении тоже. При этом, на сервере хотелось бы иметь автоинкрементные поля, а так же поля, формируемые тригерами.
В простейших случая (1 таблица, 2 автоинкрементное поле) - все работает, а вот дальше (я уже молчу про попытки связать 2-3 таблицы) - бывает очень тяжко.
Был бы признателен за описание общего подхода в решении проблем организации приоржения при необходимости непосредственного обновления DataSet через DataAware коспоненты.

PS
1.Про статьи на "Королевтсве" - знаю. Они помогают, но далеко не во всех ситуациях, да и информацию изложенную в них все навно приходится использовать лишь в паре с бубном.
2.В принципе, конечно есть альтернативные варианты: вычитать на клиента в какой-либо Client DataSet, а потом генерить команды ручками при изменениях на клиенте и отправлять их на сервер. В принипе, тот же UpdfateSQL и получится, но неужели нельзя это решить штатными методами? Впрочем, если кто-то именно так и делает - было бы интересно об этом почитать.

← →
Polevi (2003-10-06 14:45) [1]

Db-aware это зло
думаю все в конце-концов приходят к этому выводу

UI должен оперировать объектами.
остается только написать процедуры сохранения объекта в хранилише (DB) и восстановления его оттуда

а DB-Aware заменяются своими Object-aware компонентами. Грид и дерево. Редактирование в формах

скорость разработки возрастает на порядок

← →
KSergey (2003-10-06 14:55) [2]

> [1] Polevi © (06.10.03 14:45)

Тут есть одно замечание: "Редактирование в формах" и "скорость разработки возрастает на порядок" - это с точки зрения разработчика.
Однако есть еще такой немаловажный фактор, как удобство работы конечного пользователя программы. Так вот пользователю иногда бывает удобно работать именно в гриде. И я ему охотно верю. А грид - это всяко некий DataSet или его аналог, другого я не вижу, если что-то недосматриваю - просветите, плиз.

PS
Почему-то в MS Excel никто не принуждает изменять данные таблицы в отдельной форме ;)

← →
Opuhshii (2003-10-06 14:56) [3]

согласен с Polevi © (06.10.03 14:45) [1]

← →
ZrenBy (2003-10-06 15:23) [4]

>>KSergey © (06.10.03 14:55) [2]

А в чем проблемы ?

Один из тупейших вариантов

На стороне сервера -
insert into #temptable select from ... всяческие навороты
select * from #temptable

На стороне клиента - ltBatchOptimistic

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

← →
KSergey (2003-10-06 16:10) [5]

[3] Opuhshii © (06.10.03 14:56)
согласен с Polevi © (06.10.03 14:45) [1]

Это здорово, но тогда нельзя ли чуть подробнее организацию? Мне было бы очень интересно почитать ;)

[4] ZrenBy © (06.10.03 15:23)
>>KSergey © (06.10.03 14:55) [2]
А в чем проблемы ?

Проблемы у меня в том, чтобы осознать, что других путей действительно нет, а этот, на мой взгляд, призван просто обойти проблему, так ведь? При этом я не говорю, что он плох, просто всегда надеишься на какие-то "волшебные" панацеи. ;) Т.е. если принципиально других путей предложено не будет - значит к этому и пойдем. О чем-то таком я и писал, упомяная о таблицах в памяти.

PS
Я понимаю, что пытаюсь подвигнуть вас к варианту нахаляву узнать "секреты" и плоды долгих поисков, но, что тут таиться, я именно для этого ветку и затеял: в надежде увидеть в ней описание некоторых вариантов, реализованных технологий, которые использует народ - ну и, сопоставив с тем, что сам об этом думаю, прибиться к какому-то варианту... ;)

← →
ZrenBy (2003-10-06 16:28) [6]

>>KSergey © (06.10.03 16:10) [5]

Надо иметь ввиду еще один момент.

Я, например, во всех проектах, никому никаких прав на
таблицы не даю. Принципиально. Естественно, все примочки
ADO отдыхают. Работаю или через вьюхи или через
возвращающие рекордсеты ХП. Разграничение прав через роли.
Соответствено, любое изменение - отработка ХП.
Данные, которые изменились за счет триггеров и вложенных ХП,
или добавились (identity, GUID) она же и возвращает клиенту.
А на клиенте еще работает ADO.Sort.

И вот еще. DB Aware я не использую. Просто на гриде лежат
edit, combobox и др. При необходимости позиционирую,
показываю, проверяю, что там юзера наваяли, а потом обрабатываю
onExit или onClick, скрываю, вызываю ХП, ну и далее.

← →
KSergey (2003-10-06 16:38) [7]

> [6] ZrenBy © (06.10.03 16:28)
> Разграничение прав через роли.

Через какие роли? Серверные? Или построена какая-то система раздачи прав в клиентском приложении?

> И вот еще. DB Aware я не использую. Просто на гриде

А тогда на каком гриде? (не, я понимаю, что не только DBGrid есть в природе, но у вас это как сделано?)

← →
ZrenBy (2003-10-06 16:47) [8]

>>KSergey © (06.10.03 16:38) [7]

Да. Обычная DataBase Standard Role.
Клиент этим не занимается.

Грид ? Ну, сейчас у меня используются 2 грида.
1) Обычно DBGrid - стандартная схема
2) В некоторых случаях TDrawGrid, работающий непосредственно с
ADO-шным Recordset`ом, минуя глюкавых посредников.

← →
Polevi (2003-10-06 16:55) [9]

>А грид - это всяко некий DataSet
грид - это визуальный компонент который умеет рисовать себя.
и данные для отрисовки вовсе не обязательно брать из TDataset

← →
Polevi (2003-10-06 17:04) [10]

>KSergey © (06.10.03 16:10) [5]
такая организация позволяет клиентской части абстрагироваться от хранилища, процедуры сохранения-восстановления происходят обычно на среднем звене (но оно может быть и на клиенте) - а клиент лишь запрашивает нужные ему объекты, изменятет из св-ва (с помощью юзера к примеру) и отправляет измененные объекты обратно
это также позволяет добавить на среднее звено какой-либо скриптовый движок, что делает систему чрезвычайно гибкой - в частности доступы можно реализовать именно там

← →
KSergey (2003-10-06 17:15) [11]

> [9] Polevi © (06.10.03 16:55)
> >А грид - это всяко некий DataSet
> грид - это визуальный компонент который умеет рисовать себя.
>
> и данные для отрисовки вовсе не обязательно брать из TDataset

Ну не скажите ;)
Тут я имел в виду не только буквально TDataSet, а вообще некое хранилище на клиенте, где хранятся данные для отображения.
Впрочем понятно. Согласно [10] вы, по сути, полностью переписыли под себя то, что было задумано у борландов. Вернее, наработали альтеративный механизм.

> [8] ZrenBy © (06.10.03 16:47)
> ADO-шным Recordset`ом, минуя глюкавых посредников.

Что подразумевается под "глюкавыми посредниками"? Те проблемы, о которых я писал, не есть производные борландовских оберток, если об этом речь. Или речь о другом?

PS
Что меня удивляет: чем дальше лезешь, тем больше выясняется, что все эти RAD красявости дельфей по сути все заново переписывают под себя. И зафига их тогда плодят борландовцы? Мне чес. слово не понятно. Разве чтобы показать на очередной презетнашке как классно и быстро можно сосряпать простейшее приложение? Ведь на деле в реальных даже средних проектах все равно все эти ихние выдумки никем не используются! Обидно и странно мне это.

← →
Polevi (2003-10-06 17:37) [12]

тебе за меня обидно или за борланд ? :-)
хочешь готовое решение - используй CORBA, там все правильно сделано

← →
KSergey (2003-10-07 15:45) [13]

> [12] Polevi © (06.10.03 17:37)

Да за двойную работу обоих ;)

Хорошо, положим я начинаю сам все ручками делать, забываю, что у DataSet"ов есть Insert/Update/Post и т.д. Впрочем, я то об этом уже забыл, а вот DBGrid - помнит, гад.

Ну да проблема (опять же стандартная!) следующая: а беру, например, некий MemoryDataSet (название условное) и организовываю все на нем.
Но что делать с автоинкрементными полями?
Да, можно почитать @@identity, ну а если там приггер на вставку, который еще куда-то чего-то вставляет - тогда это самое @@identity мне уже не получить.
Как тут быть? Как вообще жить-то дальше??

← →
Polevi (2003-10-07 15:49) [14]

qry.Add("INSERT INTO ...);
qry.Add("SELECT @@IDENTITY");
qry.Open;
idty:=qry.Fields[0].AsInteger;

qry.Clear;
qry.Add(Format("SELECT * FROM WHERE ID=%d",[idty]));
qry.Open;

← →
ZrenBy (2003-10-07 15:55) [15]

>>ну а если там приггер на вставку, который еще куда-то чего-то
>>вставляет - тогда это самое @@identity мне уже не получить.

select SCOPE_IDENTITY()

← →
KSergey (2003-10-08 09:16) [16]

> [14] Polevi © (07.10.03 15:49)
> qry.Add("INSERT INTO ...);
> qry.Add("SELECT @@IDENTITY");
> qry.Open;
> idty:=qry.Fields[0].AsInteger;

Нет, увы.
Еси в таблице есть триггер на вставку, который добавляет записи в другую таблицу, так же содержащую автоинктементное поле, то @@IDENTITY вернет значение автоинкремента для второй таблице (вернее, для последней, затронутой в триггере). О чем думали в MS - мне не понятно. Иногда хочется крикнуть, что козлы они все же.

> [15] ZrenBy © (07.10.03 15:55)
> select SCOPE_IDENTITY()

Да, осознав свои "промахи" - в 2000 сервере они это реализовали. Спасибо за подсказку, вот только чтобы ею воспользоваться - сначала необходимо еще перейти на 2000 сервер...

← →
Delirium (2003-10-08 10:33) [17]

> KSergey ©
Как я понимаю, вся проблема в получении идентификаторов, в частности IDENTITY. Возникает такая проблема тогда, когда при проетировании БД идентификаторам внимания не уделяют, а зря.

Если бы вы отказалсь от IDENTITY, а как делают в больших распределённых системах, создали собственное хранилище идентификаторов, вы бы просто не знали-бы об излагаемой проблеме.

Кроме того, в защиту ADO скажу, что эта единственная технология, в которой набор данных - независимый легко управляемый объект, котрый кстати элементарно заменяет ClientDataSet, делая последний - вообще не нужным.

← →
KSergey (2003-10-08 11:29) [18]

> [17] Delirium © (08.10.03 10:33)

Ладно, про ADO не будем.
А вот про IDENTITY поля - скажу честно: мне противно, что практически все "навороты" и "удобства быстрой разработки" систем проектирования и платформ развертывания (а в данном случае SQL-сервера) по сути не используются в "больших распределённых системах". Т.е. я так посмотрел на разные рекомендации в разных местах - и по сути все сводится к одному: бросай это все и делай ручками.
Возникает вопрос: а нафига все это реализовывать, если оно кривое и использовать это реально - очень сложно или даже просто невозможно?
И вот сидят толпы разработчиков и каждый изобретает свой велосипед, немного адаптированный под свою задачу. В принципе, это безусловно намного проще, чем разбираться в том, что понаворотили разработчики всяких монстров, но выходит - что это единственный путь? И разбираться изначально и нет смысла, кроме как для общего развития?
Правда ничего конструктивного мой этот пост не несет, получилось -на судьбу пожалился... Прошу у всех прощения, но для меня это было большим разочарованием.

← →
Delirium (2003-10-08 11:37) [19]

"а нафига все это реализовывать, если оно кривое и использовать это реально - очень сложно или даже просто невозможно?" - эти разработки нужны и даже более, но использовать их надо грамотно.
Например Identity в MSSQL весьма активно используется в хранимых процедурах, при программировании бизнес-логики. Например: если существует упорядоченный поток данных и требуется сравнить текущее значение с предыдущим, нет ничего лучше, чем наложить Identity во временную таблицу, кластерно проидексировать и осуществить запрос типа:
select ... from #tmp_table t1 join #tmp_table t2 on t1.ID=t2.ID+1
Работает мгновенно.
Можно использовать Identity в справочниках, но никак не в оперативных таблицах, ибо сие во первых - жёсткая привязка клиента к серверу, во вторых трудности при разработке (о которых и была речь), да и вообще - показатель недостаточной эффективности системы.

← →
KSergey (2003-10-08 11:54) [20]

А почему показатель неэффективности?
Да и трудности - они, как мне кажется, от того, что разработчиком сервера не продумано в деталях как это все использовать.
Ну представьте, что это бы все работало на ура - неужели этим бы не пользовались или это все равно было бы показателем "недостаточной эффективности системы"?? Да, возможно в некоторых случаях сложных и распраделенных систем, но в относительно простейших случаях 1 сервер - несколько к нему подключенных клиентов?

← →
Delirium (2003-10-08 11:58) [21]

Оч. просто - обрыв сети, сбой напряжения, эффект уборщицы, ещё бог-знает что - работа стоит, товар не продаётся, деньги не зарабатываются, эффективно? А всего-то, сделать клиента чуть более независимым, получить диапазон идентификаторов и спокойно оформлять накладные или чеки выбивать в течение часа, пока стоит сервер - самостоятельно. Сеть заработала - синхронизация прошла, все довольны :) Такой подход тем более эффективен при малом кол-ве машин, а следовательно низком уровне обслуживания, поверьте, подобного опыта у меня достаточно.

← →
KSergey (2003-10-08 13:17) [22]

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

Работа с ADO и обновление DataSet (MS SQL) Найти похожие ветки