sql server — конфликт типа курсора ODBC_CONNECT с SQLGetData в PHP с freeTDS и unixODBC
У меня есть проект PHP, работающий на моем Gentoo Linux, который использует FreeTDS & UnixODBC для подключения к базе данных MSSQL на сервере Windows. У меня был этот проект, работающий с этим точным кодом уже много лет, но недавно мне пришлось обновлять PHP, когда у Gentoo больше не было версии 5.3, встроенной в portage, и должны были произойти другие системные обновления.
Текущие версии используемого программного обеспечения:
PHP это версия 5.6.17
FreeTDS — версия 0.91
UnixODBC — это версия 2.3.2-r1
Но теперь некоторые из тех самых запросов, которые раньше работали идеально, возвращают эту ошибку.
Предупреждение PHP: odbc_fetch_object (): ошибка SQL: [unixODBC] [Драйвер
Manager] SQLGetData не допускается только для форварда (без буферизации)
курсор, состояние SQL SL008 в SQLGetData в /home/XXXXX/XXXX.php на линии
Y
Не все запросы возвращают эту ошибку, только некоторые, но одни и те же запросы последовательно возвращают одну и ту же ошибку.
Простая PHP-программа, которая выдаст эту ошибку, выглядит следующим образом:
$con = odbc_connect(DBNAME,UNAME,PW,SQL_CUR_USE_ODBC)
$query = "SELECT * FROM SomeTable"$Output = odbc_exec($con,$query);
$return_array = array();
while($row = odbc_fetch_object($Output)){
#
foreach($row as &$value){
$value = mb_convert_encoding($value, "UTF-8", "Windows-1252");
}
unset($value);
$return_array[] = $row;
}
echo json_encode($return_array,JSON_UNESCAPED_UNICODE);
odbc_close($con);
?>
Теперь это определенно связано с 4-м параметром odbc_connect когда используешь SQL_CUR_USE_ODBC, ошибка, как я уже говорил выше. Когда это изменяется на SQL_CUR_USE_IF_NEEDED возвращает ошибку:
Предупреждение: odbc_fetch_object (): нет доступных кортежей с этим индексом результата в /home/XXXXX/XXXX.php в строке Y []
С идентичным результатом для SQL_CUR_USE_DRIVER, или если он оставлен пустым.
Опять же, два дня назад это был весь функциональный код для всех запросов. Итак, что-то изменилось с PHP 5.3 на любую версию php> 5.3. Каждая версия PHP была опробована с 5.4 до 7.0 (есть сборка PHP 7 в portage), и все выдают одинаковые ошибки.
Любая помощь или направление в этом вопросе будет принята с благодарностью.
Решение
Первый главный совет, который я обнаружил, состоял в том, что это произошло только тогда, когда мы сделали SELECT с текстовым столбцом вместе с другими столбцами. Использование SELECT для текстового столбца само по себе не выдает ошибку. И выбор любого другого столбца, кроме текстового столбца, не выдает ошибку. Мы только что перешли с SQL Server 2000 на 2008, поэтому я был более чем готов попробовать VARCHAR (MAX) в пользу текстового столбца, который мы должны были использовать в 2000 году.
ALTER TABLE tbl_name ALTER COLUMN col_name VARCHAR(MAX) [NOT] NULL исправил все эти сообщения об ошибках для нас. Он отлично передает VARCHAR (MAX), даже если возвращено несколько КБ текста. Старый Text Реализация оставила размер столбца в 2 ГБ, поэтому я предполагаю, что FreeTSD 0.91 имеет некоторые ограничения по размеру.
Другие решения
После тщательного тестирования, решением этой проблемы было заметить, что это всего лишь предупреждения, а не ошибки. Они должны были быть выброшены, но затем также выполнить SQL.
Однако некоторый сбой в одной из этих библиотек ODBC или TDS вызывал предупреждения, препятствующие выполнению SQL. Это не отличное решение, но в том числе ВЫКЛЮЧИТЬ ANSI_WARNINGS в начале запроса отключаются предупреждения, и теперь код выполняется точно так же, как и раньше.
$query = 'SET ANSI_WARNINGS OFF
SELECT * FROM SomeTable';
Вот как выглядит моя строка запроса. Не идеально, но это работает.
Я столкнулся с этой проблемой. Добавление «SET ANSI_WARNINGS OFF» до того, как мой запрос решил проблему. Благодарю.
Версия для гостей: 0.91.112
Версия PHP 5.3.29