كيفية إصلاح & lsquo ؛ فشل التحويل عند تحويل التاريخ و / أو الوقت من سلسلة الأحرف & rsquo ؛ خطأ؟

هناك العديد من الحالات التي لا تظهر فيها التواريخ والأوقات بالتنسيق الذي تريده ، ولا يلائم إخراج الاستعلام احتياجات المشاهدين. هناك العديد من الميزات المضمنة في SQL Server لتنسيق سلسلة التاريخ وفقًا لحاجتك ولكن لكي يتم تفسير السلسلة بواسطة SQL Server ولتجنب أخطاء التحويل ، يجب أن تكون بتنسيق مناسب. عندما نحاول تحويل التاريخ أو الوقت من سلسلة الأحرف ، يظهر الخطأ التالي أحيانًا. "فشل التحويل عند تحويل التاريخ و / أو الوقت من سلسلة الأحرف".

تاريخ خطأ في تحويل الوقت

ينشأ الخطأ المذكور أعلاه عادةً عندما يكون التاريخ الحرفي غير مناسب ولا يمكن تحويله من السلسلة إلى DateTime أو date. ينتج هذا الخطأ عن عدد من الأسباب ، والتي سنناقشها بالتفصيل مع مجموعة الحلول.

مثال 1:

يعرض تدوين التاريخ والوقت في المملكة المتحدة التاريخ باستخدام تنسيق اليوم والشهر والسنة (10 يناير 2015 أو 10/1/2015) والذي يمكننا تحقيقه باستخدام وظيفة "التحويل" المضمنة في SQL Server بنمط التنسيق 103.

هنا في المثال أدناه يمكننا أن نرى أن سلسلة التاريخ المقدمة بتنسيق خاطئ. أولاً ، يقدم الشهر ثم الأيام وفي العام الماضي ما هو خطأ ولا يمكن تفسيره بواسطة SQL Server مما يؤدي إلى حدوث خطأ. التنسيق الصحيح لتحويل تاريخ النمط البريطاني باستخدام نمط التاريخ "103" هو "يوم / شهر / سنة".

صيغة خاطئة:

Declaredate_time_value varchar (100) = '10 / 16/2015 21:02:04 'حدد CONVERT (datetime2،date_time_value، 103) كـ UK_Date_Time_Style

التنسيق الصحيح:

تنسيق التاريخ البريطاني والفرنسي هو 103 = "dd / mm / yyyy" أو 3 = "dd / mm / yy". هنا 103 و 3 أنماط التاريخ.

Declaredate_time_value varchar (100) = '10 / 1/15 21:02:04 'حدد CONVERT (datetime2،date_time_value، 103) كـ Date_Time_Style
Declaredate_time_value varchar (100) = '10 / 1/15 21:02:04 'حدد CONVERT (datetime2،date_time_value، 3) كـ UK_Date_Time_Style

المثال الثاني:

في بعض الأحيان ، ينتج عن تحويل السلسلة حتى الآن في خادم SQL خطأ ، ليس بسبب تنسيقات التاريخ أو الوقت المستخدمة ، بل لأنك تحاول تخزين معلومات غير صحيحة غير مقبولة للنظام.

التاريخ غير صحيح:

سبب الخطأ التالي هو أنه في عام 2019 لا يوجد تاريخ مثل "29 فبراير" لأنه ليس سنة كبيسة.

قم بإعلانdate_time_value varchar (100) = '2019-02-29 21:02:04' حدد فريق التمثيل (date_time_value كتاريخ ووقت 2) كـ date_time_value

صحيح:

قم بتعريفdate_time_value varchar (100) = '2019-02-28 21:02:04' حدد فريق التمثيل (date_time_value كتاريخ 2) كـ date_time_value

تنسيق التاريخ ISO 8601:

على الرغم من توفر العديد من التنسيقات لمعالجة قيم التاريخ ، عند العمل لكتلة عالمية / دولية ، يمكن أن يكون اختيار تمثيل التاريخ والوقت مشكلة في قابلية الاستخدام. لذلك يجب تجنب القيم الحرفية للتاريخ / الوقت الخاصة بالثقافة. إذا اعتبرنا هذا التاريخ "03/08/2018" ، فسيتم تفسيره باتباع طرق مختلفة في مناطق مختلفة من العالم.

  • في أسلوب المملكة المتحدة ، يتم تفسيره على أنه "8 مارس 2018"
  • في النمط الأوروبي يتم تفسيره على أنه "3 أغسطس 2018"

لحسن الحظ ، هناك بديل واحد في تنسيق التاريخ الدولي الذي طورته ISO. يُعد تنسيق ISO 8601 القياسي العالمي "YYYY-MM-DDThh: mm: ss" خيارًا أكثر استقلالية عن اللغة للحروف الحرفية وهو يعالج كل هذه المشكلات. حيث أن "yyyy" هي السنة ، و "mm" هي الشهر و "dd" هي اليوم. لذا فإن التاريخ "8 مارس 2018" بتنسيق ISO الدولي مكتوب بالشكل "2018-03-08". وبالتالي فإن تنسيق ISO هو الخيار الأفضل لتمثيل التاريخ.

Declaredate_time_value varchar (100) = '2019-03-28 21:02:04' حدد تحويل (datetime2، @ date_time_value، 126) كـ [yyyy-mm-ddThh: mi: ss.mmm]

التوصيات:

نأمل أن تساعد هذه المقالة في تخفيف الارتباك الذي رأيته كثيرًا في المجتمع حول قيم التاريخ / الوقت. ومع ذلك ، يوصى بعدم تخزين التواريخ مطلقًا في نوع النص (varchar أو char أو nvarchar أو nchar أو text) قم دائمًا بتخزين قيمة التاريخ في DATE أو DATETIME ويفضل DATETIME2 (يوفر مزيدًا من الدقة) أعمدة الكتابة ، واترك تنسيق معلومات التاريخ إلى طبقة واجهة المستخدم بدلاً من استرجاعها من قاعدة البيانات.