Мне поручено поддерживать устаревшее классическое приложение ASP. Приложение использует системный DSN ODBC для подключения к базе данных MySQL.
Нам пришлось недавно обновить серверы, чтобы удовлетворить некоторые лицензионные требования. Мы были на Windows с MySQL 4.x и драйвером ODBC 3.51. Мы перешли на Linux-машину с MySQL 5.1.43 и работаем с драйвером ODBC 5.1.6 на новом сервере IIS.
Пользователи практически сразу начали сообщать об ошибках как таковых:
Строка не может быть расположена для обновления.
Некоторые значения могли быть изменены
с момента последнего прочтения.
Это ложная ошибка, и одни и те же данные в одной и той же записи в разное время не всегда приводят к ошибке. Это также прерывисто между различными записями, так как иногда, независимо от того, какие значения я включаю, я не смог воспроизвести дефект во всех записях.
Это происходит в 70 из примерно 120 сценариев, многие из которых имеют длину более 1000 строк.
Единственное согласование, которое я могу найти, состоит в том, что на всех сценариях, которые терпят неудачу, они все читают / записывают плавающие в БД. Поля, которые имеют нулевое значение, похоже, не сбоят, но если в базе данных есть значение типа «19» (обратите внимание на отсутствие десятичных разрядов), которое, похоже, не работает, тогда как «19 .00» - нет. Большинство поплавков определены как 11,2.
Скрипты используют ADODB и наборы записей. Обновления выполняются по следующей схеме:
- выбрать * из таблицы, где ID =
обновленный идентификатор записи
- обновить свойства записи из формы
- вызовите RecordSet.Update и RecordSet.Close
Ошибка генерируется командой RecordSet.Update.
Я создал обходной путь, при котором вместо выбора / копирования / обновления я генерирую оператор SQL, который я выполняю. Это работает безупречно (очевидно, что оператор UPDATE с предложением where более сфокусирован и не учитывает поля, не обновленные), поэтому у меня есть довольно хорошее чувство, что это проблема округления с плавающей точкой, которая вызывает несоответствие с повторный поиск записи по вызову обновления.
Я на самом деле предпочел бы НЕ перезаписать 100 экземпляров этих экземпляров (поиск по всему источнику напрямую находит 280+ вызовов обновления).
Кто-нибудь может подтвердить, что проблема здесь связана с плавающими / округлениями?
И если да, могу ли я применить глобальное исправление?
Заранее спасибо,
-jc