J'essaie actuellement de tirer quelques données d'une vue de base de données SQL Server que nous avons restreint l'accès à partir de notre serveur Web Linux.
Nous n'avons pas besoin de modifier les données qui l'affichent simplement dans une page Web. < / p>
Tout semble bien jusqu'à ce que nous essayions de produire et que vous obtenez uniquement les 255 premiers caractères d'un champ de texte.
Est-ce que quelqu'un sait s'il s'agit d'un problème d'utilisation de Freetds via PHP :: PDO ou si cela devrait fonctionner bien? J'ai vu d'autres personnes qui ont des problèmes similaires, mais il ne semble pas y avoir de nombreuses réponses.
J'utilise ceci comme chaîne de connexion pour la MS SQL DB: < Pré> xxx
4 Réponses :
Vous pouvez augmenter la taille des champs de texte dans le fichier /etc/oDBC.ini utilisé par Freetds.
[name_of_connection] TextSize = 2097152
Nous essayons que, comme il semblait être la seule chose à essayer, mais il ne semble pas avoir d'effet. Bien qu'il soit tout à fait possible que je fais quelque chose de mal. Tous les autres processus doivent-ils être redémarrés après avoir changé l'ODBC.INI?
Selon le Guide de l'utilisateur de Freetds , le problème semble être que les Freetds peuvent Seulement gérer Vous pouvez résoudre le problème soit en modifiant votre schéma en conséquence, soit convertir le type de données lors de votre requête, comme celui-ci: P> varchar code> jusqu'à 255 caractères lorsque vous parlez à SQL Server "en raison des limitations inhérentes à la définition du protocole" em>. Tout ce qui est plus grand que celui qui doit être Type de données texte code>. SELECT CAST(mycol as TEXT) FROM mytable
Un problème similaire existe à l'aide de MS ODBC dans Windows Server 2016 sur SQL Server 2016, bien qu'il renvoie votre valeur avec NULL Byte insérés tous les 256 octets - et cette solution de contexte corrige le problème. L'autre option est d'utiliser str_replace ("\ 0", '', $ string) pour éteindre les octets nuls.
Freetds, par défaut, utilise le protocole version 4.2 Si vous par le biais du protocole de 7.0, vous pouvez récupérer plus de 255 octets d'un Varchar. Vous pouvez utiliser le piratage "Cast", ou vous pouvez modifier la colonne Col Varchar (MAX).
varchar (max) est un type de colonne complètement différent de Varchar (data_type 2005 vs 12) et sera diffusé sur des freeds 4.2 W / o tronquable.
Pourquoi ne pas passer à la version 7? Parce que UTF-8 ne peut pas être stocké à Varcharne avec de nouveaux protocoles. SQL Server transmettra toutes les informations de protocole dans UCS-2 (comme UTF-16) et convertira vos données dans la table ou dans la collection de colonnes avant d'économiser. Mais cela vous oblige à préfixer les données UTF8 avec N. Insérer dans les valeurs TBL (TXT) (N'Hello World ')
Pourquoi pas casser? Cast sous forme de texte n'est pas compatible avec MySQL (besoin de se lancer comme Char).
Rester sur le protocole 4.2 et définir vos varcharars comme Varchar (Max) vous permet de rédiger le SQL le plus compatible.
Merci d'cela, mais j'ai résolu ceci il y a quatre ans et que rien n'a à voir avec cette configuration.
Oui, mais je viens de hériter de ce problème et je voulais ajouter au pool de connaissances. Juste au cas où il existe toujours des systèmes qui hérissent de systèmes construits sur les technologies de 1998.
Un factoïde supplémentaire pour ce problème. À partir de 2015, le retour d'une valeur de type XML entraîne les 25 premiers caractères Dans mon cas particulier, je produisais XML (en utilisant plusieurs requêtes imbriquées XML) pour envoyer à un site Web pour l'affichage. Dans ce cas, la solution que j'ai trouvée était d'utiliser le piratage moulé, jetant les données sur Varchar (MAX).
N'oubliez donc pas: si vous voyez un bloc de 256 caractères clairs suivi d'une poubelle aléatoire dans vos résultats de requête, il s'agit probablement d'une valeur XML étant renvoyée sous forme de type XML au lieu d'un type de varchar (max).
CAVEAT: Cela ne peut s'appliquer que si le XML est généré de manière dynamique.