Не будет ли любезен многоуважаемый All ответить на вопрос чайника в ADO:

Можно ли получить ОБНОВЛЯЕМЫЙ НЕ MSSQL ADO.Recordset в Recordset-е Access формы?


Поковырялся в форуме и возле. Не нашел.

Пробую что нить вида:

В источнике поля после загрузки стоит набор "динамический". Таблицу вижу. А править - фигвамы.
PS: MSA2000.

Ну, раз всем лень ткнуть чайника носом в первоисточники, попробую еще раз:

1. залез на С точностью до правки имен методов (.Refresh->.Requery), то, что там написано почти заработало. А именно, хотя в Open пишу adOpenDynamic, после подключения, проверяю и вижу ?.CursorType | adOpenKeyset, причем набор получается необновляемым (там где любые изменения в коде - вышибает на ошибку "провайдер..."). Если сразу при подключении пишу .CursorType = adOpenKeyset, набор обновляемый. (-"ниччего не понимаю"! - "аналогично"),и, как и объявлвлось ?.CursorType | adOpenKeyset. Чем оно (подключение) отличается в итоге (какое св-во надо смотреть) - не понял.

2. Проверил, что же цепляется как провайдер в коннекшене. ?cn.Provider | MSDASQL.1

3. Подцепил свою таблицу (см 1-й пост) с таким же соединением (т.е. через то же ДСН, без явного задания Provider и Driver и т.п. в коде). После открытия рекордсета (что жутко долго, хотя и хбсним, ибо мне ни табла ни нужна - она интересна именно возникновением ошибки при обычном присоединении, ни 2000 строк я тягать разом в форму не буду) он редактируемый (поставил останов и наредактировался, скоко угодно), но в форме - фих (а рекордсет, тем не менее, редактируется "в окне оладки" и после подключения).
Че не так?

строка Me.UniqueTable = "leaf_heap" при источнике "SELECT id, company, status, aid, kind FROM leaf_heap;" стала вышибать на ошибку. Причем в свойствах формы значение UniqueTable = "leaf_heap" появляется после подключения автоматом. Надо думать - это "MSDASQL.1" прорезался?

?
1. Насколько я понимаю, по умолчанию формы в mdb возвращают DAO, а ADP - ADODB recordset-ы,

When a recordset is asked for in a Microsoft Access database (.mdb), a DAO recordset is returned, in a Microsoft Access project (.adp), an ADO recordset is returned.
т.е "когда запрашиваются - тогда возвращаются такого-то типа". Или нет?
а это не то же самое, что "требуют такого-то типа, когда это необходимо". Или я опять не прав?

2. Пока копал, видел вопросы по работе с ADO рекордасетами форм из mdb. Вроде как народец что-то даже обновлял. Команды синхронизации подавал (для сложных случаев - типа хранимок) и т.п. Только вот отсылка была к тому, что на кой-то ляд требуется (в 2000), для MSSQL: Provider = "MSDataShape" (а иначе вроде как кранты). (Я просмотрел верхами - большая выборка на аглицком наречии, а мне все одно Provider = "MSDataShape" вроде не светит - .Update не проходит даже из кода - "недостаточно данных ..."). Т.ч. пишу .Provider = "MSDASQL" (или через ДСН - но с без явного .Provider = "MSDASQL" тормознее, а итог - один). Вот так и получается - все у формы в свойствах "готово для редактирование/вставки/удаления", рекордсет из кода редактируется. (Результаты я тут же запросами просматриваю.) А в форме - "Форма доступна только для чтения" - а уж это-то с какого дуба? (по первости писалось что-то типа "нередактируемый набор") А сейчас - черт те что. А что поменялось? А ничего, вроде бы. В произвольные моменты выдало ругательство что "OLE-что-то-там не зарегистрированно". Но повторить сообщение с разбега не удается.

"ниччего не понимаю"

Ага, понятно:
.CursorLocation = adUseClient
- Данный набор записей не допускает обновления
.CursorLocation = adUseServer
- форма доступна только на чтение (я явно не задавал в последнем случае - вот и выпало).

Все остальное - не понятно.

:0)про DAO

Note You cannot use this property with ODBCDirect recordset types in DAO.

там же. :0) (это меня уже раза 3 выбросило при попытке проверить Вашу мысль экспериментально)


т.ч. в DAO остается только возможность через Jet дергать подключенные по ODBC таблички. А это как раз то, от чего я пытаюсь уйти (вернее от некоторой ошибки драйвера ODBC при работе с динамическими наборами). (проверил - результат в точности такой, как при открытии присоединенной таблы стандартным способом. (Там, где Акес с ОДБС терял нить, при скролинге по записям, он там ее и теряет).

Т.ч. все в то и упирается, что надо подключаться не к линкованной табле, а задействовать другие методы. (в т.ч. другой способ синхронизации). Либо самому реализовывать ту кухню, какая скрыта от юзера - редактирование набора, полученного с сервера как статический и куда-то сброшенного (например в локальные таблы), и апдейт серверного набора по завершении редактирования посредством генерации запросов к серверу. Что напрягает.

2dark
а як жеж. :0)

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


Ихде вумные люди, шоп пояснить, шо усё не так!!! И шоб побырому пояснили, чем и по чём хлобыстнуть надоть? Аллё, пипл! Хоть ссылку на букварь киньте.

Похоже фихвам.

Зато, кажисть, нашел повод ошибки драйвера. А именно - поле типа text в таблице PostgreSQL (MEMO, по Access-овски). Если его не включать в выходной набор - проблемы и нет.

Наткнулся просматривая логи ODBC - вместо
'SELECT ... "description", ... FROM "leaf" ...
именно для этой таблы увидел
'SELECT ...,'#S_C_H#' , ... FROM "leaf_heap"
(имена полей одинакие, а вот типы 'varchar' супротив 'text').
Правда сообщение об ошибках не дает зацепиться за реальную причину:

ERROR from backend during send_query: 'ERROR: Unable to identify an ordering operator '<' for type 'unknown'
Use an explicit ordering operator or modify the query'
STATEMENT ERROR: func=SC_execute, desc='', errnum=7, errmsg='Error while executing the query'

- естественно никаких условий сравнения ">, <" и т.п. даже в запросах, генерируемых ODBC нет. Мммммдя. Результат зависит от чего угодно. Вывожу в источник данных только ключи и само поле "description": - никаких подстановок на '#S_C_H#' не наблюдаю. Результат читается. Какое-то время. Перехожу в друго окно, возвращаюсь - ошибка. Смотрю лог - опять появилось '#S_C_H#' , в протоколе ODBC. Трахтибидох.

Какой-никакой - а результат. Буду думать дальше.

Нет.

MSJET35.DLL 3.50.3428.0
msjet40.dll 4.0.6218.0

(глючит и там и там).
а что, есть надежа? (тут же юзерей как собак, да на разных точках, да спец. людей надо напрягать - я как-то "из другого отдела"...) "Ну, я попал" :0)

_
побырому воткнул MSJET35.DLL 3.51.2723.0 (хотя там еще и сопутствующие - т.ч. сие неверно) - не-а (глючит). Т.е. надо ставить усе. Но это ж еще и искать/качать промежуточные сп. :0(

2ЛП:\r
\r
после пропатчей (в т.ч. и аксов) единственно - перестало быть возможным открытие формы в АДП, не имеющем связаной БД МССКУЛь. ("Аксесс не может выполнить операцию, патамушта праэкт не падключен к базеданых на сервереСКУЛь") Раньше я форму открывал.\r
\r
Но все одно спасибо :0). Теперь буду горд офисами и джетами последней выпечки.\r
\r
Проблема, похоже была в другом