Если кто-то боролся с событиями в ADO, то скажите, пожалуйста, почему не приходит событие FetchComplete по окончании асинхронного открытия таблицы Recordset'ом? Остальные события (WillMove, MoveComplete и т.д.) приходят. В чём может быть дело?
Здравствуйте mitq, Вы писали:
M>Привет всем.
M>Если кто-то боролся с событиями в ADO, то скажите, пожалуйста, почему не приходит событие FetchComplete по окончании асинхронного открытия таблицы Recordset'ом? Остальные события (WillMove, MoveComplete и т.д.) приходят. В чём может быть дело?
M>Спасибо, M>Дмитрий.
Я думаю это от провайдера зависит, если он позволяет такие вещи, событие приходить будет.
Здравствуйте Алекс, Вы писали:
А>Я думаю это от провайдера зависит, если он позволяет такие вещи, событие приходить будет.
Ok, покопаю в этом направлении. Но хочу задать ещё один вопрос: какие стили нужно понавешать на Recordset для того, чтобы в нём можно было обновить одну запись? Уже часа три бьюсь и не могу реализовать такую простую вещь:
1) Есть один Recordset (adUseClient, adOpenStatic, adLockOptimistic), который я использую для просмотра и который состоит из нескольких таблиц.
2) Изменяю одну из таблиц так:
3) Пытаюсь увидеть изменения в Recordset'е из первого пункта:
recordset->Resync( adAffectCurrent, adResyncUnderlyingValues );
// Я абсолютно уверен в том, что стою на той записи, в которой были произведены изменения.
После "перезапуска" Recordset'а изменения проявляются, но это слишком долго.
Появилась идея: я изменяю id'шник, используемый для сцепления таблиц, а не значение, выводимое на экран. Видимо, всё таки придётся перезапускать Recordset. Я прав?
Здравствуйте mitq, Вы писали:
M>Здравствуйте Алекс, Вы писали:
А>>Я думаю это от провайдера зависит, если он позволяет такие вещи, событие приходить будет.
M>Ok, покопаю в этом направлении. Но хочу задать ещё один вопрос: какие стили нужно понавешать на Recordset для того, чтобы в нём можно было обновить одну запись? Уже часа три бьюсь и не могу реализовать такую простую вещь: M>1) Есть один Recordset (adUseClient, adOpenStatic, adLockOptimistic), который я использую для просмотра и который состоит из нескольких таблиц. M>2) Изменяю одну из таблиц так: M>
M>3) Пытаюсь увидеть изменения в Recordset'е из первого пункта: M>
M> recordset->Resync( adAffectCurrent, adResyncUnderlyingValues );
M> // Я абсолютно уверен в том, что стою на той записи, в которой были произведены изменения.
M>
M>После "перезапуска" Recordset'а изменения проявляются, но это слишком долго.
M>Появилась идея: я изменяю id'шник, используемый для сцепления таблиц, а не значение, выводимое на экран. Видимо, всё таки придётся перезапускать Recordset. Я прав?
Может это и не даст выигрышь в скорости, но ИМХО нужно сделать наоборот: первый рекордсет должен быть adOpenDynamic, а второй adOpenStatic.
Кстати, если второй заводится только для изменения пары-другой записей в табличке, лучше напрямую использовать SQL'ый update table. На много быстрее будет.
Здравствуйте Алекс, Вы писали:
А>Может это и не даст выигрышь в скорости, но ИМХО нужно сделать наоборот: первый рекордсет должен быть adOpenDynamic, а второй adOpenStatic. А>Кстати, если второй заводится только для изменения пары-другой записей в табличке, лучше напрямую использовать SQL'ый update table. На много быстрее будет.
Здравствуйте mitq, Вы писали:
M>Привет всем.
M>Если кто-то боролся с событиями в ADO, то скажите, пожалуйста, почему не приходит событие FetchComplete по окончании асинхронного открытия таблицы Recordset'ом? Остальные события (WillMove, MoveComplete и т.д.) приходят. В чём может быть дело?
M>Спасибо, M>Дмитрий.
It may be opened synch even if you asked asynch. In that case FetchComplete will not be fired (wierd isn't it). So, to make it a bit straight forward I checked if rs is opened in asynch and if not then fire FetchComplete myself.