استعلام ODBC على خادم MS SQL إرجاع أول 255 حرفا فقط في PHP PDO (Freetds)

Question

أحاول حاليا سحب بعض البيانات من عرض قاعدة بيانات SQL Server التي قمنا بتقييد الوصول إليها من خادم Linux Web الخاص بنا.

لا نحتاج إلى تحرير البيانات فقط عرضها في صفحة ويب.

يبدو كل شيء على ما يرام حتى نحاول الإخراج وفقط احصل على أول 255 حرفا من حقل النص.

هل يعرف أحد إذا كانت هذه مشكلة في استخدام Freetds من خلال PHP :: PDO أو إذا كان يجب أن تعمل بشكل جيد؟ لقد رأيت أشخاصا آخرين هناك مشاكل مماثلة، ولكن لا يبدو أن هناك الكثير من الإجابات.

أنا أستخدم هذا كسلسلة اتصال ل MS SQL DB:

$dbConn = new PDO("odbc:Driver=FreeTDS;DSN=OURDSN;UID=WWWUser;PWD=ourpassword");

Answer 1

بحسب ال دليل مستخدم Freetds, ، يبدو أن المشكلة هي أن الأحرار يمكن أن تتعامل فقط varchar ما يصل إلى 255 حرفا عند التحدث إلى SQL Server "بسبب القيود الملازمة في تعريف البروتوكول". وبعد أي شيء أكبر من ذلك يحتاج إلى أن يكون نوع البيانات text.

يمكنك حل المشكلة إما عن طريق تعديل مخططك وفقا لذلك، أو تحويل نوع البيانات أثناء استفسارك، مثل هذا:

SELECT CAST(mycol as TEXT) FROM mytable

Answer 2

يمكنك زيادة حجم الحقول النصية في ملف /etc/odbc.ini المستخدمة بواسطة freetds.

[name_of_connection]
TextSize = 2097152

يمكنك أيضا محاولة استخدام إجراءات ODBC منخفضة المستوى PHP للتأكد من أنه يمكنك الحصول على هذا المستوى من استرجاع البيانات، ثم العمل مرة أخرى لاستخدام نظام التشغيل PDO.

Answer 3

يستخدم FreeTDS، بشكل افتراضي، الإصدار 4.2 البروتوكول إذا كنت حتى البروتوكول إلى 7.0، يمكنك استرداد أكثر من 255 بايت من Varchar. يمكنك استخدام الاختراق "يلقي"، أو يمكنك تغيير العمود Col varchar (كحد أقصى).

varchar (MAX) هو نوع عمود مختلف تماما عن varchar (data_type 2005 vs 12) وسيتم بثه على freetds 4.2 w / o اقتطاع.

لماذا لا ترقيات إلى الإصدار 7؟ نظرا لأن UTF-8 لا يمكن تخزينها في Varchar مع البروتوكولات الأحدث. سيقوم SQL Server بنقل جميع معلومات البروتوكول في UCS-2 (مثل UTF-16) وتحويل بياناتك إلى جدول أو ترتيب العمود قبل الحفظ. ولكن هذا يتطلب منك بادئة بيانات UTF8 مع N. Insert في قيم TBL (TXT) (N'Hello World ')

لماذا لا يلقي؟ يلقي كما النص غير متوافق مع MySQL (الحاجة إلى القيام به ك Chars).

البقاء على البروتوكول 4.2 وتحديد Varchars الخاص بك Varchar (MAX) دعونا تكتب SQL الأكثر توافقا.

Answer 4

واحد أكثر واقعية لهذه المسألة. اعتبارا من عام 2015، إرجاع قيمة نتائج نوع XML في أول 256 الشخصيات التي يتم إرجاعها نظيفة. ومع ذلك، سيتم إرجاع معظم بقية XML على أنه القمامة العشوائية على ما يبدو، مع جزء واضح من النص. في الواقع، إذا اضطررت إلى الخمول، فإن الاستعلام إرجاع كتلة عشوائية من الذاكرة لجميع الأحرف بعد 256.

في حالتي المحددة، كنت قد قمت بتوليد XML (باستخدام العديد من الاستفسارات المتداخلة XML) لإرسالها إلى موقع ويب للعرض. في هذه الحالة، كان الحل الذي وجدته هو استخدام الاختراق يلقي، يلقي البيانات إلى varchar (كحد أقصى).

لذا تذكر: إذا رأيت كتلة من 256 حرفا شفاف متبوعا بمزينة عشوائية في نتائج الاستعلام الخاصة بك، فمن المحتمل أن يتم إرجاع قيمة XML كوعي XML بدلا من نوع Varchar (MAX).

التحذير: قد ينطبق هذا فقط إذا تم إنشاؤه XML بشكل حيوي.