У нас на работе есть довольно неудачное устаревшее приложение, изначально написанное на VB6, оно старше всех в нашем ИТ-отделе как минимум на 5 лет. У нас есть контрактный разработчик для постоянного обслуживания, и где он может, он переписывает разделы в код .NET (не уверен насчет его методов, это подработка для его постоянной работы инженером IBM), приложение отлично работает (как есть) под Windows XP. У нас есть только пара машин с Windows 7, в основном для тестирования, и это приложение, похоже, упирается в стену. Такие вещи, как фоновая загрузка и ошибки SQL. Это даже работает под администратором.
Запуск трассировки SQL из панели управления ODBC показывает несколько интересных вещей. Он успешно подключается к базе данных изначально, где он запускает запрос, чтобы определить, запущена ли правильная версия. Этот запрос работает нормально.
558-1af0 ENTER SQLExecDirectW
HSTMT 0x020D7548
WCHAR * 0x04C8F0F0 [ 115] "SELECT count(*) c FROM tblSoftwareVersion WHERE fldSoftwareVersion = '123456' AND fldSoftwareName = 'Application.VB'"
SDWORD 115
BMS 558-1af0 EXIT SQLExecDirectW with return code 1 (SQL_SUCCESS_WITH_INFO)
HSTMT 0x020D7548
WCHAR * 0x04C8F0F0 [ 115] "SELECT count(*) c FROM tblSoftwareVersion WHERE fldSoftwareVersion = '123456' AND fldSoftwareName = 'Application.VB'"
SDWORD 115
Затем он, похоже, теряет соединение и не может найти соединение ODBC, несмотря на то, что он подключается к той же базе данных. Из трассировки видно, что он настраивает соединение, затем начинает запускать SQLFreeStmt для отмены привязки и закрытия, а когда он находится в приложении и пытается сделать свое дело, соединения нет.
558-1af0 ENTER SQLFreeStmt
HSTMT 0x020D7548
UWORD 2 <SQL_UNBIND>
BMS 558-1af0 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS)
HSTMT 0x020D7548
UWORD 2 <SQL_UNBIND>
А потом это происходит, когда я пытаюсь сделать что-то, что извлекает данные
558-1af0 ENTER SQLDriverConnectW
HDBC 0x020DDA00
HWND 0x00000000
WCHAR * 0x73EF8634 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x73EF8634
SWORD -3
SWORD * 0x00000000
UWORD 0 <SQL_DRIVER_NOPROMPT>
BMS 558-1af0 EXIT SQLDriverConnectW with return code -1 (SQL_ERROR)
HDBC 0x020DDA00
HWND 0x00000000
WCHAR * 0x73EF8634 [ -3] "******\ 0"
SWORD -3
WCHAR * 0x73EF8634
SWORD -3
SWORD * 0x00000000
UWORD 0 <SQL_DRIVER_NOPROMPT>
DIAG [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (0)
Почти все мои поиски по этой проблеме приводят к проблемам программирования, когда строка подключения имеет проблему. Единственное, что отличается в этом конкретном сценарии, это Windows 7, я знаю, что строка подключения в порядке, так как она работает на машинах XP. Компоненты VB должны по-прежнему функционировать под Win7. Мой компьютер работает под управлением 32-разрядной версии Win7, а мой VP — под управлением Win7 64-разрядной версии, и у обоих одна и та же проблема, так что это можно исключить.
Я уже пробовал переустановить SQL Native Client и VB runtime, а также приложение, о котором идет речь. Надеюсь, я смогу найти решение и мне не придется прибегать к использованию XP VM.
Редактировать - Ну, после многих попыток мы были вынуждены использовать XP VM в качестве решения. Либо компоненты VB не так совместимы, как они заявляют, либо это древнее приложение делает что-то странное.
решение1
Если это приложение, которое запускается с рабочего стола (т. е. не как служба), вы пробовали настроить приложение на запуск в режиме совместимости? У меня была похожая проблема с программой VB6 (одна и та же функция для чтения реестра вызывалась из двух разных частей программы, одна работает, другая нет, но из IDE VB6 обе работают), и просто щелчок правой кнопкой мыши и проверка совместимости Win7 и выбор режима XP SP2 исправили проблему.
решение2
Режим XP оказался единственным решением, которое сработало.