ODBC Сбой вызова - случайные ошибки переполнения даты после перехода из 32-битного ODBC 5.1 на 64-битную 5,3

Question

Справочная информация:

• Наследство код работает в MS Access 2003.
• SQLs ведении CurrentDb в Access.
• В настоящее время работает на Windows 7 32-разрядной машине.
• Подключение к MySQL Server 5.5 через драйвер ODBC 5.1.

Проблема:

• Попытка перенести на сервер Windows, 2012 64 бит.
• ODBC 5.3 Драйвер Unicode (32 бит).
• Не хотите использовать время, переписывая все, так как есть много кода, и он удастся удалить в удаленном будущем.

Издание:

• Несколько SQL заявления сбой при работе на новых серверах. Работал на старых серверах.
• Все неудачные sqls имеют теперь() в инструкции.
• Описание ошибки говорит, что вызов ODBC завершился неудачно. Хотя более подробное описание говорит о переполнении даты - «[MySQL] [ODBC 5.3 (w) Драйвер] [mysqlid-5.5.28-log] Переполнение даты».
• Случается случайным образом, и когда это происходит, и Access останавливается, обычно можно просто продолжить, и sql будет работать. Он терпит неудачу менее чем в 1% случаев (тысяч).
• Единственные даты в sql указаны в предложении where: "и fieldA> now()", где fieldA - столбец datetime. Это запрос sql sql. Другая ошибка во время вставки такая же, но где целое число вычиталось из теперь() перед сравнением с datetime.

Я не понимаю, почему он говорит о переполнении даты, когда не существует причины, по которой время или время или «сейчас» должно быть удалено? А так как поле datetime уже находится в базе данных, и теперь() будет получать текущую дату и время, не должно быть никаких недопустимых дат?

Любая помощь в том, что может быть проблемой или как отлаживать/регистрировать все, что может помочь, будет высоко оценено.

Поворот трассировки в драйвере ODBC не является вариантом, потому что это происходит случайным образом, так много трафика, поэтому это замедлит все, что ничего не произойдет.

Обратите внимание, что я также столкнулся с одним sql, где сообщение об ошибке переполнения даты было правильным. Похоже, что до 5.3 при вставке даты и времени в поле даты он автоматически усекался, потому что sql, который был успешным 3000 раз, начал сбой. Поэтому этот sql был исправлен путем извлечения даты из поля в первую очередь. Но другие ошибки должны быть чем-то другим.

Answer 1

Новая версия, содержащая устранении ошибки, была выпущена Oracle: 5.3.8

Эта ошибка была ошибка, которая, кажется, была введена в версии 5.1.11.

В дополнительных опциях теперь установлен флажок переполнения даты, который должен быть отмечен для продолжения кода при возникновении ошибки.

Ответить с Oracle о затруднительном: «Для вашей информации затруднительного подход в том, что в C или C++ можно читать или писать типа DATE с помощью SQL_TIMESTAMP_STRUCT Этой структура может содержать как дату и время ошибки.. (Переполнение даты) генерировалось, когда с операциями, которые должны быть DATE, только эта структура получила ненулевые значения для времени. Это канонический подход, поскольку API ODBC требует, однако, иногда это вызывает неудобства, когда, например, приложение не надо беспокоиться , чтобы инициализировать всю структуру с 0 значениями, потому что она знает, что ей потребуется только часть DATE, но случайные значения для доли TIME могут вызывать ошибки, несмотря на то, что они усечены. Новая опция была в чтобы продолжить выполнение запроса, а затем вернуть ошибку. Сервер будет игнорировать часть TIME, и результат будет таким же, как если бы были нули. "

Answer 2

Возможно, это проблема с версиями MySQL Connector/ODBC версии 5.2 и выше. Веб-поиск привел к this thread на другом сайте, который, в свою очередь, привел к this unresolved bug report. Обратите внимание, что это более широкая проблема с MySQL Connector/ODBC; это не относится к приложениям Access.

Разъем MySQL/ODBC 5.1.13 по-прежнему доступен для загрузки, поэтому наиболее целесообразным решением, вероятно, будет просто использовать эту версию, пока этот код не будет выведен из эксплуатации. Ваши другие варианты могут включать в себя:

• с использованием новой версии сервера MySQL (с [? Лучше] поддержка дробных секунд), или
• настройки запросов SQL Access использовать что-то другое, чем функция Now() (которая вы, понятно, хотели бы избежать).