Connected یا DisConnected، مساله این است؟

[odiseh]

سلام
من میخوام بدونم چرا دوستان گاهی دربرنامه های DBشون، از DataSet استفاده می کنن. من فکر می کنم که استفاده از مدل Disconnected ، حتما باعث ایجاد DirtyRead در Data خواهد شد.
اصلا همش تقصیر این Microsoft مغروره.

[HamidNazari]

ببینم یعنی اگه از Oracle یا DB2 یا MySQL یا هرچیز دیگه غیر از SQL Server استفاده بشه ، Dirty Read نخواهیم داشت ؟

[KambizZandi]

بستگي به برنامتون داره
در برنامه هاي enterprise اگر شما disconnected کار نکنيد حتما دچار مشکل خواهيد شد
در ضمن تو مواردي مثل remoting اصلا نبايد سراغ connected رفت (از سمت client)

[odiseh]

خوب همین برنامه هایEnterprise ، چطوری مطمئن هستید که DirtyRead پیش نمی آد؟ اصلا به نظر من مدل Disconnected مدل قابل اطمینانی نیست.




بستگي به برنامتون داره
در برنامه هاي enterprise اگر شما disconnected کار نکنيد حتما دچار مشکل خواهيد شد
در ضمن تو مواردي مثل remoting اصلا نبايد سراغ connected رفت (از سمت client)

[KambizZandi]

بستگي به بزرگي جامعه هدف داره
فرض کنيد جدولي داريد که مربوط به اطلاعات پايه مشتريان هست
چه افرادي ميتونند اونو تغيير بدن؟ در چه سطح دسترسي اي؟
در مدل ساده تر ما به جامعه هدف اتکا ميکنيم اما در مدلهاي پرکاربرد تر بايد از تکنيک هايي مثل lock و يا حتي پيشرفته تر از اون merge استفاده کنيم
مثل source safe که merge رو هم support ميکنه

[__H2__]

سلام
از مواردی که میتواند تا حد زیادی مشکل آپدیت ایمن را رفع کند، اول داشتن primarykey های autonumber در بانک اصلی سرور است و بعد هم گذاشتن استفاده از فیلد timestamp یا یک فیلد زمانی که اخرین تاریخ ویرایش سطر را مشخص کند.

خوشبختانه سه عمل آپدیتی بیشتر نداریم! UPDATE DELETE INSERT

UPDATE:
هم کلاینت و هم سرور در صورت UPDATE سطری فیلد زمانی مربوطه را به همان لحظه ست میکنند.
در عملیات merge آخرین زمان ملاک خواهد بود.

INSERT:
در سرور قطعی خواهد بود ولی در کلاینت با اعداد primarykey منفی انجام خواهد شد.
در عملیات Merge اطلاعات جدید سرور که برای انتقال به کلاینت (از روی primarykey و آن فیلد زمانی) مشخص است.
برای کلاینت به سرور هم باز مشکلی وجود ندارد و INSERT قطعی انجام شد و primarykey نهایی دریافت میشود.

DELETE:
در کلاینت و سرور عمل قطعی خواهد بود
و در merge به علت autonumber بودن فقدان سطر به راحتی مشخص خواهند شد.


البته هر کاری انجام دهید در نهایت احتمال اشتباه وجود خواهد داشت و فقط میتوان این احتمال را تا حد ممکن کاهش داد.
(اگر یک فیلد tinyint دیگر هم حداقل به کلاینت ها اضافه شود باز میتوان کار را دقیق تر انجام داد که در نهایت با حساب فیلد زمانی میشود 9 بایت اضافه در هر سطر!)

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

من خودم در شرکت درپیتمان(!) از الگوریتمی مشابه همین استفاده میکنم و پیاده سازیش هم اینطور ها که به نظر میرسد سخت و سنگین نیست.... با کمی فکر میتوانید با یک بار datareader گرفتن حلش کنید.