![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Работа с ADO и обновление DataSet (MS SQL) [D5]
KSergey © (2003-10-06 14:37:00)
Люди!
Проблема, думаю, знакома многим. MS считает, что движок ADO супер умный и он сам сообразит какие команды отправлять на сервер в случае обновления записи.
А вот и нифига! Я уже не говорю, что бывают объективно необхновляемые RecordSet"ы, но даже и с обновляемыми геморроя не оберешься.
Вот Borland поступила все же мудро: сделала UpdateSQL - и голова не болит (ну во всяком случае, все можно победить, проблемы - только руки свои винить). А в ADO такого, как известно, нет (исключая компоненты Volga, но это уже обертка над ADO).
Вопрос: может поделится кто-либо технологией, как с этой бякой борется, а? В частности, при добавлении новой записи, да и обновлении тоже. При этом, на сервере хотелось бы иметь автоинкрементные поля, а так же поля, формируемые тригерами.
В простейших случая (1 таблица, 2 автоинкрементное поле) - все работает, а вот дальше (я уже молчу про попытки связать 2-3 таблицы) - бывает очень тяжко.
Был бы признателен за описание общего подхода в решении проблем организации приоржения при необходимости непосредственного обновления DataSet через DataAware коспоненты.
PS
1.Про статьи на "Королевтсве" - знаю. Они помогают, но далеко не во всех ситуациях, да и информацию изложенную в них все навно приходится использовать лишь в паре с бубном.
2.В принципе, конечно есть альтернативные варианты: вычитать на клиента в какой-либо Client DataSet, а потом генерить команды ручками при изменениях на клиенте и отправлять их на сервер. В принипе, тот же UpdfateSQL и получится, но неужели нельзя это решить штатными методами? Впрочем, если кто-то именно так и делает - было бы интересно об этом почитать.
KSergey (2003-10-06 14:55:00) [21]
> [1] Polevi © (06.10.03 14:45)
Тут есть одно замечание: "Редактирование в формах" и "скорость разработки возрастает на порядок" - это с точки зрения разработчика.
Однако есть еще такой немаловажный фактор, как удобство работы конечного пользователя программы. Так вот пользователю иногда бывает удобно работать именно в гриде. И я ему охотно верю. А грид - это всяко некий DataSet или его аналог, другого я не вижу, если что-то недосматриваю - просветите, плиз.
PS
Почему-то в MS Excel никто не принуждает изменять данные таблицы в отдельной форме ;)
Polevi (2003-10-06 14:45:00) [22]
Db-aware это зло
думаю все в конце-концов приходят к этому выводу
UI должен оперировать объектами.
остается только написать процедуры сохранения объекта в хранилише (DB) и восстановления его оттуда
а DB-Aware заменяются своими Object-aware компонентами. Грид и дерево. Редактирование в формах
скорость разработки возрастает на порядок