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

واضح آرشیو وب فارسی:سایت ریسک: View Full Version : جلوگیری از ویرایش یک رکورد تو سط چند تا کلاینت MTPROG01-09-2009, 10:09 AMتو برنامه های تحت شبکه هنگام درج در جدول مشکلی به اون صورت به وجود نمیاد چون خود SQL قفلهایی رو تو جدول میزاره و کلاینتها میرن تو صف و اطلاعات به نوبت ثبت میشه ولی مشکل تو ویرایش یک رکورد مشترک هستش فرض کنید فاکتور شماره 1 با 10 رکورد وجود داره ویک کلاینت میخوان اونو ویرایش کنه قبل ذخیره تغییرات کلاینت اطلاعات فاکتور رو میریزن تو یک Dataset برنامه ش و تغییرات رو تو DataSet اعمال میکنه در حین اینکه کلاینت مورد نظر در حال ویرایش است یک کلاینت دیگه باز میخواد اونو ویرایش کنه اگر در یک زمان هردوشون بخوان اطلاعاتو ویرایش کنن مشکلات محاسباتی و انباری به وجود میاد چطور میشه جلوی ویرایش کلاینت دوم رو گرفت ؟ البته میشه با گذاشتن یک جدول کنترلی در بانک این رکوردها رو موقتا قفل کرد فرضا وقتی یک کلاینت میخواد رکوردی رو ویرایش کنه ابتدا به جدول کنترلی نگاه میکنه اگر قفل نبود بعد ویرایش کنه و اگر قفل بود پیغامی از برنامه دریافت کنه مبنی بر اینکه رکورد مورد نظر در حال به روز رسانی است و بعدا امتحان کنه حالا اگه کسی فکر بهتری داره لطفا بگه با تشـــــــــــــــــــــــ ـــــــــــــــتکر mahdi7s01-09-2009, 11:10 AMسلام خوب شما که دستورات سرور رو تو یه جدول می ریرزید توی اون جدول یه فیلد برای آدرس کلاینتی که باید اونو اجرا کنه بذارید که کلاینت ها چکش کنن اگه آدرس خودشون بود این کارو انجام بدن. یا در همون جدول یه فیلد بولیین قرار بدین و اولین که کلاینتی که اونو تغییر میده مقدار این فیلدو عوض کنه تا دیگر کلاینتها بی خیال بشن. حالا چرا از سوکت استفاده نمی کنید؟ MTPROG01-09-2009, 11:34 AMخوب شما که دستورات سرور رو تو یه جدول می ریرزید توی اون جدول یه فیلد برای آدرس کلاینتی که باید اونو اجرا کنه بذارید که کلاینت ها چکش کنن اگه آدرس خودشون بود این کارو انجام بدن. همون جدول کنترلی که گفتم همین کارو میکنه تازه اون بهتر از این روش هست چون هر چقدر رکوردها در روش شما بشتر بشه تعداد سطرهای فیلد آدرس هم بیشتر میشه و سر بار سیستم میشه و با ساخت جدول کنترلی فقط یک رکورد به ازای مجموعه از رکوردهای قابل ویرایش وجود دارد حالا چرا از سوکت استفاده نمی کنید؟ میشه بگید چور میشه از سوکت استفاده کرد در حالی من با بانکهابیSQL کار میکنم با تشکر mahdi7s01-09-2009, 12:29 PMمیشه بگید چور میشه از سوکت استفاده کرد در حالی من با بانکهابیSQL کار میکنم منظورتون اینه که نمیشه؟! این کارو میشه انجام داد و البته کد نویسی زیادتر و دقیقتر می خواد. به هر حال وقتی دارین با پایگاه داده کار می کنید راه حل ساده تر همون کاری است که خودتون انجام دادین. خوب حالا که میگید چنین کاریو انجام دادین پس مشکلتون چیه؟:20: MTPROG01-09-2009, 01:34 PMمنظورتون اینه که نمیشه؟! این کارو میشه انجام داد و البته کد نویسی زیادتر و دقیقتر می خواد. نه منظورم اینه که چطور میشه خوب حالا که میگید چنین کاریو انجام دادین پس مشکلتون چیه؟ اگر منظورتون همون تایپک در مورد ارسال اطلاعات به کلاینت هستش اونجا بحث بر سر این بود که به کلاینت فرمان انجام کاری رو بدید که باید انجام بده برای اینجا کاربرد نداره ولی Socket Programing به منظور جلوگیری از ویرایش کاربر دیگه مفید نیست و لی برای اطلاع رسانی فوری مناسبه فرض کنید 100 کلاینت داریم اگر قرار باشه از Socket Programing استفاده بشه بایدبرنامه سرور به 100 کلاینت پیغام بفرسته که فلان رکورد قفله و بعد از باز شدن دوباره همین پیغام رو بده در حالی که اون کلاینت شاید اصلا کاری به اون رکورد نداشته باشه همون جدول کنترلی فعلا بهتره چون هر وقت نیاز بود کلاینت بررسی میکنه ولی این جدول کنترلی هم به اندازه خوش دردسر داره مثلا کلاینت به دلایلی نرم افزاری یا سخت افزاری نتونه قفل رو از جدول کنترلی حذف کنه دیگه اون رکورد قابل ویرایش نیست البته میشه هنگام اجرای برنامه سرور این جدول ریست بشه در کل این روش جواب میده ولی میخواستم بدونم آیا روش بهتر و بهینه تری هست یا خود SQL امکاناتی برای این جور مواقع داره یا نه با تشکر MTPROG01-09-2009, 01:46 PMیه راه دیگه اینه که هر دو کاربر بتونن شروع به ویرایش کنن ولی نه از روی جدول اصلی بلکه بر روی یک view. یک view از جدول اصلی میگیرن و اون رو ویرایش میکنن. فرض کنیم view کاربر دوم به اسم view2 باشه و این view به وسیله select2 ساخته شده باشه. کاربر اول تغییرات خودش رو ثبت کنه. حالا وقتی کاربر دوم میخواد تغییرات خودش رو ثبت کنه،برنامه یه بار دیگه درخواستselect 2 رو اجرا میکنه. اگر با اونی که کاربر روش کار کرده تفاوت داشت بهش اطلاع میده که جدول از آخرین باری که شما دید تغییر کرده آیا میخواید جدول جدید رو ببینید؟ _H2_01-09-2009, 02:35 PMسلام کلاینت اطلاعات فاکتور رو میریزن تو یک Dataset برنامه ش و تغییرات رو تو DataSet اعمال میکنه در حین اینکه کلاینت مورد نظر در حال ویرایش است یک کلاینت دیگه باز میخواد اونو ویرایش کنه اگر در یک زمان هردوشون بخوان اطلاعاتو ویرایش کنن مشکلات محاسباتی و انباری به وجود میاد چطور میشه جلوی ویرایش کلاینت دوم رو گرفت ؟ انجام این کار در برنامه و اصولاً برای برنامه های شبکه ای رایج نیست و یکچیز از رایج نیست بیشتر! شما نباید این کار را در برنامه انجام دهید. قفلهای SQLServer کافی است و حداکثر حدکاثر برای موارد خاص و موقتی که چند هزارم ثانیه طول میکشد میتوانید از تراکنشها استفاده کنید که این هم باز ربطی به مشکل شما ندارد و کاربردی برای شما ندارد. بحرحال به نظر من کلاً هیچ کدی باری این کار ننویسید! آمد و یک نفر فرم را باز کرد و تلفن زنگ زد و نشست لیست خرید سبزی و تخم مرغ و... زنش را بنویسد!!! همه در شبکه الاف بنویشند تا کار همسر گرام کارمند تمام شود؟ اگر برنامه در شبکه جهانی اینترنت باشد چه میشود؟!!! قفل کردن بخشها برای استفاده انحصاری یک کلاینت عموماً در زمان ها کسرهای بسیار بسیار کوچک ثانیه و هزارم ثانیه انجام میشود. کارمند شما هر چه قدر هم سریع باشد و عمل کند باز عمل مذکور در برنامه منطقی نخواهد بود. ===== بحرحال من کد و پیشنهاداتی دیگری برایتان ندارم و کمک دیگری نمیتوانم بکنم. موفق باشید. mahdi7s01-09-2009, 03:33 PMسلام من که زن ندارم ولی خوب با این دوستمون موافقم . راستشو بخوای اولشم می خواستم یه همچین چیزای بگم ولی به دلایلی مفقود بیخیال شدم. _H2_01-09-2009, 08:31 PMسلام البته این را هم اضافه کنم که باید روی PrimaryKey ها شما حساسیت داشته باشید و برای تضمین صحیح کارکرد برنامه شبکه ای باید اصلاً اجازه تغییر PrimaryKey را به کاربر ندهید. اجازه تغییر Primarykey میتواند در شرایط مختلف باعث مشکلات بدجوری روی دیتاها شود و عواقب عجیب و غریبی رخ دهد. بهترین فیلد عدد Autonumber است که میتواند تحت نام کدعضویت، کد دانش آموزی، شماره فاکتور و... مخفی شود. در نهایت اگر میخواهد کاربر بتواند این کد را تغییر دهد، میتوانید یکم کلک بزنید! Primarykey ای که برنامه بر اساس آن کار میکند و لزومی هم ندارد کاربر آن را ببیند از primarykey ظاهری که کاربر میبیند مجزا کنید. مثلاً الآن Username من در این سایت _H2_ است و این هم منحصر بفرد و غیر تکراری است ولی در واقع یک شاخص منحصر به فرد دیگر تحت نام userid وجود دارد که مثلاً برای من عدد 78590 است. ما به عنوان کاربران این برنامه شبکه ای اینترنتی و وبی به این راحتی ها عدد 78590 را نمیبینیم و همان username را به عنوان شاخص منحصر بفردمان میشناسیم ولی برنامه میتوانید به جای username از userid استفاده کند و هیچ کجا هم نمیخواهد به کاربر نشان دهد و از او بپرسد و حتی مدیر سایت هم نمیخواهد بداند. خود برنامه خودکار زمان Insert یک Autonumber تخصیص میدهد و به کسی هم نشان نمیدهد ولی برای relation ها و شرط where های UTE و DELETE از آن استفاده کنید و کاربر هم میتواند همه فیلدها را ویرایش کند ولی فیلد username یک unique-index خواهد داشت که اجازه تکرار نمیدهد. (userid را هم که اصلاً نمیبیند که بخواهد تغییر دهد!) ===== خلاصه برای برنامه ای شبکه ای مطمئن primarykey جداول مهم را autonumber بگذارید و اگر راه داد این فیلد را به کاربر هم به صورت readonly نشان دهید و اگر شرایط منطقی برنامه اجازه نمیداد، ان را از کاربر مخفی کنید. موفق باشید. MTPROG02-09-2009, 09:59 AMانجام این کار در برنامه و اصولاً برای برنامه های شبکه ای رایج نیست و یکچیز از رایج نیست بیشتر! شما نباید این کار را در برنامه انجام دهید. میشه بگید اگه بخواهید یک فاکتور 10 کالایی رو که دارای 10 رکورد همزمان است رو ویرایش کنید چکار میکنید؟ یعنی شما فقط اجازه ویرایش یک تک رکورد رو میدید یا نه اجازه 10 رکورد رو میدید در اینصورت اطلاعاتو میخواید کجا نگهداری کنید؟ آمد و یک نفر فرم را باز کرد و تلفن زنگ زد و نشست لیست خرید سبزی و تخم مرغ و... زنش را بنویسد!!! همه در شبکه الاف بنویشند تا کار همسر گرام کارمند تمام شود؟ این کارمند وظیفه نشناس زن ذلیل فقط روی یک فاکتور کار مکنه نه تمام فاکتورها و فقط اون یک فاکتور غیر قابل دسترس میشه به فرض مثال اگر هیچ کنترلی نکنیم اگر این کارمند در حال ویرایش باشه و یکی دیگه این فاکتور رو حذف کنه چی ! آیا خطا در محاسبات به وجود نمیاد؟ مطمئنا به وجود میاد.چون در برنامه های حسابداری جدولها خیلی با هم ارتباط دارند فرضا اگر کارمندی کالاهای فاکتور 1 رو ویرایش کنه بعد کارمندی دیگه در همون لحظه صورتحساب فاکتور 1 رو ویرایش کنه در اینصورت به علت عدم هماهنگی جمع مبلغ پرداختی با جمع مبلغ فاکتور برابری نمیکنه و این یعنی به هم ریختن حسابها در کل من با این که در هنگام ویرایش کنترل انجام ندیدم مخالفم چون اون قفلی که شما میگید فقط جهت ذخیره تغییرات در بانکه و کلاینتها تو صف میرن ولی نمیتونه جلوی تداخل اطلاعات رو بگیره با تشکر _H2_02-09-2009, 01:12 PMسلام من بودم فقط فیلد primarykey را autonumber میگذاشتم تا تضمین کند در حال و آینده غیر تکراری است و به دو کلاینت هیچگاه یک id داده نمیشود و هیچگاه داده ها گم نخواهد شد. PrimaryKey=Autonumber+ReadOnly (با/ بدون نمایش به کاربر) هیچ سطر دیگری در حال و حتی آینده ان primarykey را نخواهد داشت. در اصلی مثل "کد ملی" ما میماند که اگر طرف بمیرد هم تکرار نمیشود و هر سطر شما موجود یا حذف شده autonumber خودش را دارد. تمام اعمال ویرایشی در هسته بانک هم با کمک primarykey ها انجام میشود و بقیه فیلدها (اگر برنامه درست طراحی شود) نباید مهم باشند. چون primarykey این تیپی غیر قابل تغییر است، تضمین میکند هر عملیات DELETE-UTE-INSERT در هر زمانی و با هر اختلاف زمانی دقیقاً مختص همان سطر که به نوعی "کدملی" دارد انجام شود و دیگر زمان مهم نخواهد بود. ===== چهار حالت اساسی که بیشتر نداریم؟ اگر بعد از هر عملیاتی (که مدام در سرور درحال انجام است) کلاینتی هر لحظه دستور ... - SELECT دهد که آخرین محتویات همان لحظه را مشاهده میکند! ایرادی دارد؟ نباید ببینید؟ بانک اطلاعاتی باید علم لدونی داشته باشد و محتویات 5 دقیقه بعد را نشان دهد؟ مشکل کجا است. - دستور INSERT بدهد که ربطی ندارد و هربار یک autonumber جدید و منحصر به فرد میگیرد و موتور بانک تضمین کرده که با هر تعداد کلاینت و همزمان اجرا شود autonumber خودشان و غیر تکراری بگیرند. و تمام دستورات قبلی روی این مورد بی اثر است. بازم من مشکلی نمیبینم. - دستور DELETE بدهد که چون هر سطر "کدملی" مانند خودش را دارد دقیقاً همان سطر حذف میشود. فرقی هم ندارد چند لحظه قبل فردی ان را ویرایش UTE کرده یا سطر تازه درج (INSERT شده باشد. یک نفر دستور DELETE یک سطر کاملاً مشخص و منحصر بفرد را داده بالاخره شما میخواهید انجامش دهید؟ یا الآن یا 5 دقیقه بعد چه فرقی دارد؟ باید این دیتا حذف شود! - دستور UTE بدهد که اگر سطر تازه INSERT شده باشد که ایرادی ندارد و اگر هم سطر قبلاً DELETE شده باشد باز هم ایرادی ندارد. یک نفر که اجازه اش را داده تشخیص داده این سطر باید حذف شود، برنامه شما نباید فرمانش را انجام دهد؟؟؟ چون دیگر سطری وجود ندارد UTE-WHERE اصلاً برقرار نشده و چیزی چه اشتباهاض و چه صحیح تغییر نخواهد کرد. (البته برنامه میتواند پیغامی مبنی بر عدم یافتن اطلاعات بدهد) بالاخره تقصیر کسی نیست که یک نفر مجوز داشته و تشخصیص داده این بخش باید حذف شود! ولی نمیتونه جلوی تداخل اطلاعات رو بگیره سعی میکنم تا شب با یک مثال شهودی تر از فاکتور و کالاهای فاکتور برایتان بیشتر توضیح دهم و یک سری از شرایط خاص را هم توضیح دهم. MTPROG02-09-2009, 04:18 PMبحث هایی که درباره primarykey ها کردید قبول دارم خود من هم تمام کلیدها و ایدیها رو با AutoNumber بدست میارم بحث سر اینکه کلید تکراری به وجود بیاد یا نه نیست بحث سر ارتباط بین جدولها است مثلا جدول فاکتورها ممکنه با چند تا جدول دیگه مثلا جدول پرداخت و چکها و صندوق و جدول ایندکس ارتباط داشته باشه حالتی که شما گفتید برای یک جدول هیچ مشکلی نداره ولی وقتی به صورت منطقی بین جدولها ارتباط برقرار کردی مشکل به وجود میاد چون با تغییر یک فاکتور جندین جدول دیگه با فاکتور مربوطه ارتباط دارن تغییر میکنن اگر روی یک فاکتور دو نفر ویرایش کنن و یک نفر حذف کنه(تقریبا همزمان) هر کدوم بسته به نیازشون ارتباط بین جدولها رو تغییر میدن و در این صورت ممکنه حالتهای غیر قابل پیش بینی تو برنامه به وجود یاد به هر حال منتظر برنامه تون هستم _H2_02-09-2009, 06:57 PMسلام من سعی همانطور که گفتم با مثال روشن تر و موردی یک نمونه را با توضیح برایتان باز کنم. فعلاً تا من وقت کنم و بتایپم(!) اگر توانستید یک مورد از نمونه زیر مثال بزنید تا به جای بحث کلی بتوانیم موردی و برای نمونه بررسی دقیق تری کنیم و بحث مفید تر شود: ...هر کدوم بسته به نیازشون ارتباط بین جدولها رو تغییر میدن ... MTPROG03-09-2009, 09:31 AMاگر توانستید یک مورد از نمونه زیر مثال بزنید تا به جای بحث کلی بتوانیم موردی و برای نمونه بررسی دقیق تری کنیم و بحث مفید تر شود: نقل قول: ...هر کدوم بسته به نیازشون ارتباط بین جدولها رو تغییر میدن ... منظورتون نمونه سورسه یا همینجا توضیح بدم؟ _H2_05-09-2009, 04:02 PMسلام میبخشید ویندوز عوض کردم، کمی الاف شدم ... ! سه جدول زیر را در نظر بگیرید ... !!!! برای مشاهده محتوا ، لطفا ثبت نام کنید / وارد شوید !!!! رابطه جداول هم کاملاً مشخص است. دو جدول اول با فیلد کلیدشان با جدول سوم ارتباط دارند. ( پیشنهاد میکنم برای سادگی بحث و رفع مشکل، شما هم اگر مثال و ابهامی داشتید روی همین مدل سه جدولی فوق با همین فیلدها توضیح داده و بحثتان را مطرح کنید. ) حالا وضعیت های مختلف را بررسی میکنیم: ----- زمان اضافه کردن فاکتور جدید (Invoices-INSERT) شما سطر را در دیتابیس INSERT میکنید و یک ID_Invoice صدردصد سالم و منجحصر به فرد و مخصوص همین فاکتور میگیرد. بعد هم تک تک کالاها را با توجه به کدشان که ID_Good باشد و شماره فاکتور که ID_Invoice باشد (و از مرحله قبل گرفته اید) به جدول Invoices_Goods اضافه میکنید. چون ID_Invoce منحصر به فرد است با سایر برنامه های شبکه هم مشکلی ایجاد نمیشود. ----- زمان تغییر موارد فیلدهای فاکتور در جدول اصلی (Invoices-UTE) چون تمام ارتباط جدول فوق با جدول Invoices_Goods با فقط و فقط ID_Invoice اش است و آن هم اصلاً کاربر نمیبینید و قابل تغییر هم نیست هر تغییری در سطح جدول Invoices مشکلی ایجاد نمیکنم و نیازی به تغییر و نگرانی برای جدول نظیر Invoices_Goods وجود ندارد! باز هم چون ID_Invoce منحصر به فرد است بقیه برنامه های شبکه هم کار خودشان را میکنند. هر کسی زودتر فاکتور را ویرایش کند و ذخیره کند، تا همان لحظه ویرایش او ذخیره میشود. مثلاً کسی تاریخ فاکتور را 1388 گذاشته و Save کند، ذخیره میشود، پشت او کسی فاکتور را 1350 بگذارد و چند میلی ثانیه بعد ذخیره کند، خوب مقدار جدید ذخیره میشود، کاملاً هم منطقی نیست. ایرادی میبینید؟؟؟ اگر هم کسی بعد از ویرایش ما فاکتور را Delete کند، خوب فرمان داده و حذف میشود! اگر هم قبل از ذخیره تغییرات کس دیگری Delete کند، چون کلید منحصر است شرط Update-Where بعدی بدون شک سطری نمی یابد و چیزی را تغییر نمیدهد. یک نفر که مجوز داشته حذفش کرده، به برنامه ارتباطی ندارد! ----- زمان حذف کلی یک فاکتور (Invoices-DELETE) چون کلید منحصر به فرد است، اگر کسی قبش ویرایش و یا حذف کرده باشد، مشکلی ایجاد نمیشود. یا کلید وجود دارد که دستور Delete حذفش میکند یا قبلاً و زودتر کسی حذفش کرده که Delete-Where دیگری چیزی برای حذف پیدا نمیکند. طبیعتاً بعد از حدف فاکتور اصلی باید زیر مجموعه های Invoices_Goods هم حذف شود که برای انها هم دقیقاً همین وضعیت پیش می آید و اگر کلیدشان هنوز موجود باشد، حذف خواهند شد و بعد هم تمام دستورات Delete-Where و Update-Where جاهای دیگر صادق نخواهد شد. (برای حذف زیر مجموعه ها میتوان از تنظیم آبشاری در زمان تعریف Relation استفاده کنید و Enforce را فعال کنید. یا میتوان از تریگرها استفاده کرد.) ----- واقعاً من مشکلی نمیبینم؟ اگر تردیدی دارید مطرح کنید. اگر فکر میکنید مشکلی ایجاد میکند شرح دهید؟ مهم برای برنامه ان است که تداخل پیش نیایید و مثلاً اگر سطر حذف شود و کسی Update کند ... - اصلاً مهم نیست و کاملاً منطقی است که سطر حذف شده و Update دیگر معنی ندارد و نباید انجام شود (کسی انتظار دیگری ندارد!) - ولی نباسید چنین شود که چون سطر اصلی را نیافته سطر اشتباهی دیگری را تغییر ندهد. (این است که باید در برنامه تضمینش کنید.) منظورتون نمونه سورسه یا همینجا توضیح بدم؟ منظورم چیزی مثل همین شرح فوق بود. اگر تداخلی در تئوری فوق درک میکنید، لطفاً بیان کنید. موفق باشید. MTPROG06-09-2009, 11:10 AMوقتی در حال ویرایش یک فاکتور هستید که دارای 6 قلم کالا است قبل از اینکه ویرایش شما تموم بشه این فاکتور با 6 قلم کالا توسط کسی دیگه کلا حذف میشه حالا کاربری که در حال ویرایش هستش اگر همون 6 فیلد باشه خوب به قول شما Update Where چون برقرار نیست عمل نمیکنه اما اگر این 6 قلم کالا تبدیل به 8 قلم بشه و دو کالای جدید به لیست ویرایش اضافه بشه دیگه عمل Insert به ازای 2 رکورد انجام میشه و چون عمل درج هستش پس اجام میشه اینو چطوری حل میشه؟ _H2_06-09-2009, 12:46 PMسلام حالا کاربری که در حال ویرایش هستش اگر همون 6 فیلد باشه خوب به قول شما Update Where چون برقرار نیست عمل نمیکنه اما اگر این 6 قلم کالا تبدیل به 8 قلم بشه و دو کالای جدید به لیست ویرایش اضافه بشه دیگه عمل Insert به ازای 2 رکورد انجام میشه و چون عمل درج هستش پس اجام میشه اینو چطوری حل میشه؟ خوب تازه حالا این شد یک چیزی!!! این در تعریف اختلال میگنجد و دقیقاً شرح های منطقی این تیپی مد نظر من بود که گفتم اگر تردیدی دارید بیان کنید. اما راه حل: کافی است در دستابیس بین جداول Relation تعریف کنید که البته SQLServer انها را Diagram هم می نامد. در زمان تعریف و یا بعد ان همه گزینه های اجباری را فعال کنید: !!!! برای مشاهده محتوا ، لطفا ثبت نام کنید / وارد شوید !!!! (مورد آخری با فیلدهای AutoNumber برای PrimaryKey چندان لازم نیست) با این تنظیمات SQLServer تضمین میکند که هیچگاه امکان ندارد همچین تداخلهایی رخ دهد. اگر هم سطری در رابطه بالاسری (والد) حذف شود، خودکار همه زیر مجموعه ها (فرزندان) را خود SQLServer پاک میکند. (یعنی با حذف سطر جدول Invoices همه سطرهای نظیر Invoices_Goods هم حذف خواهد شد و شما لازم نیست کاری کنید.) اگر هم دستور INSERT ای بیاید که نظیر کلید بالاسری اش (والد) وجود نداشته باشد، SQLServer دستور INSERT و یا UTE که همچین وضعیتی را میخواهد ایجاد کند انجام نمیدهد و به ریسمان مذکور یک اثتثنا (همان خطای خودمان!) ارسال میکند. ... عمل Insert به ازای 2 رکورد انجام میشه و چون عمل درج هستش پس اجام میشه ... پس با فعال کردن گزینه های مذکور در دیتابیس و با در نظر گرفتن شرایط منطقی (که شما به خوبی تشریح کردید) کلایت دوم که خطا دریافت خواهد کرد و فقط کاری که شما باید در کدنویسی انجام دهید آن است که دستور Try برای عملتان قرار دهید و در Cacth نوع کلاس خطای مذکور را هندلر کنید و پیغام خطای مناسب فارسی را در قالب یک MsgBox نمایش دهید. اگر موارد منطقی و استدلالی دیگر از این دست به ذهنتان رسید بیان کنید. MTPROG06-09-2009, 01:31 PMخیلی عالی بود ممنون فکر کنم این پست آخر ارزش کل این تاپیک رو داشت اگر موارد منطقی و استدلالی دیگر از این دست به ذهنتان رسید بیان کنید. چند مورد دیگه هم هست البته اون هم مربوط به ارتباط بین جدولهاست . یکم روش فکر میکنم مینویسم MTPROG07-09-2009, 10:00 AMمن تو برنامه خودم 8 نوع فاکتور دارم جهت ذخیره لیست این 8 نوع فاکتور از یک جدول به نام List_factor استفاده کردم و یک فیلد به نام State وجود دارد که نوع فاکتورها رو مشخص می کنه مثلا : فاکتور شماره 1 با State مقدار 0 مربوط به فروش فاکتور شماره 1 با State مقدار 5 مربوط به خرید یعنی در این جدول ممکنه 8 تا شماره 1 وجود داشته باشه ولی اگر فیلد state اونها رو حساب کنی به ازای هر نوع فاکتور یک شماره وجود داره آیا این روش باعث به هم خوردن Relation نمیشه(چون فیلد یکتا نیست)؟ اگر نمیشه پس باید از 8 تا جدول استفاده بشه که کار رو طولانی تر میکنه! اگر از یک جدول استفاده بشه و فیلد شماره فاکتور یکتا باشه شماره فاکتورها پراکنده میشه مثلا 1 تا 10 فروش 11 برگشت از فروش 12 تا 15 خرید ... که اینم زیاد جالب نیست شما چه روشی رو پیشنهاد میکنید؟ _H2_08-09-2009, 01:41 AMسلام برای برنامه شبکه ای و حداکثر تضمین صحت کارکرد شبکه ای، استفاده از Autonumber-PrimaryKey میتوانید خیلی کمک کند و حلال مشکلات باشد. در ضمینه همین تداخل ها که بحث کردیم، من خودم در طی سالها بارها و در شرایط گوناگون (که الا« به ذهنم خودم هم نمیرسد!) این مسئله را تحلیل کرده بودم ولی � سایت ما را در گوگل محبوب کنید با کلیک روی دکمه ای که در سمت چپ این منو با عنوان +1 قرار داده شده شما به این سایت مهر تأیید میزنید و به دوستانتان در صفحه جستجوی گوگل دیدن این سایت را پیشنهاد میکنید که این امر خود باعث افزایش رتبه سایت در گوگل میشود

این صفحه را در گوگل محبوب کنید

[ارسال شده از: سایت ریسک]

[مشاهده در: www.ri3k.eu]

[تعداد بازديد از اين مطلب: 1464]