اس کیو ال روی شبکه [بایگانی]

payam_skandari

پنج شنبه 30 فروردین 1386, 01:12 صبح

دوستای عزیز یه شرکت هست که سیستم مالی و حسابداریشو دارم مینویسم . این سیستم روی شبکه و باحدود 50 کاربر کار خواهد کرد .اگه میشه مطالبی رو که در رابطه با کار با بانک اطلاعاتی (sql server 2005)مهمه که مد نظر داشت رو توضیح بدین.منظورم تداخل کاربر ها موقع ورود رکورد ها با فیلدهاییی که کاملا یکسان هستند. و مثلا یک کاربر چند رکورد رو select کرده و داره ویرایششون میکنه و دقیقا همین موقع یکی یا چند تا از همین رکورد ها توسط کاربر دیگه ای ویرایش میشه.چطور باید این جور چیزها رو هندل کرد. ضمنا دوستان اگر تجربه ای از این دست تو برنامه نویسی شبکه دارن لطف کنن بگن.
در واقع .من خیلی نگران تداخل کاربر ها موقع پاک کردن یا update کردن رکورد هاهستم.بابت اینها دقیقا باید چیکار کرد.
و در کل توی این شکل برنامه های چند کاربره روی شبکه چه مشکلات احتمالی مثل همین تداخل ها ممکنه بوجود بیاد و راه حلشون چیه.
ممنون میشم توضیحاتتون حتی الامکان با کد باشه.و احتمالا جامع و با یه نگاه کلی.

ممنون.

DonetKarvb

پنج شنبه 30 فروردین 1386, 13:55 عصر

دوستای عزیز یه شرکت هست که سیستم مالی و حسابداریشو دارم مینویسم . این سیستم روی شبکه و باحدود 50 کاربر کار خواهد کرد .اگه میشه مطالبی رو که در رابطه با کار با بانک اطلاعاتی (sql server 2005)مهمه که مد نظر داشت رو توضیح بدین.منظورم تداخل کاربر ها موقع ورود رکورد ها با فیلدهاییی که کاملا یکسان هستند. و مثلا یک کاربر چند رکورد رو select کرده و داره ویرایششون میکنه و دقیقا همین موقع یکی یا چند تا از همین رکورد ها توسط کاربر دیگه ای ویرایش میشه.چطور باید این جور چیزها رو هندل کرد. ضمنا دوستان اگر تجربه ای از این دست تو برنامه نویسی شبکه دارن لطف کنن بگن.
در واقع .من خیلی نگران تداخل کاربر ها موقع پاک کردن یا update کردن رکورد هاهستم.بابت اینها دقیقا باید چیکار کرد.
و در کل توی این شکل برنامه های چند کاربره روی شبکه چه مشکلات احتمالی مثل همین تداخل ها ممکنه بوجود بیاد و راه حلشون چیه.
ممنون میشم توضیحاتتون حتی الامکان با کد باشه.و احتمالا جامع و با یه نگاه کلی.

ممنون.
این مسئله ای رو که شما بیان کرده اید بر میگردد به مبحثی به نام همزمانی کاربران در SQL Server که بسیار جالب است. در حالت عادی وقتی یک کاربر شروع به ویرایش رکوردی میکند اون رکورد توسط اون کاربر lock میشه و کاربران دیگری که میخواهند از اون رکورد استفاده کنند block میشوند. به طوریکه منتظر میمانند ویرایش این رکورد به اتمام برسد تا بتوانند از آن استفاده کنند.
این تنظیمات پیش فرض SQL Server است که به کاربر اجازه خواندن دادهایی که commit نشده اند را نمیدهد. حالت های دیگری نیز وجود دارد که بسته به شرایط از آنها استفاده میشود.

payam_skandari

پنج شنبه 30 فروردین 1386, 20:38 عصر

خوب؟ جواب سوال چیه؟راه حل ؟

مهدی نان شکری

پنج شنبه 30 فروردین 1386, 20:59 عصر

با سلام
این سوال منم هست که تا حالا جوابی درست و حسابی براش پیدا نکردم.
مثلا اگه ما با دات نت براناممون رو بنویسیم و همچنین می دونیم که دات نت Connection less هست اون وقت SQL Server از کجا می دونه که باید چه رکوردی رو قفل کنه؟

مهدی نان شکری

پنج شنبه 30 فروردین 1386, 21:04 عصر

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

DonetKarvb

پنج شنبه 30 فروردین 1386, 21:30 عصر

خوب؟ جواب سوال چیه؟راه حل ؟
شما بدون نگرانی میتونید به کارتون ادامه بدهید. مگر اینکه نخواهید مواردی نظیر phantom Data داشته باشید. مثلا" شما یک ترنزکشن باز میکنید یک سلکت میزنید در هیمن حال یک کاربر دیگه تو این تیبل شما یک رکورد اینزرت میکند درحالی که شما هنوز ترنزکشن رو نبسته اید مجددا" سکلکت میزنید که نتیجه کوئری قبلی شما با کوئری جدید شما در همین ترنزکشن فرق میکند که در صورت نیاز باید از Isolation Level های دیگری استفاده کنید.

با سلام
این سوال منم هست که تا حالا جوابی درست و حسابی براش پیدا نکردم.
مثلا اگه ما با دات نت براناممون رو بنویسیم و همچنین می دونیم که دات نت Connection less هست اون وقت SQL Server از کجا می دونه که باید چه رکوردی رو قفل کنه؟
ببینید اینجا مبحث کلاینت نیست. مبحث دیتابیس است. مشکل اینجاست در یک ثانیه من در حال آپدیت کردن هستم و در ثانیه بعدی که هنوز عملایت آپدیت من تموم نشده شما میخواهید کوئری بگیرید. حالا وظیفه SQL Server چیست؟ چه چیزی رو به شما نمایش دهد.؟؟؟ وقتی که دیتا به سمت کلاینت فرستاده شد یک ترنزکشن کارش تمام شد. دیگر دلیلی ندارد که رکورد ها را قفل کند. فرض کنید SQL Server یک رکورد را فرستاد سمت کلاینت آیا کس دیگری حق ویرایش این رکورد را ندارد؟؟؟ نه صبحت بر روی ثاینه و میلی ثانیه ها است. نه بر روی اینکه یک تیبل به سوی کلاینت فرستاده میشود تغیییراتی انجام داده میشود و حالا میخواهد آپدیت شود. زمانی که این تغییرات میخواهد در SQL Server ثبت شود مهم است.

البته یکی از جواب هایی که خود MSDN نوشته استفاده از فیلد تاریخ هست که در اون آخرین تاریخ ویرایش شده رو نگه داریم و اگه کاربری خواست اون رکورد رو ویراش کنه تاریخ ها با هم مقایسه می شوند ، اگر برابر نبودن یعنی concurrency اتفاق افتاده . ولی این روش یه جوریه...
راه بعدی که خود MSDN پیش نهاد کرده استفاده از متد Update دیتا آداپتور در دات نت هست که اونم ویزاردی هست. و گاها به درد نمی خوره.
متد Update دیتا آداپتور ویزاردی نییست و خودتا نیز میتوانید batch Update داشته باشید. اتفاقا" شیوه مناسب و جالبی است . میتواند زمان آپدیت کردن را پایین تر بیاورد. در مجموع پیشنهاد میشود :چشمک:
برای اطلاعات بیشتر مقاله زیر رو بخونید:
استفاده از Batch Updates در ADO.NET 2 برای افزایش کارائی برنامه (http://www.dotnetsource.com/fa/forum/default.aspx?g=posts&t=534)
در بخش مقالات Ado.Net که برای خواندن مقاله باید عضو باشید.

payam_skandari

جمعه 31 فروردین 1386, 14:22 عصر

خوب راهش چیه؟چیکار باید کرد؟

DonetKarvb

جمعه 31 فروردین 1386, 14:58 عصر

خوب راهش چیه؟چیکار باید کرد؟
راستش من متوجه نمیشم. شما گفتید که چه مشکلاتی میتونه پیش بیاد منم براتون توضیح دادم. مشکلی در کار نیست با خیال راحت برنامتان را بنویسید.
خواهشا" اگر ابهامی هست درست بیان کنید نیایید بازم تو پست بعدی بگید مشکل چیه راه حل چیه....
:متفکر: :متفکر:

payam_skandari

شنبه 01 اردیبهشت 1386, 14:21 عصر

راستش من متوجه نمیشم. شما گفتید که چه مشکلاتی میتونه پیش بیاد منم براتون توضیح دادم. مشکلی در کار نیست با خیال راحت برنامتان را بنویسید.
خواهشا" اگر ابهامی هست درست بیان کنید نیایید بازم تو پست بعدی بگید مشکل چیه راه حل چیه....
:متفکر: :متفکر:
باید ببخشید این پست دو بار ارسال شده بود.مشکل در کانکشن اینترنتمه.
از جوابتونم ممنون.