Access 2007: несоответствие типов при открытии подключения ADO

У меня есть файл Access ADP. Я обновил внутреннюю базу данных, чтобы она указывала на сервер SQL 2005 вместо сервера SQL 2000, и соответствующим образом изменил информацию о подключении к базе данных. Файл отлично работает в моей собственной системе, работающей под управлением Windows 7 (64-разрядная версия) и Access 2007. В целевых системах под управлением Windows XP и Access 2007 основная функциональность базы данных почти сразу же взрывается с сообщением «Ошибка выполнения» «13»: ошибка несоответствия типа.

Сначала я думал, что страдаю от той же проблемы, что описана в этом вопросе здесь, где определение соединения по умолчанию - DAO, но база данных использует объект ADO. Однако при просмотре кода каждый экземпляр соединения специально объявляется как «ADODB.Connection».

Рассматриваемый код, вызывающий ошибку, таков:

Public Sub Tools()
dim db as ADODB.Connection
dim sql as String

sql = "Select SSPatch from tblPlastech"
set db = CurrentProject.Connection           ' THIS LINE CAUSES THE TYPE MISMATCH ERROR
dim rst as ADODB.RecordSet
set rst = New ADODB.RecordSet

rst.open sql, db, adOpenKeyset, adLockOptimistic
gsSSpath = rst!sspath
QUOTES = Chr(34)
rst.Close
set rst = Nothing
db.Close
set db = Nothing

End Sub

Может ли кто-нибудь пролить свет на эту проблему? Прямо сейчас я в тупике.


person Hellion    schedule 31.05.2011    source источник
comment
Что, если вы замените rst.open sql, db, adopenkeyset, adlockoptimistic на rst.open sql, currentproject.connection, adopenkeyset,adlockoptimistic? Это вызывает ту же ошибку?   -  person Tim Lentine    schedule 31.05.2011
comment
@tim lentine, используя currentproject.connection непосредственно в вызове rst.open, заставляет все работать правильно. Фактически, это сработало так хорошо, что в какой-то момент в процессе отладки я снова переключился на сломанный код, приведенный выше, и он тоже сработал .... (хотя восстановление до заведомо сломанной копии базы данных снова сломало ее). просто не знаю, какой внутренний бит мог быть установлен, чтобы восстановить работоспособность сломанного кода.   -  person Hellion    schedule 01.06.2011
comment
Все еще пытаетесь понять ... какую версию библиотеки объектов данных ActiveX вы используете?   -  person Philippe Grondier    schedule 01.06.2011
comment
@Hellion: Мне жаль, что у меня не было ответа для вас. У меня такое случалось и раньше, поэтому я и предложил это. Если вы выясните основную причину, напишите ответ.   -  person Tim Lentine    schedule 01.06.2011
comment
@ Тим Лентин, если вы хотите повторно опубликовать свой комментарий в качестве ответа, я продолжу и принимаю его, поскольку именно ваша идея привела меня к подходящему обходному пути: удалите переменную db и используйте CurrentProject.Connection напрямую. (К сожалению, нет ключа к первопричине.)   -  person Hellion    schedule 03.06.2011
comment
@Hellion, только что отправил как ответ, но мне это немного смешно. Мне жаль, что у меня не было причины, почему это сработало \ почему вы вообще получали ошибку, поэтому не думайте, что вы должны принимать мой пост в качестве ответа.   -  person Tim Lentine    schedule 03.06.2011
comment
@TimLentine, я опубликовал новую информацию, которая может оказаться полезной, если вы снова столкнетесь с этой проблемой .... :-)   -  person Hellion    schedule 06.06.2011


Ответы (5)


Вот что я наконец выяснил, что кажется актуальным:

В 64-битной Windows 7 Pro инструмент Microsoft MDAC Component Checker сообщает мне, что я использую версию MDAC UNKNOWN с версиями файлов 6.1.7600.16385 или 6.1.7601.17514 (которые по странному совпадению очень близко совпадают с номер версии Windows). В 32-битной Windows XP, с другой стороны, Component Checker сообщает, что я использую версию «MDAC 2.8 SP1 ON WINDOWS XP SP3» с версиями файлов 2.81.1132.0 или 2.81.3012.0, которые выглядят как правильные номера версий MDAC.

Если я изменю "сломанный" код, когда я нахожусь в XP, и тем самым принудительно перекомпилирую, тот же самый код, который вызвал ошибку времени выполнения (либо ошибка несоответствия типа 13, упомянутая выше, либо ошибка времени выполнения 430), будет начать работать (и продолжать работать, когда я копирую его в другие коробки XP или в свой ящик Windows 7). Если я изменю код в моем окне Windows 7 и перераспределю его в бокс XP, он сломается, несмотря на то, что каждая ссылка в списке ссылок имеет одинаковое имя и указывает на идентичный файл в идентичном месте на диске.

Изменить: по-видимому, эта нумерация версий связана с тем, что Windows Vista / 7 использует "WDAC" вместо "MDAC", и конкретная проблема кода, скомпилированного на Win7 SP1, нарушается при запуске в ОС нижнего уровня, является известной проблемой, на которую есть ссылка в support.microsoft.com, статья 2517589 и этот пост на сайте technet < / а>. Предлагаемые исправления - переключение на позднее связывание, установка исправления KB в системах нижнего уровня или связывание в «обратно-совместимых» версиях ADO.

Изменить 2: исправление, на котором я остановился на этом этапе, заключается в том, чтобы продолжить и выполнить всю свою работу по разработке (с ранней привязкой) на моем ящике Win7SP1, а затем перекомпилировать все приложение в ящике WinXP перед его развертыванием для моих пользователей.

person Hellion    schedule 06.06.2011
comment
это очень интересно. Интересно, что бы произошло, если бы вы использовали позднее связывание вместо установки ссылки на ADO. Я подозреваю, что когда код компилируется в Windows 7 и выполняется в Windows XP, он будет работать правильно. Мне также интересно, проблема ли это в Windows 7 ИЛИ проблема в 64-битной версии. В любом случае, спасибо за исследование! - person Tim Lentine; 07.06.2011
comment
@TimLentine, дополнительная информация и ссылки добавлены в ответ. Похоже, что это на самом деле известная проблема с компонентами доступа к данным W7 SP1, вы просто не можете найти ее, когда заняты поиском ошибки времени выполнения 13 или 430. :-) (Кроме того, поздняя привязка действительно является одной из официальные предложения!) - person Hellion; 08.06.2011
comment
отличное исследование! Спасибо за публикацию. :) - person Tim Lentine; 08.06.2011
comment
+1 за большую детализацию с последующими правками. Престижность вам за то, что вы привели меня прямо к статье kb, подробно описывающей это. В итоге я установил их обратно совместимую библиотеку типов и перекомпилировал ее; Ящики xp теперь снова работают. - person Lynn Crumbling; 21.12.2011

Лучше просто завершить объект ADO Connection и таким образом подключиться к SQL Server. Задайте свойство ConnectionString объекта подключения и откройте его. Не беспокойтесь об использовании CurrentProject.Connection. Все, что вы пытаетесь сделать в этом случае, - это объявить соединение для уже существующего соединения. Просто объявите соединение ADO полностью и используйте его, как если бы оно использовалось из приложения VB или C ++ с использованием ADO.

person HardCode    schedule 31.05.2011
comment
Извините, но я использую HardCode на этом. Если вы используете ADO, я не уверен, почему вы пытаетесь использовать соединение CurrentProject. Если бы вы использовали DAO, я думаю, это имело бы больше смысла. - person HK1; 01.06.2011
comment
DAO не может использоваться в ADP, что и связано с этим вопросом. - person David-W-Fenton; 03.06.2011

У вас есть соответствующая библиотека объектов данных ActiveX Micorsoft, объявленная в ваших инструментах? Появляется ли какое-либо всплывающее окно в редакторе кода при написании ADODB. Со всеми методами, объектами и свойствами ADODB, перечисленными в поле со списком?

После ваших комментариев проблема в том, что db ожидает объект ADODB.connection, а currentProject.connection - от другого типа объекта! Действительно странно, не правда ли?

Не могли бы вы выполнить отладку с помощью команд typeOf \ typeName и проверить точный характер currentProject.connection. В своих тестах я получаю следующие результаты в окне отладки:

? typeOf currentproject.Connection is ADODB.Connection
True

? typeName(currentproject.Connection)
Connection

Что логично, и я не понимаю вашей ошибки ....

person Philippe Grondier    schedule 31.05.2011
comment
У меня это объявлено, и я получаю всплывающие окна для завершения методов и свойств ADODB.x. - person Hellion; 01.06.2011
comment
Тогда вы уверены, что строка 'set db' вызывает несоответствие типов? Это очень странно! - person Philippe Grondier; 01.06.2011
comment
Учитывая, что кнопка «Отладка» переходит непосредственно к этой выделенной строке, и что ее комментирование позволяет успешно продолжить выполнение, вполне вероятно, что именно эта строка действительно является проблемой. - person Hellion; 01.06.2011
comment
Я сделал то же самое в ответ на теперь удаленный ответ, и оба ответа вернулись, как вы и ожидали («правда», «связь»). Сейчас у меня есть обходной путь, который я использую на данный момент, вместо того, чтобы серьезно пересматривать код, а именно: dim db as ADODB.connection; set db = new ADODB.connection; set db = currentproject.connection Этот дополнительный набор для new, похоже, помогает. - person Hellion; 01.06.2011
comment
Я уже думал об этом, но, поскольку инструкция 'set db' относится к уже существующему объекту подключения, прохождение шага 'New' звучит для меня странно: вы не хотите создавать новый экземпляр ADODB. здесь, и мой код отлично работает без этой строки «New» ...). Я помню, как однажды у меня были подобные сомнения, но я думаю, что это было с объектами ADOX. Так или иначе ... - person Philippe Grondier; 01.06.2011
comment
Код отлично работает без нового шага везде, кроме WinXP с Access 2007, поэтому я предпочитаю винить именно эту комбинацию. Однако я понятия не имею, какой аспект этой комбинации вызывает проблему. - person Hellion; 01.06.2011
comment
Чтобы сделать это еще более разочаровывающим, после того, как я сам проверил свой обходной путь и отправил его моим пользователям для тестирования, сама строка кода, которую я добавил, чтобы заставить все работать, внезапно начала вызывать новую ошибку (ошибка 430, я думаю, что это так). В этот момент я вскинул руки и согласился с подразумеваемым предложением Тима Лентина не беспокоиться об объявлении новой переменной и просто использовать currentproject.connection напрямую. Все идет нормально.... - person Hellion; 02.06.2011

Попробуйте заменить:

rst.open sql, db, adopenkeyset, adlockoptimistic

с участием:

rst.open sql, currentproject.connection, adopenkeyset,adlockoptimistic?

person Tim Lentine    schedule 03.06.2011

В редакторе VBA перейдите в Инструменты-Настройки и отключите «Библиотека объектов данных MS ActiveX 2.8», затем включите «Библиотека объектов данных MS ActiveX 2.7». По крайней мере, у меня сработало.

person Umid    schedule 18.01.2013