SQL Server 2005 مقابل.الارتباك في تنسيق التاريخ والوقت ASP.net

Question

لقد وجدت سؤالًا مشابهًا حول تجاوز سعة المكدس، لكنه لم يجيب حقًا على سؤالي.أحتاج إلى التأكد من أن تطبيق asp.net الخاص بي يقوم بتنسيق التاريخ dd/mm/yyyy مثل SQL Server 2005 الخاص بي.

كيف يمكنني التحقق من تطابق ثقافة التاريخ (إذا كان هذا ما يطلق عليه) للخادم مع الطريقة التي قمت بها ببرمجة تطبيقي؟هل هناك إعدادات محددة لقاعدة البيانات وإعدادات نظام التشغيل؟هل هو خاص بالجدول؟لا أريد أن أغير أيامي وأشهري.

شكرًا لك

Answer 1

عندما تحصل على DateTime من قاعدة البيانات، يجب أن يكون بتنسيق غير مثقف (مثل كائن DateTime، استنادًا إلى عدد علامات التجزئة منذ تاريخ معين).فقط عندما تقوم بتحويل هذه القيمة إلى سلسلة، يجب أن تهتم بالثقافة.في هذه الحالات، يمكنك استخدام yourDateTimeValue.ToString("dd/MM/yyyy", CultureInfo.InvariantCulture) للتأكد من عرض المعلومات بشكل صحيح.

Answer 2

أعتقد أنه إذا كنت تستخدم SqlParameters ADO.NET فسوف يعتني بالباقي ولا داعي للقلق بشأن ذلك.علاوة على ذلك، فهو جيد للدفاع ضد هجمات حقن SQL أيضًا!:)

Answer 3

** انتبه لأن أعمدة SQL DateTime غير قابلة للإلغاء والحد الأدنى لقيمتها هو 1/1/1753 بينما تكون .net DateTimes غير قابلة للإلغاء بقيم دنيا تبلغ 1/1/0001.**

إذا كنت تقوم بسحب البيانات من عمود DateTime حقيقي، فستكون دائمًا بنفس التنسيق القياسي افتراضيًا.لحفظ البيانات في العمود، قد ترغب في تحديد SqlDbType.DateTime في المعلمة الخاصة بك.

لقد انفصلت عن هذا http://bytes.com/forum/thread767920.html :

com.Parameters.Add("@adate"، SqlDbType.DateTime).Value = DateTime.Now;

Answer 4

حسنًا، إذا احتفظت بحقول التاريخ والوقت في قاعدة البيانات، فلا داعي للقلق بشأن ذلك.

طالما أنك تحتفظ بالتواريخ في التطبيق مكتوبة بقوة (متغيرات DateTime) وترسل التواريخ من خلال البيانات المعدة باستخدام DBParameter/SqlParameter، فسوف تأخذها قاعدة البيانات الخاصة بك كما هي.

إذا كنت تستخدم سلاسل لحفظ التواريخ الخاصة بك في التعليمات البرمجية، فستضمن بعض القوالب إرسال القيم الصحيحة:

string sqlCmd = @"SELECT *
   FROM MyTable
   WHERE MyDateField = CONVERT(datetime, '{0}', 101)";

// assuming myDateString is a string with a date in the local format
sqlCmd = string.Format(sqlCmd,
    Convert.ToDateTime(myDateString).ToString("yyyyMMdd"));

(الكود قبيح، ولكن نأمل أن يتم توضيح النقطة)

Answer 5

كما ذكر الآخرون، يجب أن تكون على ما يرام فيما يتعلق بتخزين أوقات التاريخ ثقافيًا.ما أوصي به هو أن تقوم بتخزين جميع أوقاتك بالتوقيت العالمي الموحد (UTC) القياسي.في SQL Server 2005 والإصدارات الأقدم، لا توجد طريقة لتخزين معلومات المنطقة الزمنية، ولكن إذا تم تخزين كل شيء بالتوقيت العالمي، فيجب أن تكون على ما يرام لأنه يمكن تحويل الوقت إلى التوقيت المحلي لاحقًا.

يحتوي SQL Server 2008 على بعض أنواع البيانات التي تعرف المناطق الزمنية، وإذا كنت تستخدم .NET 3.5، فهناك أدوات للمساعدة في معالجة/تحويلات المنطقة الزمنية.

بالتأكيد احتفظ بالأوقات بتنسيق عالمي.سيحدث هذا فرقًا كبيرًا إذا كان عليك العمل في مناطق زمنية متعددة.