جلوگیری از ویرایش یک رکورد تو سط چند تا کلاینت

[MTPROG]

تو برنامه های تحت شبکه هنگام درج در جدول مشکلی به اون صورت به وجود نمیاد چون خود SQL قفلهایی رو تو جدول میزاره و کلاینتها میرن تو صف و اطلاعات به نوبت ثبت میشه

ولی مشکل تو ویرایش یک رکورد مشترک هستش
فرض کنید فاکتور شماره 1 با 10 رکورد وجود داره ویک کلاینت میخوان اونو ویرایش کنه قبل ذخیره تغییرات
کلاینت اطلاعات فاکتور رو میریزن تو یک Dataset برنامه ش و تغییرات رو تو DataSet اعمال میکنه

در حین اینکه کلاینت مورد نظر در حال ویرایش است یک کلاینت دیگه باز میخواد اونو ویرایش کنه
اگر در یک زمان هردوشون بخوان اطلاعاتو ویرایش کنن مشکلات محاسباتی و انباری به وجود میاد

چطور میشه جلوی ویرایش کلاینت دوم رو گرفت ؟

البته میشه با گذاشتن یک جدول کنترلی در بانک این رکوردها رو موقتا قفل کرد فرضا وقتی یک کلاینت میخواد رکوردی رو ویرایش کنه ابتدا به جدول کنترلی نگاه میکنه اگر قفل نبود بعد ویرایش کنه و اگر قفل بود پیغامی از برنامه دریافت کنه مبنی بر اینکه رکورد مورد نظر در حال به روز رسانی است و بعدا امتحان کنه

حالا اگه کسی فکر بهتری داره لطفا بگه

با تشـــــــــــــــــــــــ ـــــــــــــــتکر

[mahdi7s]

سلام

خوب شما که دستورات سرور رو تو یه جدول می ریرزید توی اون جدول یه فیلد برای آدرس کلاینتی که باید اونو اجرا کنه بذارید که کلاینت ها چکش کنن اگه آدرس خودشون بود این کارو انجام بدن.

یا در همون جدول یه فیلد بولیین قرار بدین و اولین که کلاینتی که اونو تغییر میده مقدار این فیلدو عوض کنه تا دیگر کلاینتها بی خیال بشن.

حالا چرا از سوکت استفاده نمی کنید؟

[MTPROG]

خوب شما که دستورات سرور رو تو یه جدول می ریرزید توی اون جدول یه فیلد برای آدرس کلاینتی که باید اونو اجرا کنه بذارید که کلاینت ها چکش کنن اگه آدرس خودشون بود این کارو انجام بدن.

همون جدول کنترلی که گفتم همین کارو میکنه تازه اون بهتر از این روش هست چون هر چقدر رکوردها در روش شما بشتر بشه تعداد سطرهای فیلد آدرس هم بیشتر میشه و سر بار سیستم میشه و با ساخت جدول کنترلی فقط یک رکورد به ازای مجموعه از رکوردهای قابل ویرایش وجود دارد

حالا چرا از سوکت استفاده نمی کنید؟

میشه بگید چور میشه از سوکت استفاده کرد در حالی من با بانکهابیSQL کار میکنم

با تشکر

[mahdi7s]

میشه بگید چور میشه از سوکت استفاده کرد در حالی من با بانکهابیSQL کار میکنم

منظورتون اینه که نمیشه؟!
این کارو میشه انجام داد و البته کد نویسی زیادتر و دقیقتر می خواد.

به هر حال وقتی دارین با پایگاه داده کار می کنید راه حل ساده تر همون کاری است که خودتون انجام دادین.
خوب حالا که میگید چنین کاریو انجام دادین پس مشکلتون چیه؟

[MTPROG]

منظورتون اینه که نمیشه؟!
این کارو میشه انجام داد و البته کد نویسی زیادتر و دقیقتر می خواد.

نه منظورم اینه که چطور میشه

خوب حالا که میگید چنین کاریو انجام دادین پس مشکلتون چیه؟

اگر منظورتون همون تایپک در مورد ارسال اطلاعات به کلاینت هستش

اونجا بحث بر سر این بود که به کلاینت فرمان انجام کاری رو بدید که باید انجام بده برای اینجا کاربرد نداره
ولی Socket Programing به منظور جلوگیری از ویرایش کاربر دیگه مفید نیست و لی برای اطلاع رسانی فوری مناسبه
فرض کنید 100 کلاینت داریم اگر قرار باشه از Socket Programing استفاده بشه بایدبرنامه سرور به 100 کلاینت پیغام بفرسته که فلان رکورد قفله و بعد از باز شدن دوباره همین پیغام رو بده در حالی که اون کلاینت شاید اصلا کاری به اون رکورد نداشته باشه

همون جدول کنترلی فعلا بهتره چون هر وقت نیاز بود کلاینت بررسی میکنه

ولی این جدول کنترلی هم به اندازه خوش دردسر داره مثلا کلاینت به دلایلی نرم افزاری یا سخت افزاری نتونه قفل رو از جدول کنترلی حذف کنه دیگه اون رکورد قابل ویرایش نیست البته میشه هنگام اجرای برنامه سرور این جدول ریست بشه

در کل این روش جواب میده ولی میخواستم بدونم آیا روش بهتر و بهینه تری هست یا خود SQL امکاناتی برای این جور مواقع داره یا نه

با تشکر

[MTPROG]

یه راه دیگه اینه که هر دو کاربر بتونن شروع به ویرایش کنن ولی نه از روی جدول اصلی بلکه بر روی یک view.
یک view از جدول اصلی میگیرن و اون رو ویرایش میکنن. فرض کنیم view کاربر دوم به اسم view2 باشه و این view به وسیله select2 ساخته شده باشه. کاربر اول تغییرات خودش رو ثبت کنه. حالا وقتی کاربر دوم میخواد تغییرات خودش رو ثبت کنه،برنامه یه بار دیگه درخواستselect 2 رو اجرا میکنه. اگر با اونی که کاربر روش کار کرده تفاوت داشت بهش اطلاع میده که جدول از آخرین باری که شما دید تغییر کرده آیا میخواید جدول جدید رو ببینید؟

[_H2_]

سلام

کلاینت اطلاعات فاکتور رو میریزن تو یک Dataset برنامه ش و تغییرات رو تو DataSet اعمال میکنه

در حین اینکه کلاینت مورد نظر در حال ویرایش است یک کلاینت دیگه باز میخواد اونو ویرایش کنه
اگر در یک زمان هردوشون بخوان اطلاعاتو ویرایش کنن مشکلات محاسباتی و انباری به وجود میاد

چطور میشه جلوی ویرایش کلاینت دوم رو گرفت ؟

انجام این کار در برنامه و اصولاً برای برنامه های شبکه ای رایج نیست و یکچیز از رایج نیست بیشتر!
شما نباید این کار را در برنامه انجام دهید.
قفلهای SQLServer کافی است و حداکثر حدکاثر برای موارد خاص و موقتی که چند هزارم ثانیه طول میکشد میتوانید از تراکنشها استفاده کنید که این هم باز ربطی به مشکل شما ندارد و کاربردی برای شما ندارد.

بحرحال به نظر من کلاً هیچ کدی باری این کار ننویسید!
آمد و یک نفر فرم را باز کرد و تلفن زنگ زد و نشست لیست خرید سبزی و تخم مرغ و... زنش را بنویسد!!!
همه در شبکه الاف بنویشند تا کار همسر گرام کارمند تمام شود؟
اگر برنامه در شبکه جهانی اینترنت باشد چه میشود؟!!!
قفل کردن بخشها برای استفاده انحصاری یک کلاینت عموماً در زمان ها کسرهای بسیار بسیار کوچک ثانیه و هزارم ثانیه انجام میشود.
کارمند شما هر چه قدر هم سریع باشد و عمل کند باز عمل مذکور در برنامه منطقی نخواهد بود.

=====

بحرحال من کد و پیشنهاداتی دیگری برایتان ندارم و کمک دیگری نمیتوانم بکنم.
موفق باشید.

[mahdi7s]

سلام

من که زن ندارم ولی خوب با این دوستمون موافقم .
راستشو بخوای اولشم می خواستم یه همچین چیزای بگم ولی به دلایلی مفقود بیخیال شدم.

[_H2_]

سلام
البته این را هم اضافه کنم که باید روی PrimaryKey ها شما حساسیت داشته باشید و برای تضمین صحیح کارکرد برنامه شبکه ای باید اصلاً اجازه تغییر PrimaryKey را به کاربر ندهید.

اجازه تغییر Primarykey میتواند در شرایط مختلف باعث مشکلات بدجوری روی دیتاها شود و عواقب عجیب و غریبی رخ دهد.
بهترین فیلد عدد Autonumber است که میتواند تحت نام کدعضویت، کد دانش آموزی، شماره فاکتور و... مخفی شود.

در نهایت اگر میخواهد کاربر بتواند این کد را تغییر دهد، میتوانید یکم کلک بزنید!
Primarykey ای که برنامه بر اساس آن کار میکند و لزومی هم ندارد کاربر آن را ببیند از primarykey ظاهری که کاربر میبیند مجزا کنید.

مثلاً الآن Username من در این سایت _H2_ است و این هم منحصر بفرد و غیر تکراری است ولی در واقع یک شاخص منحصر به فرد دیگر تحت نام userid وجود دارد که مثلاً برای من عدد 78590 است.
ما به عنوان کاربران این برنامه شبکه ای اینترنتی و وبی به این راحتی ها عدد 78590 را نمیبینیم و همان username را به عنوان شاخص منحصر بفردمان میشناسیم ولی برنامه میتوانید به جای username از userid استفاده کند و هیچ کجا هم نمیخواهد به کاربر نشان دهد و از او بپرسد و حتی مدیر سایت هم نمیخواهد بداند.
خود برنامه خودکار زمان Insert یک Autonumber تخصیص میدهد و به کسی هم نشان نمیدهد ولی برای relation ها و شرط where های UPDATE و DELETE از آن استفاده کنید و کاربر هم میتواند همه فیلدها را ویرایش کند ولی فیلد username یک unique-index خواهد داشت که اجازه تکرار نمیدهد.
(userid را هم که اصلاً نمیبیند که بخواهد تغییر دهد!)

=====

خلاصه برای برنامه ای شبکه ای مطمئن primarykey جداول مهم را autonumber بگذارید و اگر راه داد این فیلد را به کاربر هم به صورت readonly نشان دهید و اگر شرایط منطقی برنامه اجازه نمیداد، ان را از کاربر مخفی کنید.

موفق باشید.

[MTPROG]

انجام این کار در برنامه و اصولاً برای برنامه های شبکه ای رایج نیست و یکچیز از رایج نیست بیشتر!
شما نباید این کار را در برنامه انجام دهید.

میشه بگید اگه بخواهید یک فاکتور 10 کالایی رو که دارای 10 رکورد همزمان است رو ویرایش کنید چکار میکنید؟
یعنی شما فقط اجازه ویرایش یک تک رکورد رو میدید یا نه اجازه 10 رکورد رو میدید
در اینصورت اطلاعاتو میخواید کجا نگهداری کنید؟

آمد و یک نفر فرم را باز کرد و تلفن زنگ زد و نشست لیست خرید سبزی و تخم مرغ و... زنش را بنویسد!!!
همه در شبکه الاف بنویشند تا کار همسر گرام کارمند تمام شود؟

این کارمند وظیفه نشناس زن ذلیل فقط روی یک فاکتور کار مکنه نه تمام فاکتورها و فقط اون یک فاکتور غیر قابل دسترس میشه

به فرض مثال اگر هیچ کنترلی نکنیم اگر این کارمند در حال ویرایش باشه و یکی دیگه این فاکتور رو حذف کنه چی ! آیا خطا در محاسبات به وجود نمیاد؟
مطمئنا به وجود میاد.چون در برنامه های حسابداری جدولها خیلی با هم ارتباط دارند فرضا اگر کارمندی کالاهای فاکتور 1 رو ویرایش کنه بعد کارمندی دیگه در همون لحظه صورتحساب فاکتور 1 رو ویرایش کنه در اینصورت به علت عدم هماهنگی جمع مبلغ پرداختی با جمع مبلغ فاکتور برابری نمیکنه و این یعنی به هم ریختن حسابها

در کل من با این که در هنگام ویرایش کنترل انجام ندیدم مخالفم چون اون قفلی که شما میگید فقط جهت ذخیره تغییرات در بانکه و کلاینتها تو صف میرن ولی نمیتونه جلوی تداخل اطلاعات رو بگیره

با تشکر