PDA

View Full Version : مشکل همزمانی یا concurrency



ب- تات
سه شنبه 18 اردیبهشت 1386, 13:14 عصر
دیتا بیس : اکسس
با ClientDataSet
سناریو:
دو تا کاربر همزمان اومدن داخل یک قسمت برنامه و هر دو یک رکورد از بانک رو دارن ادیت میکنن اولی ادیت میکنه و دومی هم ادیت میکنه . اولی Apply Update میکنه و اطلاعاتش با بانک ارسال میشه اما اگر حالا دومی بخواد apply update کنه ارسال نمیشه و در واقع مشکل همینجاست . شما نظرتون در شرائط اینچنینی چیه ؟

MNosouhi
سه شنبه 18 اردیبهشت 1386, 14:20 عصر
معمولا در این موارد رکورد رو قفل می کنن ، یعنی اولین کسی که ویرایش می کنه رکورد رو قفل میکنه ، نفر دوم وقتی میخاد رکورد رو در حالت ویرایش قرار بده پیغامی دریافت میکنه که امکان ویرایش وجود نداره، معمولا هم همه بانک ها این قضیه رو پشتیبانی می کنن.

ب- تات
سه شنبه 18 اردیبهشت 1386, 14:54 عصر
میشه لطفا توضیح بدین روشی رو که رکورد قفل میشه و حالا اگر فقط بخواهیم در اختیار کاربر بزاریم که انتخاب کنه آیا اطلاعات با وجود تغییرات توسط کاربر دیگر ذخیره شود یا نه اونوقت چی؟

MNosouhi
سه شنبه 18 اردیبهشت 1386, 20:10 عصر
روی خاصیت locktype عناصر ado تحقیق کن.

ب- تات
چهارشنبه 19 اردیبهشت 1386, 06:40 صبح
روی خاصیت locktype عناصر ado تحقیق کن.
باید عرض کنم پدر و مادر locktype رو بیرون آوردم اما اونها در این مورد نقشی ندارن تا قبل از نشستن دیتا توی بانک موفق هستن اما برای موردی که من ذکر کردم هیچ اثری ندارن.
من فکر میکردم این تاپیک بیشتر از اینها بحث داشته باشه چون مشکل به شکلی هست که تقریبا توی همه برنامه های تحت شبکه خودش رو نشون میده. لذا خواهش دارم اگه ممکنه عملی تر توضیح بدین.

mzjahromi
چهارشنبه 19 اردیبهشت 1386, 06:49 صبح
با SQL Server که مشکلی نداریم
من یه بررسی کردم روی اکسس ظاهرا قفل گذاری رو با دستورات اس کیو ال ساپورت نمیکنه

vcldeveloper
چهارشنبه 19 اردیبهشت 1386, 08:13 صبح
اینا رو ببینید:
http://www.barnamenevis.org/forum/showthread.php?t=30186
http://www.barnamenevis.org/forum/showthread.php?t=14406

ب- تات
چهارشنبه 19 اردیبهشت 1386, 09:33 صبح
مطلب جالبی بود.

با SQL Server که مشکلی نداریم
من یه بررسی کردم روی اکسس ظاهرا قفل گذاری رو با دستورات اس کیو ال ساپورت نمیکن
من همین کار را با بانک SQl شبیه سازی کردم دقیقا مشکل تکرار شد.
ببینید من روز فرمم یک ADOConnection که به َاکسس وصله
یک DataSetProvider که به یک AdoQuery وصله
و یک ClientDataSet که به DataSetProvider وصله
و من با CDS دارم با جدولم کار میکنم .
کاربر اول جدول رو باز میکنه یک فیلد را ویرایش میکنه
هم زمان کاربر دوم هم همان کار را میکنه .
حالا اگر یکی از این دو تا زودتر دستور Apply Update را اجرا کنه کاربر ثانی دیگه اطلاعاتش نادیده گرفته میشه . در واقع همونطور که میدونید Apply Update دیگه صفر برنمیگردونه و عدد یک را برمیگردونه که نشاندهنده یک خطاست.
در ضمن مجبورم از CDS استفاده کنم.
این کل ماجراست شاید هم مشکل کلی CDS هست . شما هم امتحان کنید . راه حلی یافتید من گوش به زنگم.

mzjahromi
چهارشنبه 19 اردیبهشت 1386, 10:49 صبح
این دقیقا اون چیزیه که باید کنترل بشه تا عدم همخوانی بوجود نیاد. در واقع این مساله به نفع شما است چون در غیر اینصورت اطلاعات شما خراب میشه. بسته به نوع و حساسیت کار باید از روشهای مختلفی برای حل این مساله(نه جلوگیری از آن) استفاده کرد

ب- تات
چهارشنبه 19 اردیبهشت 1386, 14:42 عصر
خوب پس نتیجه میگیریم که باید یکی از اینها رو انتخاب کرد:
1- تشخیص بدیم در هنگام ذخیره نهایی آیا کسی قبلا اطلاعات رو تغییر داده یا نه ؟
2- مجوز تغییر رکورد را بعد از اینکه توسط یک نفر به حالت ویرایش رفت رو برای دیگران لغو کنیم.

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

MNosouhi
چهارشنبه 19 اردیبهشت 1386, 20:00 عصر
حقیقت رو بخای Midas دلفی مشکل داره ، یعنی باگ داره ( کافیه در گروههای گوگل در اینباره جستجو کنید ) ، من یه مدتی خیلی دنبال این گشتم که بتونم با Midas برنامه تحت شبکه بنویسم ، اما با مشکلاتی مواجه شدم که در سایت هم مطرح کردم ولی راه حلی پیدا نشد ، البته میشد ماست مالیش کرد (همونطوری که اکثر برنامه نویس ها همین کار رو میکنن ) و در برنامه های معمولی هم که ما مینویسیم اثرش معلوم نمیشه ، اما چون از این کار خیلی بدم میاد کلا midas رو گزاشتم کنار تا در نسخه های بعدی دلفی ببینیم چه فکری برای شبکه میکنن.
حتی سعی کردم خودم اشکالات رو برطرف کنم ، اما متاسفانه قسمت مهمی از عملیاتی که در midas انجام میگیره در یه dll انجام میشه که سورسش در دسترس نیست.
ضمن اینکه خیلی از چیزهایی که در راهنمای دلفی در مورد پراپرتی های عناصر midas گفته شده ، هنگام پیاده سازی با sql درست عمل نمی کنن ( نمونش هم همون locktype ، البته اگر مثلا از interbase استفاده کنی اکثرشون درست کار میکنن) ، پس بهتره بگم که sql خیلی با دلفی ست نیست.
در کل از نظر من midas با sql چیز مسخره ای هستش ، درسته کار رو راه میندازه ، اما اصلا استاندارد نیست (البته میدونم که خیلی ها با نظر من مخالفن)
الان با dbisam شبکه میکنم ، اون هم مشکلات خودش رو داره ، اما خب مزیتش اینه که اولا سورسش در دسترسه ، ثانیا یه تیم پشتیبانی قوی داره که بدون اینکه توجهی به این بکنن که شما dbisam رو خریدی یا داری نسخه کرک استفاده میکنی ، سریع پشتیبانید می کنن (بورلند عمل خاصی در مورد باگ ها انجام نداده) ، ثالثا چون با دلفی نوشته شده کاملا با این زبان ست هست ، رابعا ... (اگه بخام همش رو بنویسم هم خودم رو خسته میکنم و هم سر شما رو درد میارم)

mzjahromi
پنج شنبه 20 اردیبهشت 1386, 06:53 صبح
در کل از نظر من midas با sql چیز مسخره ای هستش ، درسته کار رو راه میندازه ، اما اصلا استاندارد نیست (البته میدونم که خیلی ها با نظر من مخالفن)
اصلا اینطور نیست. طبیعتا هر ابزاری که ما استفاده میکنیم یه جاهائی مشکل داره پس میتونیم از هیچ ابزاری استفاده نکنیم؟ میشه اون ضعفهائی که شما باهاش برخورد کردی رو از راههای دیگه پوشش داد%


خوب پس نتیجه میگیریم که باید یکی از اینها رو انتخاب کرد:
1- تشخیص بدیم در هنگام ذخیره نهایی آیا کسی قبلا اطلاعات رو تغییر داده یا نه ؟
2- مجوز تغییر رکورد را بعد از اینکه توسط یک نفر به حالت ویرایش رفت رو برای دیگران لغو کنیم.

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

MNosouhi
پنج شنبه 20 اردیبهشت 1386, 07:59 صبح
اصلا اینطور نیست. طبیعتا هر ابزاری که ما استفاده میکنیم یه جاهائی مشکل داره پس میتونیم از هیچ ابزاری استفاده نکنیم؟ میشه اون ضعفهائی که شما باهاش برخورد کردی رو از راههای دیگه پوشش داد%
البته من بین اینکه یک مشکل رو به طور دیگه پوشش داد و اینکه مشکل رو ماست مالی کرد فرق میزارم . البته الان خیلی یادم نیست که به چه مشکلاتی برخوردم ، اما یه نمونه از مشکلات cds رو میگم که نمیشد طور دیگه ای پوشش داد ، فقط میشد ماست مالیش کرد :
فرضا شما در بانکت رکورد از نوع autoinc داشته باشی ، حالا شما یک رکورد جدید ایجاد می کنی و applyUpdate کنی ، خب مشاهده می کنید که فیلد از نوع autoinc خالی میمونه (تا زمانی که بازیابی بشه) ، اولا که به نظر من این وظیفه موتور بانک اطلاعاتیه که چون ما فیلد autoinc داشته ایم خودش فقط مقدار این فیلد رو برگردونه که البته نمیکنه و ما باید خودمون اقدام به بازیابی کنیم ، خب دستور refreshrecord هم که کار نمیکنه ، چون احتیاج به اطلاعات فیلد کلید که همون فیلد autoinc داره که اون رو هم هنوز نداریم ، پس تنها راه refresh کردن کل جدوله که این میشه همون ماست مالی ، شما در نظر داشته باشید که مثلا جدولتون 100000 رکورد داشته باشه و تحت شبکه هم باشه ، حالا برای هر رکورد جدیدی که وارد میکنیم یه بار بابد کل جدول رو refresh ( که اصلا این کار استاندارد و منطقی نیست ) کنید که حتما میدونید با سرعتی که sql داره این یعنی فاجعه و غیر این کلی از پهنای باند شبکه شما بیهوده صرف فقط بازیابی میشه . من خیلی سعی کردم که این مشکل را با کد نویسی جانبی ، استفاده از ابزارهای دیگه یا دستکاری سورس miad تصحیح یا راه حل منطقی براش پیدا کنم ، اما نشد ، از بسیاری از دوستان و اساتید هم در این زمینه کمک گرفتم ، اما به دلیل اینکه سورس به صورت کامل در اختیار ما نبود نشد کاری کرد.
خوشحال میشم اگر شما بتونید راه حلی برای این موضوع پیدا کنید.

vcldeveloper
پنج شنبه 20 اردیبهشت 1386, 09:12 صبح
حقیقت رو بخای Midas دلفی مشکل داره ، یعنی باگ داره
همه نرم افزارها باگ دارند، Midas هم استثنا نیست، اما باگش در حد معموله. این حرف شما مثل این میمونه که بگیم ویندوز باگ داره، پس نباید ازش استفاده کرد. Midas امکانات بسیار زیادی را برای برنامه نویس فراهم میکنه، بخوبی عمل میکنه، و توسعه اش هم متوقف نشده. افراد زیادی از Midas برای توسعه نرم افزارهاشون استفاده می کنند، به نظر شما همشون ماست مالی می کنند؟!!

ضمن اینکه خیلی از چیزهایی که در راهنمای دلفی در مورد پراپرتی های عناصر midas گفته شده ، هنگام پیاده سازی با sql درست عمل نمی کنن ( نمونش هم همون locktype ، البته اگر مثلا از interbase استفاده کنی اکثرشون درست کار میکنن) ، پس بهتره بگم که sql خیلی با دلفی ست نیست.
این از اون حرفهای جالب انگیزناک بود!!! من تا به حال مشکلی در کار با SQL Server از طریق دلفی و Midas نداشتم.
امکاناتی که در برخی از پراپرتی ها می بینید، باید توسط درایور بانک اطلاعاتی و خود موتور بانک اطلاعاتی پشتیبانی بشند.


فرضا شما در بانکت رکورد از نوع autoinc داشته باشی ، حالا شما یک رکورد جدید ایجاد می کنی و applyUpdate کنی ، خب مشاهده می کنید که فیلد از نوع autoinc خالی میمونه (تا زمانی که بازیابی بشه) ، اولا که به نظر من این وظیفه موتور بانک اطلاعاتیه که چون ما فیلد autoinc داشته ایم خودش فقط مقدار این فیلد رو برگردونه که البته نمیکنه و ما باید خودمون اقدام به بازیابی کنی...
شما اول ببین Midas را برای چه کاری می خوای استفاده کنی، بعد انتقاد بکن. از Midas برای توسعه برنامه ای 3-tier استفاده میشه. چرا باید در همچین برنامه ایی یک فیلد AutoInc بصورت اتوماتیک برای کلاینت ارسال بشه؟! انتقال داده ها به بانک از طریق Data Provider موجود در Application Servre صورت میگیره. Data Provider می تونه قبل از ثبت داده ها، فیلد مربوطه را پر کند، یا مقدار آن را از بانک بگیرد، بدون آنکه ClientDataSet در این فرایند دخالتی داشته باشه.
به نظر میاد بیشتر مشکلات شما از اونجا ناشی شده که شما می خواستی یک برنامه Client/Server را با Midas پیاده سازی کنی.

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

موفق باشید

ب- تات
پنج شنبه 20 اردیبهشت 1386, 09:25 صبح
حالا شما یک رکورد جدید ایجاد می کنی و applyUpdate کنی ، خب مشاهده می کنید که فیلد از نوع autoinc خالی میمونه (تا زمانی که بازیابی بشه)

مطمئن هستید؟ این مطلب بین زمان Post و Applyupdate صادقه اما بعد از ApplyUpdate بعید میدونم.
یه سئوال دیگه فرض کنیم داریم کنترل میکنیم که کاربر دیگه ای در حال ویرایش یک رکورد هست مثلا با قرار دادن یک فیلد تگ از جنس Boolean حالا به هر دلیل کاربر در حال تصحیح کامپیوترش ریست بشه و تکلیف اون فیلد تگ چی میشه چطور بفهمیم هنوز کاربر مربوطه در حال تصحیح هست یا نه؟

mzjahromi
پنج شنبه 20 اردیبهشت 1386, 09:27 صبح
در ادامه صحبتهای علی جان:

خوشحال میشم اگر شما بتونید راه حلی برای این موضوع پیدا کنید.
شاید شما با توجه به حسن نیتی که نسبت به این مساله دارید هر کدی که نوشته بشه رو با عنوان ماست مالی مزین کنید ولی یک روش سر دستی برای حل مشکلی که شما در آخرین پستتون مطرح کردید شاید بتونه چیزی شبیه به کد زیر باشه البته با مقداری تغییرات و کار و ریسورس اضافه. که البته بار آن از Refresh ;کل جدول کمتره


procedure TForm1.ClientDataSet1AfterPost(DataSet: TDataSet);
begin
if DataSet.FieldByName('NewID').AsInteger=0 then
Begin
TClientDataSet(DataSet).ApplyUpdates(-1);
With AdoQuery2 Do
Begin
Active:=False;
SQL.Clear;
SQL.Add('Select @@identity From Table1');
Active:=True;
TClientDataSet(DataSet).Edit;
TClientDataSet(DataSet).FieldByName('NewID').AsInt eger:=Fields[0].AsInteger;
TClientDataSet(DataSet).Post;
Active:=False;
End;
End;
end;

mzjahromi
پنج شنبه 20 اردیبهشت 1386, 09:34 صبح
یه سئوال دیگه فرض کنیم داریم کنترل میکنیم که کاربر دیگه ای در حال ویرایش یک رکورد هست مثلا با قرار دادن یک فیلد تگ از جنس Boolean حالا به هر دلیل کاربر در حال تصحیح کامپیوترش ریست بشه و تکلیف اون فیلد تگ چی میشه چطور بفهمیم هنوز کاربر مربوطه در حال تصحیح هست یا نه؟

در صورتیکه شما یک فیلد برای این کار در نظر بگیرید این احتمال وجود داره و شما برای جلو گیری از آن باید یه فکری بکنید مثلا استفاده از TimeStamp . یعنی زمانی که کاربر رکورد رو Lock میکنه مشخص باشه و در صورتیکه از یه حدی بیشتر این رکورد رو خواست نگه داره این فیلد رو دوباره نویسی کنه و ...

ب- تات
پنج شنبه 20 اردیبهشت 1386, 09:41 صبح
متوجه شدم فقط این TimeStamp که شما گفتید یک تکنیک مشخص هست ؟ یا اینکه خودمون باید پیادش کنیم؟

MNosouhi
پنج شنبه 20 اردیبهشت 1386, 10:58 صبح
اول یه توضیح بدم ، قرار بود یه نرم افزار بنوسم که 3 زبان فارسی ، انگلیسی و عربی رو ساپورت کنه ، برنامه تحت شبکه بود و هیچ حدثی در مورد حجم اطلاعاتی که قراره واردش بشه و تعداد کاربرانش نمیشد زد ( چون حالت همه گیر داشت ، یعنی هر شرکت و سازمانی می تونس ازش استفاده کنه ) ، بنابر این من باید بدترین حالت ها رو در نظر می گرفتم ، یعنی صدها هزار رکورد و ده ها ( و شاید صدها ) کاربر . بنابر این نمیشد ریسک کرد.

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

توسعه اش هم متوقف نشده.
مطمئنید؟

افراد زیادی از Midas برای توسعه نرم افزارهاشون استفاده می کنند، به نظر شما همشون ماست مالی می کنند؟!!
نمیخام کلی صحبت کنم ، اما سر این قضیه با ماهرترین و باتجربه ترین برنامه نویس های اصفهان ارتباط برقرار کردم ، جمیعا ماست مالی میکردن.

این از اون حرفهای جالب انگیزناک بود!!! من تا به حال مشکلی در کار با SQL Server از طریق دلفی و Midas نداشتم.
امکاناتی که در برخی از پراپرتی ها می بینید، باید توسط درایور بانک اطلاعاتی و خود موتور بانک اطلاعاتی پشتیبانی بشند.
مگه میشه یه بانک اطلاعاتی مثل sql امکاناتی مثل قفل های خوش بینانه و بدبینانه رو ساپورت نکنه ، من این رو میزارم به حساب ست نبودن یه محصول مایکروسافتی با یک محصول برلندی.

چرا باید در همچین برنامه ایی یک فیلد AutoInc بصورت اتوماتیک برای کلاینت ارسال بشه؟!
توجه داشته باشید که sql برای انجام اکثر کارها به مقدار فیلد کلید وابسته هستش ، یعنی تا اون رو نداشته باشه نمیتونه کار انجام بده.

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

شاید شما با توجه به حسن نیتی که نسبت به این مساله دارید هر کدی که نوشته بشه رو با عنوان ماست مالی مزین کنید ولی یک روش سر دستی برای حل مشکلی که شما در آخرین پستتون مطرح کردید شاید بتونه چیزی شبیه به کد زیر باشه البته با مقداری تغییرات و کار و ریسورس اضافه. که البته بار آن از Refresh ;کل جدول کمتره
البته من الان sql ندارم که بخام تست کنم و دقیقا هم یادم نیست ، اما مطمئنید که رکوردی که مقدار کلید نداره رو میشه ویرایش کرد؟( ببخشید اگه سوالم خیلی ابتدائیه)

ب- تات
پنج شنبه 20 اردیبهشت 1386, 20:49 عصر
اگه میدونستم یه تاپیک به نام کلکل باز میکردم اونوقت سئوال هام رو اونجا مطرح میکردم. حتما جواب میگرفتم.
توی دنیا و علم برنامه نویسی هیچ کسی بر هیچ کسی برتر نیست. شاید همین خود من که دارم مسئله ای رو به عنوان سئوال مطرح میکنم که شاید از دید خیلی از عزیزانی که این تاپیک رو مرور میکنن ابتدائی بیاد حاضرم شرط ببندم تجربیاتی در برنامه نویسی دارم و با مشکلاتی که خودم حل کردم رو برو شدم که شاید به ذهن هم خطور نکنه اما دلیلی بر بازگو کردنش نمیبینم تا زمانی که نیاز باشه . خلاصه کلام ما که نمیتونیم اون یکی رو قانع کنیم (یا به زور یا با هر ابزار دیگه ای) که من نوعی از تو نوعی بهتر میدونم . چون این علم محدود به چیزی که من و شما و ما همه میدونیم نیست . بازی هزار سازه هست هر کسی با مخلوط کردن 4 تا چیز با همدیگه یه نوع آوری میکنه و ازش استفاده میکنه به دیگران هم منتقل میکنه .اصل منتقل کردنه و الا که بالقوه همه چیزهایی که ما میدونیم و فهمیدیم وجود داشته تازه بهش رسیدیم. لذا خواهش من به عنوان یکی از اعضای این انجمن اینه که سعی کنیم خمس علم رو بدون حاشیه ادا کنیم.

MNosouhi
پنج شنبه 20 اردیبهشت 1386, 21:45 عصر
اگه میدونستم یه تاپیک به نام کلکل باز میکردم اونوقت سئوال هام رو اونجا مطرح میکردم.
واقعا براتون متاسفم
مشکلی که در بالا مطرح کردم ، حاصل دو ماه و نیم کار بر روی یک پروژه بود که به دلیل عدم انتخاب ابزار مناسب ( منظورم دلفی و اسکیواله) ، با توجه به سطح پروژه با شکست مواجه شد ( البته فقط همین یه مورد نبود ) . من دارم تجربم رو در اختیارتون قرار میدم تا شما شکست من رو تجربه نکنید و از همین الان هم مزایا رو بدونید و هم معایب و شما اسم اینها رو میزارید کلکل.

vcldeveloper
جمعه 21 اردیبهشت 1386, 08:50 صبح
ولی برای هر کاری و هر پروژه ای هم نمیشه ازش استفاده کرد ، همونطوری که از ویندوز دز هر جایی نمیشه استفاده کرد
مسلما همینطوره. Midas یک ابزار خاص برای کارهای خاص هست. قرار نیست توی هر پروژه ایی ازش استفاده بشه!

نقل قول:
توسعه اش هم متوقف نشده.
مطمئنید؟
می تونید نگاهی به باگ های Midas که در سایت CodeGear اعلام شدند یه نگاهی بندازید، یا به ورژن Midas.dll در نسخه های جدیدتر دلفی توجه کنید.


توجه داشته باشید که sql برای انجام اکثر کارها به مقدار فیلد کلید وابسته هستش ، یعنی تا اون رو نداشته باشه نمیتونه کار انجام بده.
شما ظاهرا هنوز متوجه نشدید که Data Provider موجود در Application Server هست که با بانک اطلاعاتی SQL برقرار می کنه و در این ارتباط داشتن یک کلید منحصر به فرد لازم میشه. در ارتباط بین Data Provider و ClientDataSet شما می تونید از هر چیزی استفاده کنید. ClientDataSet شما فقط Application Server را میشناسه، نه SQL Server.
در یک برنامه سه-لایه، شما اطلاعات را توسط Application Server از بانک می گیرید، اونها را به نحوی که لازم دارید تغییر می دید و بخشی که لازم است به Client نمایش داده شود را برای Client ارسال می کنید. داده های رد و بدل شده بین Client و Data Provider لزوما متناظر با داده های موجود در بانک نیستند.
همونطور که در پست قبلی هم گفتم، بنظر میاد طراحی برنامه تون بیشتر Client/Server باشه تا 3-tier. با توجه به توضیحاتی که شما در برنامه تون میدید، Application Server صرفا یک لایه اضافه بین Sql Server و ClientDataSet است و شما می خواید همه چیز بین ClientDataSet و Sql Server مستقیما حل بشه.

مگه میشه یه بانک اطلاعاتی مثل sql امکاناتی مثل قفل های خوش بینانه و بدبینانه رو ساپورت نکنه ، من این رو میزارم به حساب ست نبودن یه محصول مایکروسافتی با یک محصول برلندی.
SQL Server از قفل هایی که نام بردید پشتیبانی می کنه و دلفی هم به راحتی و بدون هیچ مشکلی اونها رو پشتیبانی می کنه. دلفی برای اتصال از ADO که محصول خود مایکروسافت هست استفاده می کنه. dbGo صرفا یک Wrapper برای ADO است و امکان خاصی به اون اضافه نمیکنه، پس محدودیت های دلفی (در صورتی که از dbGo استفاده شده باشه) همون محدودیت های ADO است.