Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
Пытаюсь перевести свой проект с БД под MSSQL с ZeosLib на ADO (достали ограничения DB LIb'а). Есть TADOQuery, в котором делается SELECT с объединениями и ORDER BY. Хочется, чтобы, во-первых, recordset был редактируемым, и, во-вторых, при вставке новая запись оказывалась не в конце, а там, где она должна быть в соответствии с ORDER BY. Первое достигается прописыванием свойств Update Criteria, Update Resync и Unique Table. Для второго, судя по всему, надо прописывать Immobile Rows=false. Проблема в том, что при использовании клиентского курсора попытка изменить Immobile Rows приводит к ошиьке типа "невозможно изменить read-only свойство". При серверном же курсоре у датасета в принципе отсутствуют свойства Update Criteria и т. д. Это, в принципе, логично, поскольку их использует, насколько я понял, Local Cursor Engine. Но задачу-то решить хочется! Что делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2003, 10:06 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
Работаю с базой через sp. Для редактироавния полученного ADODataSeta при его содании прописываю: with ADODataSet do begin Close; Connection := MyBase.FADOConnection; CommandType := cmdStoredProc; LockType := ltBatchOptimistic; Filtered := False; Filter := ''; Parameters.Clear; Prepared := False; end; В sp на сервере результат select'a перегоняю в tmp таблицу и ее уже выдаю клиенту. Update и Del - отдельные sp. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2003, 11:11 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
Так неинтересно. Хочется ведь попользоваться плюшками от ADO - типа, например, того, что при изменении записи ее можно одну прорефрешить, а не выполнять целиком весь SELECT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2003, 12:56 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
А рефрешить как раз и не надо. Ты напрямую редактируешь DataSet на клиенте, после этого апдейтишь базу, если что не так - откат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2003, 20:46 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
Вроде этого: with TADOCommand.Create(nil) do try Connection := MyBase.FADOConnection; CommandType := cmdStoredProc; CommandText := 'update_fuel'; if DataSet.State = dsInsert then DataSet.FieldByName('fuel_id').AsInteger := -1; Parameters.CreateParameter('@result', ftInteger, pdReturnValue, 32, 0); Parameters.CreateParameter('@id', ftInteger, pdInput, 32, DataSet.FieldByName('fuel_id').AsInteger); Parameters.CreateParameter('@fuel_name', ftString, pdInput, 32, DataSet.FieldByName('fuel_name').AsString); Parameters.CreateParameter('@benzine', ftBoolean, pdInput, 32, DataSet.FieldByName('benzine').AsBoolean); Parameters.CreateParameter('@diesel', ftBoolean, pdInput, 32, DataSet.FieldByName('diesel').AsBoolean); Parameters.CreateParameter('@gas', ftBoolean, pdInput, 1, DataSet.FieldByName('gas').AsBoolean); Execute; if Parameters.ParamByName('@result').Value < 0 then Abort; DataSet.FieldByName('fuel_id').AsInteger:=Parameters.ParamByName('@result').Value; Free; except on e:Exception do begin ShowErr(e.Message, CommandText); Free; Abort; end; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2003, 20:54 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
Да, подзадержался я... 2 harrytv: Нет, это мне как раз не подходит. Дело в том, что значения некоторых полей в запросе определяются на сервере (это может быть результат работы триггера или просто что-то, подтягиваемое из справочника JOIN'ом). И дублировать все это дело на клиентской стороне абсолютно не хочется, а пользователю надо значения этих полей видеть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2003, 17:58 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
harrytv писал:В sp на сервере результат select'a перегоняю в tmp таблицу и ее уже выдаю клиенту. А это еще зачем? Без временных таблиц никак? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2003, 18:40 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
2tygra Давненько я сюда не заглядывал ;-) Однако, решение этой проблемы где-то год назад меня очень интересовало.Ничего лучше не придумал, вроде пока работает. Если есть другие идеи интересно узнать. Дело в том,что если редактировать DataSet, поднятый select'om ,при изменении полей типа primary key и т.п. генерится exeption. А при чтении #table можно писать в DataSet что угодно (в рамках разумного) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.10.2003, 18:21 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
А мне и не надо ключевые поля редактировать - на то они и ключевые. Они тама почти все identity/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2003, 12:52 |
|
||
|
ADO - редактируемый recordset + сортировка
|
|||
|---|---|---|---|
|
#18+
Вот именно. Т.к. ты не делаешь рефреш, а САМ пишешь данные в DataSet, в том числе и id (после успешного выполнения sp на сервере). База изменяется сохр. процедурой, возвращающей новый id. Подобным образом можно изменять и результат селекта на несколько таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2003, 15:39 |
|
||
|
|

start [/forum/topic.php?fid=58&fpage=1997&tid=2116432]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
28ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 244ms |
| total: | 336ms |

| 0 / 0 |
