[karimx]

السلام عليكم ورحمة الله وبركاته
أخي أبو ليلى كلامك جميل وترفع له القبعة،
أحببت أن أضيف فكرة على حالة الصف في الـ Datagrid  يمكننا إضافة عامود غير منضم يمثل حالة الصف، ومن خلال هذا العامود نستطيع رصد طبيعة المتغيرات التي ستطرأ على الصف (التعديل - الإضافة - الحذف ) وسوف نرمز إليها بقيم معينة، فعند إضافة سجلات جديدة إلى الـ Datagrid سوف يسجل تلقائيا بناء لشروط أو معايير معينة فكل قيمة في عامود الحالة تدل على الحالة الحالية لكل صف على حدى، فإذا كانت القيمة الموجودة في عامود الحالة تدل على سجل جديد سوف يتم إضافته كسجل جديد إلى قاعدة البيانات، وإذا كانت القيمة أو القيم الموجودة في صف أو أكثر من صف تدل على سجل موجود مسبقا وطرأ عليه تغيير ما (معدل أو خضع للتعيدل) سوف يتم التعاطي معه على أنه سجل موجود مسبقا في قاعدة البيانات وسف يتم تحديثه وهكذا دواليك، ونسحب هذا الكلام أيضا على عملية الحذف.
سوف نستخدم الـ Loop ونضمنها جملة من الشروط، وهذه الشروط سوف نحدد من خلالها طبيعة العملية التي ستنفذ باتجاه قاعدة البيانات بناء للقيم الموجودة في عامود الحالة ونستطيع أن نعبر عنها بالمعايير التي سنستخدمها في جملة الشرط، وبالتالي إذا كانت القيمة في عامود الحالة هي (أ) سوف ينفذ عملية إضافة سجل جديد، وإذا كانت (ب) سوف ينفذ عملية تحديث لسجل، وإذا كانت (ج) سوف ينفذ عملية حذف.
بمعنى آخر نستطيع بناء جملة Loop يتخللها جملة من الشروط تتعاطى مع متغير أو أكثر قد يطرأ على Datagrid وبالتالي إذا تحقق شرط واحد سوف ينفذ عملية واحدة، وإذا تحقق أكثر من شرط سوف ينفذ أكثر من عملية باتجاه قاعدة البيانات مهما كان نوعها وفي نفس الوقت.
كما أنصح بوضع كل عملية (إضافة - تعديل - حذف) في دالة مستقلة ثم إنشاء Thread لكل دالة على حدى وتنفيذها من خلال الـ Thread وذلك من أجل رفع مستوى أداء العملية، واستخدام SqlTransaction لحماية العملية من أي خطر خارجي أو داخلي قد يؤدي إلى تلف أو فشل العملية.

ويعطيكم العافية

[ابو ليلى]

السلام عليكم و رحمة الله و بركاته
الاخ  karimx   , شكراً لمداخلتك اخي الكريم
اذا كانت غاياتك تجريبة فقط لمعاينة حالات الصفوف فلا بأس بذلك من باب معاينة ما يحصل.
اما اذا كنت تريد الاعتماد على هذه الطريقة التي شرحتها في مداخلتك فلا انصح بذلك لان اسماء الحالات مخزنة مسبقاً مع كل سطر
ففي الاحوال الطبيعية و بعد تعبئة الجدول بالبيانات تاخذ كل الصفوف الحالة UnChanched
و بعد القيام بالعمليات على السجلات انت اما 3 حالات متعارف عليها تستطيع الوصول اليها عبر الخاصية DataRowState
-  DataRowState.Added
-  DataRowState.Modified
-  DataRowState.Deleted

كل السجلات السابقة يتم العمل عليها و اعطاء الامر المناسب لكل حالة 
فمع الصفوف المضافة نحن بحاجة امر ادخال , مع المعدلة امر تعديل , مع المحذوفة امر حذف
هذا كل ما في الامر

بالنسبة لعملية فصل كل عملية في Thread مستقل 
لا ارى داعي لذلك , لانك داخل حلقة تكرارية و كل Thread ستاخذ عمل لسجل واحد فقط و هذا انهاك لموارد الجهاز .
فاذا كان لدينا 100 سجل تحتاج لمعالجة سيكون لدي 100 Thread (دمار للبرنامج).
و اذا كنت تفكر في عمل Thread واحد لكل نوع من العمليات فالعملية مضنية جداً و ستدخل في عمليات دمج متوالية لا تدري ما نهايتها.
بينما الحل بسيط جداً وهو الاكثر وثوقية و امناً , ان ندع الامور تسير بشكلها الطبيعي تبدأ عملية بعد انتهاء الاخرى 
و السرعة ممتازة جدأ لا تاخذ الا بضع ثواني 3-4 ثواني مع كم كبير  من السجلات .

بالنسبة لاطلاق عملية و فق مجموعة شروط لا يوجد مثل هذا الكلام , الصف ياخذ حالة واحدة فقط و هي اخر حالة جرت عليه
الــ Thread لا ترفع مستوى اداء العمليات , على العكس هي تبطأ من اداء البرنامج لانها عمليات متزامنة و كثرة استخدامها قد توقعنا في مشاكل نحن بالغنى عنها.

بالنسبة للــ TransAction انا تحدثت عنها في معرض بيانات مترابطة بين اكثر من جدول (و هو الاستخدام الاشيع لها)
بمعنى لو اردنا تنفيذ عملية على مجموعة سجلات مرتبطة بعميل واحد فالاولى ان تتم التعديلات على كل السجلات التابعة للعميل او لا يتم التعديل على اي سجل في حال حدوث خطأ في سير عملية التحديث (في حال كانت البيانات حساسة فقط).

بالنسبة للاخطاء الخارجية (الكهرباء او اخطاء في نظام الوندوز) فنحن في و رطة كبيرة لا يمكن السيطرة عليها قد يتعدى حرصنا على سلامة سجل او سجلين الى تلف كامل في القاعدة , اعاذنا الله منها.
اما ما قصدناه بالمشاكل اثناء سير العمليات الخاصة بنا هو وجدود خطأ ما في اكوادنا لم نحسب حسابه و غالباً هي اخطاء ادخال من مسؤولية المستخدم .
لم نتوقع ان يقوم المستخدم بهذه الحركة و بالتالي حدث خطأ غير محسوب حسابه ادى الى تقويض العملية , لهذا ترى ان الكود يزداد تحسناً مع كثرة زلات المستخدم و في هذا الباب ياتي دور Tester و ما ادراك ما الــ Tester
انت بتتعب و بتبرمج ايام طويلة و تعود للتصحصح و التنقيح مراراً و تكراراً و الاخ Tester  ما عليه غير يدور كيف بدو يجلطك و على فكرة راتبه كمان كبير كثير و ليس بالضرورة يكون يفهم بالبرمجة يمكن يكون صاحب بسطة او سائق تك تك   بس عنده هواية التنكيد ؟؟

تحياتي لك و لكل الاخوة.

[karimx]

نعم كلامك صحيح إذا كانت وجهة نظرك تنطلق من تقنية ADO.NET، ولكن لم ألتفت عندما وضعت مشاركتي أن وجهة نظري تنطلق من تقنية Dapper.