MS SQL Server
  1. MS SQL Server
  3. Le type de slider ODBC_CONNECT est en conflit avec SQLGetData en PHP avec freeTDS et unixODBC
Intereting Posts
SSRS – renvoie plusieurs requêtes dans une procédure stockée Rejoindre plusieurs tables et get des données Count dans TSQL SQL Server 2012 prend-il en charge la réplication transactionnelle avec un abonnement pouvant être mis à jour? Degré de support C # dans la fonction SQL CLR définie par l'user? SQL Server: se connecter à l'instance locale en utilisant Flux SqlFileStream via WebAPI Sélection multiple par rapport à une table dans une requête Quelle est la différence entre un schéma Oracle et Microsoft? Mise à jour de SQL dans la table avec le cas Comment calculer hashbyte SHA1 en utilisant C #? TSQL Utilisations multiples de la table définie par WITH Comment écrire une requête SQL qui search un groupe de mots d'une autre table? SqlDataAdapter Récupère l'identité après l'insertion Erreur de requête SQL: nom de colonne non valide Chiffrement de mot de passe SQL-Server

Le type de slider ODBC_CONNECT est en conflit avec SQLGetData en PHP avec freeTDS et unixODBC

J'ai un projet PHP fonctionnant sur mon Gentoo Linux qui utilise FreeTDS & UnixODBC pour se connecter à une database MSSQL sur un server Windows. J'ai eu ce projet fonctionnant avec ce code exact pendant des années maintenant, mais récemment j'ai dû mettre à jour PHP quand Gentoo n'avait plus un ebuild de la version 5.3 dans le portage et d'autres mises à jour de système ont dû se produire.

Les versions actuelles des différents logiciels utilisés sont:
PHP est la version 5.6.17
FreeTDS est la version 0.91
UnixODBC est la version 2.3.2-r1

Mais maintenant certaines des mêmes requêtes qui fonctionnaient parfaitement returnnent cette erreur.

PHP Avertissement: odbc_fetch_object (): Erreur SQL: [unixODBC] [Gestionnaire de pilotes] SQLGetData n'est pas autorisé sur un slider avant uniquement (non tamponné), l'état SQL SL008 dans SQLGetData dans /home/XXXXX/XXXX.php sur la ligne Y

Toutes les requêtes ne returnnent pas cette erreur, seulement certaines, mais les mêmes requêtes returnnent systématiquement la même erreur.

Un programme PHP simple qui returnnera cette erreur est le suivant: 

$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); ?>

Maintenant, cela est certainement lié au quasortingème paramètre fourni à odbc_connect lors de l'utilisation de SQL_CUR_USE_ODBC , l'erreur est comme je l'ai dit ci-dessus. Lorsque cela est remplacé par SQL_CUR_USE_IF_NEEDED , l'erreur est renvoyée :

Attention: odbc_fetch_object (): Pas de tuples disponibles à cet index dans /home/XXXXX/XXXX.php sur la ligne Y []

Avec un résultat identique pour SQL_CUR_USE_DRIVER , ou s'il est laissé vide.

Encore une fois, il y a deux jours, c'était du code fonctionnel pour toutes les requêtes. Quelque chose a changé de PHP 5.3 à n'importe quelle version de php> 5.3. Chaque version de PHP a été essayée de 5.4 à 7.0 (il y a un ebuild PHP 7 dans portage) et tous produisent les mêmes erreurs.

Toute aide ou direction dans ce domaine serait grandement appréciée.

Le premier indice majeur que j'ai découvert était que cela n'arrivait que lorsque nous faisions un SELECT avec une colonne de text avec d'autres colonnes. L'utilisation de SELECT sur une colonne de text en elle-même n'a pas déclenché l'erreur. Et en sélectionnant chaque autre colonne à l'exception de la colonne de text n'a pas lancé l'erreur. Nous venions de passer de SQL Server 2000 à 2008, donc j'étais plus que désireux d'essayer VARCHAR (MAX) en faveur de la colonne de text que nous devions utiliser en 2000.

ALTER TABLE tbl_name ALTER COLUMN col_name VARCHAR(MAX) [NOT] NULL corrigé tous ces messages d'erreur. Il transfère VARCHAR (MAX) très bien même quand il y avait plusieurs Ko de text returnnés. L'ancienne implémentation de Text laissait la taille de la colonne à 2Go donc je suppose que FreeTSD 0.91 a une certaine ressortingction de taille.

Après des tests approfondis, la solution à ce problème était de remarquer que ce ne sont que des avertissements, pas des erreurs. Ils auraient dû être lancés, mais aussi exécuter le SQL.

Cependant un petit problème dans l'une de ces bibliothèques ODBC ou TDS provoquait des avertissements pour empêcher l'exécution du SQL. Ce n'est pas une solution géniale , mais en incluant SET ANSI_WARNINGS OFF au début de la requête, éteignez les avertissements, et maintenant le code s'exécute exactement comme avant. 

 $query = 'SET ANSI_WARNINGS OFF SELECT * FROM SomeTable';

Est ce que ma string de requête ressemble maintenant. Pas idéal, mais ça marche.