نقل قول از javad_rajabloo
در مورد اول فرض می کنیم کاربر اول بر روی یک رکورد جهت ویرایش کلیک می کنه
یک فیلد گذاشتیم که وضعیت ویرایش رو مشخص میکنه که در حالت غیر ویرایش فالس هست
وقتی کاربر کلیک کرد بر روی ویرایش ، اون فیلد بشه true .

تا اینجاش اوکی . اما کاربر دوم وقتی کلیک کرد بر روی همون رکورد ، چون تغییرات کاربر قبلی هنوز ذخیره نشده ، کاربر دوم اون حالت true رو نمی بینه . پس این راه حل شدنی نیست.

در مورد دوم اگه یه دی بی گرید داشته باشیم ، می تونیم یه تایمر بذاریم که هر چند ثانیه رفرش کنه.


منظور از true کردن یک فیلد یعنی ذخیره ی اطلاعات ، البته ضرورتی نداره که از این روش استفاده کنید ، منظور من از ارائه ی این روش هدف قفل گذاری بود .
SQLServer خودش تقریبا این قفل گذاری رو انجام میده و به جز در مواردی که شما قرار است تراکنشی انجام دهید نیاز به کد نویسی خاصی نخواهید داشت.
در شرایطی که شما قرار است تراکنشی ارسال کنید ، لازم است مراحل رو در قالب یک transaction ارسال نموده که این transaction اگر به مشکل برنخورد ( مثلا رکوردی که قرار است ویرایش شود حذف نشده باشد ) تراکنش Commit خواهد شد و در غیر اینصورت Rollback خواهد شد ...
یکی از جواب هایی که خود MSDN نوشته ، استفاده از فیلد Date هست که در اون آخرین تاریخ ویرایش شده رو نگه داریم و اگه کاربری خواست اون رکورد رو ویراش کنه تاریخ ها با هم مقایسه می شوند ، اگر برابر نبودن یعنی concurrency اتفاق افتاده ...
ضمنا ابزاری همچون ADOTable به صورت خودکار و از پیش تعریف شده خیلی به شما در رفع این مشکل کمک خواهند کرد و کافی است شما کدتان را در try/catch نوشته و exception ها رو هندل بکنید ...

در مورد دوم هم پیشنهاد من اینه که اگر تعداد کلاینت های شما حتی بیشتر از 5 است ، به هیچ عنوان همچنین اشتباهی رو انجام ندهید ، واگرنه بعد از Run شدن نرم افزار بر روی تعداد کثیری از کلاینت ها سرور شما و همچنین سامانه ی نرم افزاری اتان به کلی هنگ خواهد کرد ...