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

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

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

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

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

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

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

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

سلام

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

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

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

نقل قول:

---

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

---

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

نقل قول:

---

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

---

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

با تشکر

نقل قول:

---

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

---

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

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

نقل قول:

---

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

---

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

نقل قول:

---

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

---

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

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

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

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

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

با تشکر

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

سلام

نقل قول:

---

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

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

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

---

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

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

=====

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

سلام

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

سلام
البته این را هم اضافه کنم که باید روی 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 نشان دهید و اگر شرایط منطقی برنامه اجازه نمیداد، ان را از کاربر مخفی کنید.

موفق باشید.

نقل قول:

---

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

---

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

نقل قول:

---

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

---

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

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

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

با تشکر

سلام
من بودم فقط فیلد primarykey را autonumber میگذاشتم تا تضمین کند در حال و آینده غیر تکراری است و به دو کلاینت هیچگاه یک id داده نمیشود و هیچگاه داده ها گم نخواهد شد.
PrimaryKey=Autonumber+ReadOnly (با/ بدون نمایش به کاربر)

هیچ سطر دیگری در حال و حتی آینده ان primarykey را نخواهد داشت.
در اصلی مثل "کد ملی" ما میماند که اگر طرف بمیرد هم تکرار نمیشود و هر سطر شما موجود یا حذف شده autonumber خودش را دارد.
تمام اعمال ویرایشی در هسته بانک هم با کمک primarykey ها انجام میشود و بقیه فیلدها (اگر برنامه درست طراحی شود) نباید مهم باشند.
چون primarykey این تیپی غیر قابل تغییر است، تضمین میکند هر عملیات DELETE-UPDATE-INSERT در هر زمانی و با هر اختلاف زمانی دقیقاً مختص همان سطر که به نوعی "کدملی" دارد انجام شود و دیگر زمان مهم نخواهد بود.

=====

چهار حالت اساسی که بیشتر نداریم؟

اگر بعد از هر عملیاتی (که مدام در سرور درحال انجام است) کلاینتی هر لحظه دستور ...

- SELECT دهد که آخرین محتویات همان لحظه را مشاهده میکند!
ایرادی دارد؟ نباید ببینید؟ بانک اطلاعاتی باید علم لدونی داشته باشد و محتویات 5 دقیقه بعد را نشان دهد؟ مشکل کجا است.


- دستور INSERT بدهد که ربطی ندارد و هربار یک autonumber جدید و منحصر به فرد میگیرد و موتور بانک تضمین کرده که با هر تعداد کلاینت و همزمان اجرا شود autonumber خودشان و غیر تکراری بگیرند.
و تمام دستورات قبلی روی این مورد بی اثر است. بازم من مشکلی نمیبینم.


- دستور DELETE بدهد که چون هر سطر "کدملی" مانند خودش را دارد دقیقاً همان سطر حذف میشود.
فرقی هم ندارد چند لحظه قبل فردی ان را ویرایش UPDATE کرده یا سطر تازه درج (INSERT شده باشد.
یک نفر دستور DELETE یک سطر کاملاً مشخص و منحصر بفرد را داده بالاخره شما میخواهید انجامش دهید؟ یا الآن یا 5 دقیقه بعد چه فرقی دارد؟ باید این دیتا حذف شود!


- دستور UPDATE بدهد که اگر سطر تازه INSERT شده باشد که ایرادی ندارد و اگر هم سطر قبلاً DELETE شده باشد باز هم ایرادی ندارد.
یک نفر که اجازه اش را داده تشخیص داده این سطر باید حذف شود، برنامه شما نباید فرمانش را انجام دهد؟؟؟
چون دیگر سطری وجود ندارد UPDATE-WHERE اصلاً برقرار نشده و چیزی چه اشتباهاض و چه صحیح تغییر نخواهد کرد.
(البته برنامه میتواند پیغامی مبنی بر عدم یافتن اطلاعات بدهد)
بالاخره تقصیر کسی نیست که یک نفر مجوز داشته و تشخصیص داده این بخش باید حذف شود!

نقل قول:

---

ولی نمیتونه جلوی تداخل اطلاعات رو بگیره

---

سعی میکنم تا شب با یک مثال شهودی تر از فاکتور و کالاهای فاکتور برایتان بیشتر توضیح دهم و یک سری از شرایط خاص را هم توضیح دهم.

بحث هایی که درباره primarykey ها کردید قبول دارم خود من هم تمام کلیدها و ایدیها رو با AutoNumber بدست میارم

بحث سر اینکه کلید تکراری به وجود بیاد یا نه نیست

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

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

اگر روی یک فاکتور دو نفر ویرایش کنن و یک نفر حذف کنه(تقریبا همزمان) هر کدوم بسته به نیازشون ارتباط بین جدولها رو تغییر میدن و در این صورت ممکنه حالتهای غیر قابل پیش بینی تو برنامه به وجود یاد

به هر حال منتظر برنامه تون هستم

سلام
من سعی همانطور که گفتم با مثال روشن تر و موردی یک نمونه را با توضیح برایتان باز کنم.
فعلاً تا من وقت کنم و بتایپم(!) اگر توانستید یک مورد از نمونه زیر مثال بزنید تا به جای بحث کلی بتوانیم موردی و برای نمونه بررسی دقیق تری کنیم و بحث مفید تر شود:

نقل قول:

---

...هر کدوم بسته به نیازشون ارتباط بین جدولها رو تغییر میدن ...

---

نقل قول:

---

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

نقل قول:
...هر کدوم بسته به نیازشون ارتباط بین جدولها رو تغییر میدن ...

---

منظورتون نمونه سورسه یا همینجا توضیح بدم؟

سلام
میبخشید ویندوز عوض کردم، کمی الاف شدم ... !

سه جدول زیر را در نظر بگیرید ...

کد:

---

Invoices (فاکتورها)
==============
ID_Invoice int PK-AutoNumbet-ReadOnly (کلید و مخفی)
InvoiceCode int UniqueIndex (شماره فاکتور قابل تخصیص توسط کاربر)
RegisterDate smalldatetime (تاریخ ثبت)
Seller nvarchar (فروشنده)
Buyer nvarchar (خریدار)
...
...
SellerGrandFatherPicture varbinary (! تصویر اسکن شده پدر بزرگ فروشنده !)
...
...
Description nvarchar (توضیحات)

------------------------------------------------------------------------

Goods (کالاها)
==============
ID_Good int PK-AutoNumbet-ReadOnly (کلید و مخفی)
GoodCode int UniqueIndex (کد کالا قابل تخصیص توسط کاربر)
RegisterDate smalldatetime (تاریخ ثبت)
Price int (قیمت)
...
...
ProducerGrandFatherPicture varbinary (! تصویر اسکن شده پدر بزرگ تولید کننده !)
...
...
Picture varbinary (تصویر کالا)
Description nvarchar (توضیحات)

------------------------------------------------------------------------

Invoices_Goods (جزئیات آیتم های فاکتورها)
==============
ID_Invoice int PK1 (کلید و مخفی)
ID_Good int PK2 (کلید و مخفی)
Qty int (تعداد)
Price int (قیمت در زمان اضافه شدن به فاکتور)
...
...

---

رابطه جداول هم کاملاً مشخص است.
دو جدول اول با فیلد کلیدشان با جدول سوم ارتباط دارند.
(
پیشنهاد میکنم برای سادگی بحث و رفع مشکل، شما هم اگر مثال و ابهامی داشتید روی همین مدل سه جدولی فوق با همین فیلدها توضیح داده و بحثتان را مطرح کنید.
)


حالا وضعیت های مختلف را بررسی میکنیم:
----- زمان اضافه کردن فاکتور جدید (Invoices-INSERT)
شما سطر را در دیتابیس INSERT میکنید و یک ID_Invoice صدردصد سالم و منجحصر به فرد و مخصوص همین فاکتور میگیرد.
بعد هم تک تک کالاها را با توجه به کدشان که ID_Good باشد و شماره فاکتور که ID_Invoice باشد (و از مرحله قبل گرفته اید) به جدول Invoices_Goods اضافه میکنید.
چون ID_Invoce منحصر به فرد است با سایر برنامه های شبکه هم مشکلی ایجاد نمیشود.

----- زمان تغییر موارد فیلدهای فاکتور در جدول اصلی (Invoices-UPDATE)
چون تمام ارتباط جدول فوق با جدول 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 دیگر معنی ندارد و نباید انجام شود (کسی انتظار دیگری ندارد!)
- ولی نباسید چنین شود که چون سطر اصلی را نیافته سطر اشتباهی دیگری را تغییر ندهد. (این است که باید در برنامه تضمینش کنید.)

نقل قول:

---

منظورتون نمونه سورسه یا همینجا توضیح بدم؟

---

منظورم چیزی مثل همین شرح فوق بود.
اگر تداخلی در تئوری فوق درک میکنید، لطفاً بیان کنید.


موفق باشید.

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

حالا کاربری که در حال ویرایش هستش اگر همون 6 فیلد باشه خوب به قول شما Update Where چون برقرار نیست عمل نمیکنه
اما اگر این 6 قلم کالا تبدیل به 8 قلم بشه و دو کالای جدید به لیست ویرایش اضافه بشه دیگه عمل Insert به ازای 2 رکورد انجام میشه و چون عمل درج هستش پس اجام میشه
اینو چطوری حل میشه؟

سلام

نقل قول:

---

حالا کاربری که در حال ویرایش هستش اگر همون 6 فیلد باشه خوب به قول شما Update Where چون برقرار نیست عمل نمیکنه
اما اگر این 6 قلم کالا تبدیل به 8 قلم بشه و دو کالای جدید به لیست ویرایش اضافه بشه دیگه عمل Insert به ازای 2 رکورد انجام میشه و چون عمل درج هستش پس اجام میشه
اینو چطوری حل میشه؟

---

خوب تازه حالا این شد یک چیزی!!!
این در تعریف اختلال میگنجد و دقیقاً شرح های منطقی این تیپی مد نظر من بود که گفتم اگر تردیدی دارید بیان کنید.

اما راه حل:
کافی است در دستابیس بین جداول Relation تعریف کنید که البته SQLServer انها را Diagram هم می نامد.
در زمان تعریف و یا بعد ان همه گزینه های اجباری را فعال کنید:

کد:

---

Enforce For Replication = True
Enforce Foreign Key Constraint = True
Check Existing Data On Creation Or Re-Enabling = True
INSERT And UPDATE Specification -> Delete Role = Cascade
INSERT And UPDATE Specification -> Update Role = Cascade

---

(مورد آخری با فیلدهای AutoNumber برای PrimaryKey چندان لازم نیست)
با این تنظیمات SQLServer تضمین میکند که هیچگاه امکان ندارد همچین تداخلهایی رخ دهد.

اگر هم سطری در رابطه بالاسری (والد) حذف شود، خودکار همه زیر مجموعه ها (فرزندان) را خود SQLServer پاک میکند.
(یعنی با حذف سطر جدول Invoices همه سطرهای نظیر Invoices_Goods هم حذف خواهد شد و شما لازم نیست کاری کنید.)

اگر هم دستور INSERT ای بیاید که نظیر کلید بالاسری اش (والد) وجود نداشته باشد، SQLServer دستور INSERT و یا UPDATE که همچین وضعیتی را میخواهد ایجاد کند انجام نمیدهد و به ریسمان مذکور یک اثتثنا (همان خطای خودمان!) ارسال میکند.

نقل قول:

---

... عمل Insert به ازای 2 رکورد انجام میشه و چون عمل درج هستش پس اجام میشه ...

---

پس با فعال کردن گزینه های مذکور در دیتابیس و با در نظر گرفتن شرایط منطقی (که شما به خوبی تشریح کردید) کلایت دوم که خطا دریافت خواهد کرد و فقط کاری که شما باید در کدنویسی انجام دهید آن است که دستور Try برای عملتان قرار دهید و در Cacth نوع کلاس خطای مذکور را هندلر کنید و پیغام خطای مناسب فارسی را در قالب یک MsgBox نمایش دهید.

اگر موارد منطقی و استدلالی دیگر از این دست به ذهنتان رسید بیان کنید.

خیلی عالی بود ممنون

فکر کنم این پست آخر ارزش کل این تاپیک رو داشت

نقل قول:

---

اگر موارد منطقی و استدلالی دیگر از این دست به ذهنتان رسید بیان کنید.

---

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

من تو برنامه خودم 8 نوع فاکتور دارم
جهت ذخیره لیست این 8 نوع فاکتور از یک جدول به نام List_factor استفاده کردم و یک فیلد به نام State وجود دارد که نوع فاکتورها رو مشخص می کنه مثلا :
فاکتور شماره 1 با State مقدار 0 مربوط به فروش
فاکتور شماره 1 با State مقدار 5 مربوط به خرید

یعنی در این جدول ممکنه 8 تا شماره 1 وجود داشته باشه ولی اگر فیلد state اونها رو حساب کنی به ازای هر نوع فاکتور یک شماره وجود داره

آیا این روش باعث به هم خوردن Relation نمیشه(چون فیلد یکتا نیست)؟

اگر نمیشه پس باید از 8 تا جدول استفاده بشه که کار رو طولانی تر میکنه!
اگر از یک جدول استفاده بشه و فیلد شماره فاکتور یکتا باشه شماره فاکتورها پراکنده میشه مثلا
1 تا 10 فروش
11 برگشت از فروش
12 تا 15 خرید
...
که اینم زیاد جالب نیست
شما چه روشی رو پیشنهاد میکنید؟

سلام
برای برنامه شبکه ای و حداکثر تضمین صحت کارکرد شبکه ای، استفاده از Autonumber-PrimaryKey میتوانید خیلی کمک کند و حلال مشکلات باشد.
در ضمینه همین تداخل ها که بحث کردیم، من خودم در طی سالها بارها و در شرایط گوناگون (که الا« به ذهنم خودم هم نمیرسد!) این مسئله را تحلیل کرده بودم ولی برای همه موارد توجیح و راه حلی منطقی در Autonumber-PrimaryKey یافتم.

=====

من همچنان پیشنهاد میکنم PrimaryKey حقیقی و واقعی جدول در دیتابیس و برنامه (جهت ارجاع و عملیات) همان Autonumber باشد.
اینطوری مشکل شبکه و چند ریسمانی و برنامه نویسی اش خیلی ساده میشود و شما به عنوان برنامه نویس باید به موارد کمتری فکر کنید و ساده تر میتوانید کدنویسی کنید.

ولی میتوانید این فیلد اصلی را هیچ کجا نشان ندهید و به اقتضای منطق برنامه و شرایط و درخواست مشتریتان، بیایید و فیلدهای شبه primarykey و الکی از نظر برنامه نویسی برای او اضافه کنید ولی با ایندکس یکتا در دیتابیس تضمین کنید که تکراری نشود.

=====

یعنی خلاصه آنکه ...
پیشنهاد میکنم Autonumber-PrimaryKey را همچنان قرار دهید و با ان در دیتابیس و برنامه کار کنید و relation بدهید ولی برای کاربر من شرایط برنامه شما را نمیدانم...
- اگر راه دارد و برای شرایط کاری برنامه منطقی است یک فیلد شماره فاکتور اضافه کنید که کلاً و بدون در نظر گرفتن State یکتا باشد.
(در این شرایط شاید بتوانید شماره فاکتور را با ان autonumber یکی کنید.)

- اگر مورد بالا برای شرایط کاری برنامه منطقی نیست و باید هر نوع شماره های خودش را داشته باشد، خوب فیلد شماره فاکتور را با جفت State با هم UniqueIndex معرفی کنید.

با این شرایط کاربر برنامه هر موقع عشقش کشید میتوانید شماره فاکتور یا State را هم اصلاح کنید و همه چیز هم به ظاهر او قابل ویرایش و تغییر مجدد باشد.

نقل قول:

---

- اگر مورد بالا برای شرایط کاری برنامه منطقی نیست و باید هر نوع شماره های خودش را داشته باشد، خوب فیلد شماره فاکتور را با جفت State با هم UniqueIndex معرفی کنید.

---

فیلد State میتونه تکراری باشه چون هرچی فاکتور فروش وارد بشه این فیلد مقدار 0 میگیره ، برگشت از فروش مقدار 1 و الی آخر
البته اگر با فیلدIdFactor با هم مقایسه بشن تکراری نمیشه مثلا ممکن نیست دو تا شماره فاکتور یکسان State یکسان داشته باشن
با UniqueIndex کردن فیلد State مشکلی به وجود نمیاد؟

یه سئوال دیگه:
تو بعضی از توابع برنامه ام پیش میاد که 3 تا 4 دستور INSERT,DELETE,UPDATE انجام میشه که اینها رو پشت سر هم انجام میدادم مثلا اول دستور DELETE بعد INSERT و بعد UPDATE
بعضی مواقع مشکلاتی به وجود میامد که دو مرحله DELETE,INSERT انجام میشد ولی تو UPDATE دچار مشکل میشد(حالا به هر دلیلی)
تو این حالت اطلاعات دچار مشکل میشد چون یه مرحله از کار انجام نشده بود

چطور میشه کاری کرد که این دستورات یا همه اجرا بشن یا هیچکدوم ؟

سلام

نقل قول:

---

نوشته شده توسط MTPROG

البته اگر با فیلدIdFactor با هم مقایسه بشن تکراری نمیشه مثلا ممکن نیست دو تا شماره فاکتور یکسان State یکسان داشته باشن

---

خوب منظور من همین بود.
منطقی است شرایط برنامه شما طوری باشد که State و IdFactor شما هر کدام جداگانه تکراری باشند ولی دیگر منطقی نیست هر دو با هم و جفت تکرار شوند و حتماً در کنارهم منحصر به فرد خواهند بود و باید برای سرعت و جلوگیری از تداخل یکتا اعلام شوند.

نقل قول:

---

نوشته شده توسط _H2_

... شماره فاکتور را با جفت State با هم UniqueIndex معرفی کنید

---

نقل قول:

---

چطور میشه کاری کرد که این دستورات یا همه اجرا بشن یا هیچکدوم ؟

---

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

(
شما خودتان یک ذهنیتی دارید برای کسی که لزوم "همه یا هیچ" را درک نمیکند، مثال ساده ای میزنم تا تداخلش را درک کند:

پولی را میخواهید ااز یک حساب به حساب دیگر منتقل کنید.
در ساده ترین شرایط ممکن و با کمترین عملیات دو کار لازم است...
1) کسر پول از حساب مبداً و 2) افزودن پول به حساب مقصد
حالا فرض کنید کار نیمه انجام شود و فقط یکی از دو عمل فوق موفقیت امیز اجرا شود!
چه میشود؟
اگر 1) انجام شود و 2) انجام نشود (کاری به دلیلش نداریم، به هر دلیل!) پول حقیقی که قبلاً وجود داشته و مالکیت داشته در رایانه از بین میرود

اگر 2) انجام شود و 1) انجام نشود، پولی که وجود نداشته و مالکی ندارد و پشتوانه ای ندارد در رایانه خلق میشود و به وجود می آید.

پس اجرای عملیات فوق مستلزم "همه یا هیچ" است.
)

راه حل:
خوشبختانه اکثر بانکهای اطلاعاتی موجود این عملیات ها را خودشان پشتیبانی میکنند.
در T-SQL با دستورات BEGIN TRAN و COMMIT TRAN و ROLLBACK TRAN میتوانید تراکنش ها را ایجاد و مدیریت کنید.

کد:

---

BEGIN TRAN T1;

--...
--... any t-sql ...
--... if error then "ROLLBACK TRAN T1;"
--...

COMMIT TRAN T1;

---

ولی برای حالت عادی و معمول پیشنهاد میکنم تمام عملیات هایتان را (برای سرعت و شفافیت و قابلیت نگه داری) در بانک یک SP کنید و از دستورات فوق در آن استفاده کنید.

(یا در خود دات نت هم میتوانید با کلاس System.Data.SqlClient.SqlTransaction مشبه عمل فوق را انجام دهید.)

نقل قول:

---

خیلی جالب است، خیلی!!!!
شما حتی لفظ برنامه نویسی اش را هم نمیدانید اما دقیقاً دارید جملاتی را میگویید که برنامه نویسان گذشته دقیقاً همین جملات را تکرار کرده بودند و طراحان بانکهای اطلاعاتی رابطه ای هم با ان دست به گریبان بودند.

---

نمیدونم تیکه پروندی یا نصیحت کردی! به هر حال بگذریم

نقل قول:

---

در T-SQL با دستورات BEGIN TRAN و COMMIT TRAN و ROLLBACK TRAN میتوانید تراکنش ها را ایجاد و مدیریت کنید.


کد:
BEGIN TRAN T1;--...--... any t-sql ...--... if error then "ROLLBACK TRAN T1;"--...COMMIT TRAN T1;

---

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

نقل قول:

---

شما خودتان یک ذهنیتی دارید برای کسی که لزوم "همه یا هیچ" را درک نمیکند، مثال ساده ای میزنم تا تداخلش را درک کند:

پولی را میخواهید ااز یک حساب به حساب دیگر منتقل کنید.
در ساده ترین شرایط ممکن و با کمترین عملیات دو کار لازم است...
1) کسر پول از حساب مبداً و 2) افزودن پول به حساب مقصد
حالا فرض کنید کار نیمه انجام شود و فقط یکی از دو عمل فوق موفقیت امیز اجرا شود!
چه میشود؟
اگر 1) انجام شود و 2) انجام نشود (کاری به دلیلش نداریم، به هر دلیل!) پول حقیقی که قبلاً وجود داشته و مالکیت داشته در رایانه از بین میرود

اگر 2) انجام شود و 1) انجام نشود، پولی که وجود نداشته و مالکی ندارد و پشتوانه ای ندارد در رایانه خلق میشود و به وجود می آید.

پس اجرای عملیات فوق مستلزم "همه یا هیچ" است

---

خوب این هم دقیقا شبیه همون مثال منه

نقل قول:

---

(یا در خود دات نت هم میتوانید با کلاس System.Data.SqlClient.SqlTransaction مشبه عمل فوق را انجام دهید.)

---

این بیشتر به درد میخوره ولی باهاش کار نکردم اگه میشه یه کم درباره ش توضیح بدید

سلام

نقل قول:

---

نمیدونم تیکه پروندی یا نصیحت کردی!

---

هیچ نوع قصد بدی نداشتم.
فقط میخواستم بیان کنم که انسانها با اینکه در سرزمین های جداگانه و با اختلاف زمانی مختلفی هستند، چطور به یک مفاهیم واحد میرسند و برای بیان ان مفاهیم هم (بدون هیچ پیش ضمینه ای) از لغات یکسانی استفاده میکنند.
(یکم بحث فلسفی بود!!! :31:)

نقل قول:

---

... ولی این روش رو فقط تو خود محیط SQL میشه اجرا کرد ...

---

بله برای این مورد طراحی شده ولی همینطوری در کد هم قابل استفاده است (که چندان جالب نیست)
ولی حالا استفاده فققط در SQL و در طی دستورات T-SQL مشخص در SP های مشخص چه ایرادی دارد؟؟؟

به نظر من که (خارج از بحث فوق) هر چه بتوان برنامه را به لایه های مجزا تفکیک کرد و کلاً دستورات SQL را از بیخ و بن از درون کدها حذف کرد و به خود دیتابیس منتقل کرد خیلی بهتر است.
باعث شفافیت بیشتر و افزایش اصل نگه داری و سرعت دیباگ و بازدهی و سرعت بیشتر برنامه خواهد شد.

نقل قول:

---

این بیشتر به درد میخوره ولی باهاش کار نکردم اگه میشه یه کم درباره ش توضیح بدید

---

نمونه کد:
msdn.microsoft.com/en-us/library/system.data.sqlclient.sqltransaction.aspx

نقل قول:

---

ه نظر من که (خارج از بحث فوق) هر چه بتوان برنامه را به لایه های مجزا تفکیک کرد و کلاً دستورات SQL را از بیخ و بن از درون کدها حذف کرد و به خود دیتابیس منتقل کرد خیلی بهتر است.
باعث شفافیت بیشتر و افزایش اصل نگه داری و سرعت دیباگ و بازدهی و سرعت بیشتر برنامه خواهد شد.

---

اگر دستورات مربوط به بانک تو خود اسکول باشه امنیت سورسهات پایین نمیاد؟
برای دستوراتی که وابسته به انتخاب نوع اطلاعات کاربر هستند و ورودی متغییر میگیرند(مثلا حساب کاربر شماره 5 یا ذخیره 8 رکورد با اطلاعات مختلف) آیا کاملا جوابگو هستش. چطور میشه اطلاعات اینچنین متغییری رو به دستورات از قبل آماده شده فرستاد ؟

نقل قول:

---

نمونه کد:
msdn.microsoft.com/en-us/library/system.data.sqlclient.sqltransaction.aspx _

---

کد خیلی عالی و واضحیه ممنون

سلام

نقل قول:

---

امنیت سورسهات پایین نمیاد؟

---

اخه چی را میخواهید لو نرود؟؟؟ یک دستور SQL ای DELETE یا UPDATE یا ...
به نظر شخصی من با وجودی که زبان TSQL کلمات و امکانات زیادی دارد ولی ارزش خاصی ندارد.

من لایه بندی و شفافیت کدها و نیز توسعه آینده ساده تر و اشکال یابی و رفع باگ سریعتر و سرعت بیشتر برنامه را ترجیح میدهم به اینکه کسی نتواند TSQL های من را ببینید!

کدهای قاطی و اسپاگتی وار میتواند در زمان رفع ایراد چالش جدی ایجاد کنند و خود برنامه نویس هم سردرد بگیرد که بین صفحات کدش جا به جا شود بعد هم هر بخش را دستکاری میکنید جای دیگر خراب میشود ، من وقتی برخی کدهای افراد را میبینیم از درهم بودن کدها و قاطی پاتی بودن بخش ها (فقط از دیدنش) دچار سردد میشوم! خدا صبر بده به برنامه نویش!

یک اصل منطقی و پذیرفته شده برنامه نویسی "اصل قابلیت نگه داری" است که به توسعه و رفع اشکال و ادامه بهره برداری از کد در آینده اشاره میکند و شرکت های بزرگ خیلی از چیزها را بابت رسیدن به این اصل فدا میکنند.

تازه SP ها چون ثابت در داخل خود SQLServer هستند، هسته مرکزی آنها را بهینه سازی میکند و مسیرهای ایندکسی لازم و عملیات های مورد نیاز را قبلاً پردازش کرده و ذخیره میکند.
یک حالتی شبیه یک نوع نیمچه کامپایل!

در حالی که دستورات SQL عادی شما string خالص هستند و تازه باید بروند و پردازش متنی شوند و بعد ...

=====

چون استفاده نمیکنم، فراموش کرده ام ولی گمانم SQLServer امکانی برای حفاظت و عدم رویت کدهای SQL داخل SP هایش داشته باشد.
در msdn جستجو کنید شاید پیدایش کنید.

نقل قول:

---

آیا کاملا جوابگو هستش

---

شما باید تا حد امکان و تا جایی که میتواند SP هایی برای کارهای مختلفتان ایجاد کنید که طبیعتاً پارامترهایی بگیرند و کاری انجام دهند که میتواند موارد ساده تا پیچیده را شامل شود!
مثلاً به همین سادگی:

کد:

---

CREATE PROCEDURE Users_DELETE
(
@ID_User int
)
AS

DELETE FROM [Users] WHERE ([ID_User] = @ID_User);

---

بعد دیگر اگر در جای خیلی خاص و ویژه ای نمیشد کاری کرد که دستور SQL حتماً از قبل مشخص و واضح باشد و پارامتری مقدار بگیرد، دیگر ناچاراً میتوانید از سایر روشها استفاده کنید.

موفق باشید.

نقل قول:

---

اخه چی را میخواهید لو نرود؟؟؟ یک دستور SQL ای DELETE یا UPDATE یا ...

---

همه کارها یک DELETE یا UPDATE نیستند بعضی ها گزارشهای مهمی هستند که نیاید هیچ جا درز بشه

(ما برای یک تاجر برنج که تو خاورمیانه برو بیایی داره بک برنامه تحت شبکه مخصوص مدیریت و پیگیری فروش ساختیم
که آمارهای فروش و نوع تجارتش توش بود یه روز یه بکاپ اونو تو شرکت داشتیم بررسی میکردیم که یه تاجر دیگه اومد اونجا و اون اطلاعات رو دید حاضر بود 10 میلیون پول بابت اون بکاپ رقیب تجاریش بده)

البته تا حدی هم حق با شماست اگر کاربر میخواد اطلاعتش سالم بمونه نزاره کسی بره پشت سرورش
ولی در عوض سرعت کارش بالا میره و همون بقیه مثالی که شما ذکر کردید

تا حالا چندتا نرم افزار تحت شبکه که تو ایران اسم و رسمی به هم زدن دیدم و سر بانکشون رفتم هیچکدوم از SP,View و سایر موارد دیگه تو بانک میشه انجام داد استفاده نکردن گفتم شاید حتما ارزشو داره که تمام کارهاتو تو خود برنامه انجام بدی!

سلام

نقل قول:

---

همه کارها یک DELETE یا UPDATE نیستند بعضی ها گزارشهای مهمی هستند که نیاید هیچ جا درز بشه

---

یعنی چی؟ یعنی چون خروجی گزارش حاوی اطلاعات مهمی است دستور SQL اش نباید دیده شود ولی دیدن مقادیر جداول مشکلی ندارد!!!

نقل قول:

---

حاضر بود 10 میلیون پول بابت اون بکاپ رقیب تجاریش بده

---

تاجایی که من یادم می آید بحث ما سر دستورات SQL بود که داخل برنامه String بماند یا در بانک به صورت SP و View و ... باشد.
من واقعاً مثال شما را نمیتوانم با بحث خودمان تطبیق دهم.
من که نگفتم اطلاعات را محافظت نکنید! یا فایل backup را فشرده و رمزنگاری نکنید! اتفاقاً در سایزهای معقول فشرده سازی و رمزنگاری فایلهای پشتیبان به نظرم کار خوبی است.

نقل قول:

---

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

---

شما میتوانید برنامه های ویرایشی SQLServer را برای رایانه مقصد نصب نکنید که از جمله مهم ترین این ابزار SSMS است.
برای ورود به برنامه و اتصال به دیتابیس هم رمز عبور تایین کنید.
بارها گفتم امنیت SQLServer بسیار دقیق و گسترده و کامل است ولی پیشفرض ان امنیت فیزیکی دسترسی به سرور است.

اگر به فکر این هستید که فردا آمدند و کیس را یک تکه دزدیدند، باز هم اطلاعات درز نکند (!!!) دیگر باید اطلاعات را داخل دیتابیس رمزنگاری کنید!
اگر فکر میکنید کار به دزدیدن کیس نمی انجامد شاید نیازی به رمزنگاری نباشد و تدابیر دیگر ویندوزی و دیتابیسی کافی باشد.
ولی این مطلب بازهم ارتباطی با دستورات SQL و بهینه سازی و لایه بندی انها ندارد.

نقل قول:

---

تا حالا چندتا نرم افزار تحت شبکه که تو ایران اسم و رسمی به هم زدن دیدم و سر بانکشون رفتم هیچکدوم از SP,View و سایر موارد دیگه تو بانک میشه انجام داد استفاده نکردن گفتم شاید حتما ارزشو داره که تمام کارهاتو تو خود برنامه انجام بدی!

---

من هم تا حالا برنامه های دسکتاپی و وبی ایرانی اسم درکرده و معروف زیادی دیده ام و به جرآت میگویم که اگر من میخواستم نمره دهم از بیست نمره با بالای 6 یا 7 نمیدادم.
خودم یک سایت پر ادعای ایرانی طراحی شده میشناسم (و برنامه نویسش را نمیشناسم) ولی حاضر فتوا دهم برنامه نویسش برخلاف کلاس و ادعا و پز سایت مطلقاً سواد برنامه نویسی نداشته.
(
قبلاً هم در تاپیک دیگری گفتم، ماشا ا... برنامه نویسان ایرانی (دور از جون دوستان عزیز این سایت :10:) فقط اینقدر وقت میکنند که اول Caption فرم را حذف کنند و یک و بعد هم یک عکس منظره بیاندازند تنگ فرم بعد هم دکمه های را دایره ای کنند و با حرکت ماوس استایل دکمه بین نقره ای و بلورین و طلایین سوییچ کند، دیگر گمانم وقتی برایشان نمیماند که برنامه نویسی لایه بندی شده و شی گرایانه و اصولی انجام دهند و دیتابیس را نرمال کنند و اصول کدنویسی قابل نگه داری طولانی مدت و کد نویسی با بازده و سرعت بالا و کدهای مناسب چند ریسمانی و شبکه و... و... و... را یادبگیرند و پیاده سازی کنند.
)

=====

مجدد تاکید میکنم که فقط از جهت محافظت از سورس کدها شاید شاید شاید شاید شاید منطقی باشد برخی دستورات SQL محافظت شوند که در این صورت هم ...
1) باز باید سرعت و بازدهی برنامه و رضایتمندی سفارش دهنده را مد نظر داشت
2) همانطور که گفتم احتمال دارد SQLServer امکاناتی در جهت محافظت از سورس های SQL اجزای خودش داشته باشد ولی آلان چیزی یادم نمی آید و فرصت خالی کافی برای بررسی در msdn را ندارم.

موفق باشید.

نقل قول:

---

یعنی چی؟ یعنی چون خروجی گزارش حاوی اطلاعات مهمی است دستور SQL اش نباید دیده شود ولی دیدن مقادیر جداول مشکلی ندارد!!!

---

تو گزارشهای پیچیده دیدن جدول اصلا مهم نیست چون اطلاعت اون جداول به علت ارتباط چند به چند شامل فیلدهای عددی نا مفهوم است و با دیدن این جداول هیچ چی دستگیر کسی نمیشه ولی با اجرای View,SP های اماده اطلاعات مهم فاش میشه

نقل قول:

---

تاجایی که من یادم می آید بحث ما سر دستورات SQL بود که داخل برنامه String بماند یا در بانک به صورت SP و View و ... باشد.
من واقعاً مثال شما را نمیتوانم با بحث خودمان تطبیق دهم

---

بحث سر امنیت نمایش اطلاعات هستش چرا تطبیق نداره الان چه بکاپ ببره چه بره سر بانک وقتی SP و View اماده است کار تمومه
اصلا بحثی هست به نام SQL Injection که هکر میتونه تو شبکه یا تو اینترنت با تزریق دستوراتی به SQL SERVER دستورات SP و View رو بدست بیاره و اونو اجرا کنه و اطلاعاتو بکشه بیرون (بالاخره SQL هم هر چقدر قوی باشه بازم جای ضعف داره)
PDF زیر توضیحاتی درباره SQL Injection نوشته
[HTML]http://www.divshare.com/download/8499004-c55[/HTML]

حالا شاید بگید کی میتونه این کارو بکنه ولی بهتر نیست که خودمونو با اصولی ترین روش و بهینه ترین روش که کمترین ایراد رو داشته باشه تطبیق بدیم
(تا به قول شما مثل بعضی برنامه نویسان ایرانی پر مدعا و بی سواد نشیم! )(جنبه شوخی داشت)

سلام
بحرحال من فقط و فقط یک روش برای حفاظت از دیتاهای شبکه های مبتنی بر SQLServer بلد هستم که بسیار قوئی است.
1) SQLServer را در رایانه سرور و با ترجیحاٌ یک user و pass نصب میکنیم
2) برای اتصال به SQLServer مفاهیم login و user و pass با اختیارات معلوم و به حد لازم محدود شده تعریف میکنیم.
3) برای اکانت های administrator یک password محکم و سری میگذاریم.
4) برای اطمینان نهایی و صد در صد اتاق سرور را از نظر امنیتی از سایر بخش ها ایزوله میکنم و یک چندتایی قفل خفن به دربش میزنیم!

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

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

برای موارد کوچک تر هم میتوان از مورد 4) صرف نظر کرد ولی دیگر باید بخش های رایانه password داشته باشد.
(منظورم password واقعی است، نه اینکه میوه فروشی سر کوچهه هم password را بداند و فقط بماند خواجه حافظ شیرازی مظلوم !:31:)

=====

اما اگر میخواهید برنامه را عمومی بفروشید و در جهت امنیت کدها و اینکه برنامه نویس دیگری نتواند برود CD برنامه شما را بخرد و روش شما را تجزیه کند و از ان کپی کند، من راحتان کنم که کمکی نمیتوانم بکنم.
(که گمانم نگرانی شما از این جهت است)

خود من شخصاً به این موارد اهمیتی نخواهم داد و معتقدم صرف لو رفتن جداول و ساختار ها و یک دیتابیس عادی نرمال شده نمیتواند امنیت کپی رایتی محصول من را در قبال سایر برنامه نویسان و رقبا کاهش دهد.


یعنی اگر نگرانی امنیتی به معنای واقعی ان دارید با روشهای صحیح قابل حل است ولی اگر خیلی نگرانی لو رفتن ساختار دیتابیس و ارتباط جداول را دارید، دستورات SQL را داخل برنامه مستقر کنید!

=====

نقل قول:

---

اصلا بحثی هست به نام SQL Injection

---

1)
من هنوز PDF شما را دانلود نکرده ام ولی با این مورد کاملاً آشنایی دارم و تضمین 100% میدهم اگر کد نویسی اصولی و منطقی انجام دهید و همه موارد و اصول برنامه نویسی را رعایت کنید هیچ مشکلی پیش نمی آید.

2)
ضمن اینکه بحث وجود SP و View و... هم هیچ تاثیر بد و خوبی روی مورد فوق ندارد و من ان را در بحث جاری مان چندان مرتبط نمیبینم.

=====

موفق باشید. :10: