یه مثال برای SQL Native Client

[r00tkit]

دوستان با توجه به




SQL Native Client and SqlClient primarily differ in that SQL Native Client is written in native code and provides native libraries for C/C++ applications. SqlClient is written in managed code and serves as a managed ADO provider for managed (.NET) applications.

They also surface different APIs:
SQL Native client surfaces OLE DB and ODBC providers for SQL Server
SQLClient surfaces an ADO provider for SQL Server.

یه مثال از روش استفاده از SQL Native Client بزنن یا یه لینکی چیزی بدن گشتم چیز خوب پیدا نکردم

[mehdi.mousavi]

دوستان با توجه به
یه مثال از روش استفاده از SQL Native Client بزنن یا یه لینکی چیزی بدن گشتم چیز خوب پیدا نکردم

سلام.
من در C++‎ میتونم براتون اینو توضیح بدم که چطوری مستقیما با SQL Native Client توسط OLEDB یا ODBC کار کنید، اما در C#‎ فقط کافیه تا Provider مورد نظر رو Native Client تعیین کنید:


Provider=SQLNCLI;
دقیقا چی مد نظرتونه؟
استفاده از همون Win32 API ها تحت C#‎ بطور مستقیم؟

[r00tkit]

سلام
اقای موسوی

کلا" می شه در مورد MDAC , OLEDB و ODBC و SQL Native Client , SqlClient
کمی بنویسید خیلی روشون مطالعه کردم و می خوام از یه منبع فارسی فرق اینها رو بدونم و کی و کجا باید استفاده کرد
اگه از oledb , SQL Native Client , odbc یه مثال تو c/c++ و c# بزنید(لینک) خیلی ممنون می شم

یه سری سوال دیگه هستش که تو ادامه می پرسم

[mehdi.mousavi]

سلام اقای موسوی
کلا" می شه در مورد MDAC , OLEDB و ODBC و SQL Native Client , SqlClient
کمی بنویسید خیلی روشون مطالعه کردم و می خوام از یه منبع فارسی فرق اینها رو بدونم و کی و کجا باید استفاده کرد
اگه از oledb , SQL Native Client , odbc یه مثال تو c/C++‎ و C#‎ بزنید(لینک) خیلی ممنون می شم

یه سری سوال دیگه هستش که تو ادامه می پرسم

سلام.
OLEDB یا Object Linking and Embedding DB ساز و کار COM-based هستش که دسترسی یکسان به داده های ذخیره شده در بانکهای اطلاعاتی مختلف رو فراهم میکنه. OLEDB از موتورهای مختلفی برای ارائه سرویسهای خودش استفاده میکنه، که یکی از اونها، موتوری تحت عنوان Client Cursor Engine هستش که امکان عقب و جلو رفتن بین رکوردها رو در بانکهایی که چنین سرویسی رو بصورت Native پشتیبانی نمیکنن، قراهم میکنه.

یکی دیگه از سرویسهایی که OLEDB در اختیار برنامه نویس قرار میده، امکان enlist کردن خودکار Resource ها در یک Transaction هستش. (هر کدوم از این مطالب ساعتها وقت میبره اگه بخوام بازشون کنم). بدین وسیله، امکان Resource Pooling فراهم میشه.

برای استفاده از OLEDB باید اونو مثل COM-Server های دیگه ابتدا با CLSID خاصی و بکمک دستور CoCreateInstance ایجاد کنیم. سپس با استفاده از دو اینترفیس IDataInitialize یا IDBPromptInitialize اقدام به Initialize کردن Component کرده و کار با اون Instance رو شروع کنیم.

برای اینکه OLEDB بتونه روی Data Source ها مختلف کار کنه، یه سری OLEDB Provider وجود داره که بر اساس Interface های از پیش تعیین شده (و با پیاده سازی مورد نظر) میشه داده ها رو از هر 3rd party DBMS گرفت و در اختیار Client قرار داد. تقریبا چیزی شبیه همون ODBC Provider ها...

http://i.msdn.microsoft.com/dynimg/IC44287.gif


بطور کلی، این شکل معماری OLEDB رو نشون میده. همونطور که می بینید، در بالای ماجرا برنامه ما قرار داره (در بخش Consumer). برنامه ما به دو روش میتونه با OLEDB در ارتباط باشه. یا بطور مستقیم که در فوق به اون اشاره کردم، یا بطور غیر مستقیم از طریق یه COM Server دیگه به اسم ActiveX Data Objects یا همون ADO

ADO خودش به نوبه خود، با اتصال به OLEDB COM Server سرویسهای مورد نظرش رو میگیره. همونطور که اشاره کردم، OLEDB سرویسهاشو از طریق Engine هایی در اختیار لایه بالایی قرار میده. توی عکس سه سرویس Cursor Engine، Distribution Query Engine و Relational Query Engine در اختیار لایه فوقانی قرار میگیره. در انتهای کار هم، Data Provider ها قرار دارن که با پیاده سازی Interface های مورد نظر OLEDB، سرویسهای یکسان رو میتونن روی Data Source های متفاوت ارائه کنن.

کدهای OLEDB واقعا کدهای کثیف و ناخوانایی بود و سر در آوردن از اونها، برای افراد عادی بسیار دشوار (و حتی غیر ممکن). به یک نمونه کد در اینجا (http://www.vijaymukhi.com/vmis/oledb.htm) توجه کنید. کسی که از COM اطلاعات زیادی نداره، با دیدن این کد چشمهاش سیاهی میره. :)

به همین دلیل ADO بوجود اومد تا سرویسهای یکپارچه تری رو ارائه کنه، و خوانایی (و صد البته نوشتن) کدهای Data-Centric رو بالا ببره...

این فعلا برای OLEDB... در فرصتهای بعدی در مورد اونیکی ها هم براتون توضیح میدم.

موفق باشید.

[r00tkit]

خیلی ممنون
مثل همیشه خوب

ولی اگه ادامه داشته باشه برای ado.net , ODBC ,SQL native client خیلی خوب می شه



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


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

[mehdi.mousavi]

سلام.
ODBC یا Open Database Connectivity مجموعه Interface هایی رو تعریف میکنه که امکان برقراری ارتباط با DBMS ها و کارکردن با اونها رو فارغ از نوع DBMS، نوع سیستم عامل و زبان برنامه نویسی در اختیار Developer ها قرار میده.

به بیان دیگه، ساختار ODBC روی Unix، OS/400 و خلاصه سیستم عاملهای دیگه (غیر ویندوز) نیز پیاده سازی شده. برای اینکه ارتباط با یک بانک خاص رو بشه برقرار کرد، باید Component نرم افزاری ای تحت عنوان ODBC Driver بنویسیم. اما اجازه بدید تا به معماری ODBC نیز نگاه گذرایی داشته باشیم:

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzaii/rv3w364.gif

توی این معماری و همونطور که از روی شکل پیداست، برنامه ما بالای کار قرار داره و لایه زیریش Driver Manager هستش که در واقع روند کاری تعامل با ODBC Driver ها رو تحت کنترل خودش میگیره. ODBC Driver مربوطه نیر به نوبه خودش با بانک مورد نظر ارتباط برقرار میکنه و دستور مورد نظر ما رو روی بانک اعمال میکنه. اما این بانک چطوری آدرس میشه؟

بانک مورد نظر با استفاده از DSN یا Data Source Name آدرس دهی میشه. DSN ها به سه دسته تقسیم میشن:


User DSN - که فقط در دسترس کاربر owner هستش و اطلاعات مربوط برای برقراری با بانک مورد نظر رو در Registery ثبت می کنه.
System DSN - در Scope یه ماشین در دسترسه و مثل User DSN ها اطلاعات مربوطه رو در Registry نگهداری میکنه.
File DSN - که اطلاعات مربوطه رو (همونطوریکه از اسمش پیداست) در یک فایل ذخیره میکنه و بالطبع هر کسی به این فایل و ODBC Driver مورد نظر دسترسی داشته باشه، به اون Data Source دسترسی داره.

نحوه نوشتن یک ODB Driver قبلا در مجله Dr. Dobb (http://www.drdobbs.com/184416434) (و البته کتابی که در این زمینه خونده بودم و الان عنوانش یادم نمیاد) توضیح داده شده. اطلاعات بیشتر در مورد Win32 API های مورد نیاز برای کارکردن با یه ODBC Driver (http://msdn.microsoft.com/en-us/library/ms714562%28v=VS.85%29.aspx) رو میتونید اینجا بخونید.

موفق باشید.

[mehdi.mousavi]

اما ADO.NET چیه؟
من به مساله ای در مورد ODBC و OLEDB اشاره نکردم و اون هم بنا شدن اون دو معماری بر پایه مدل two-tier و البته connection-based بود. در واقع پردازش داده ها قبل از ظهور ADO.NET شکل و شمایل دیگه ای داشت اما با گسترش نیازها، و رشد روز افزون سیستم های چند لایه، برنامه نویسها نیاز داشتن تا به مدل جدیدی از کار با داده روی بیارن و این مدل جدید چیزی نبود جز دسترسی disconnected به داده ها.

بدین ترتیب ASP.NET با ظهور خودش و با استفاده از توان XML تونست دسترسی disconnected به داده ها رو با معرفی DataSet ها فراهم کنه. DataSet ها باید از منطق دستکاری داده ها جدا می بودن، به بیان دیگه اونها ظروفی برای رد و بدل کردن داده بودن و این مهم نبود که داده ها از کدوم Data Source دریافت شده یا به کجا منتقل میشن. بنابراین ADO.NET این دو مفهموم رو کاملا از هم تمیز داد و با معرفی Data Provider هایی در محیط .NET، وظیفه دستکاری داده ها رو به عهده این Provider ها گذاشت. اینجا منظورمون از Data Provider اندکی متفاوته. لطفا این شکل رو نگاه کنید:


http://i.msdn.microsoft.com/27y4ybxw.ado_2%28en-us,VS.71%29.gif


همونطوریکه در شکل مشخصه، .NET Frameowrk Data Provider ها حاوی هسته هایی هستن که سرویسهای مورد نظر رو به DataSet ها ارائه میدن. این کلاسها (یا سرویسها) عبارتند از Connection, Command, DataReader، DataAdapter و ...

با این معماری، دیگه دسترسی disconnected به داده ها فارغ از Data Source مورد استفاده میسر میشد و در نتیجه، نقل و انتقال داده ها توی این ظرفهای استاندار W3C-Compliant عملی شده بود (اگرچه بر خلاف ادعای مایکروسافت، هنوز این Interopberability به جایگاه قابل قبولی نرسیده و هنوز مشکلات عدیده ای در پیاده سازی استاندارد ها در Data Set ها وجود داره، اما خوب، اوضاع نسبت به روزهای .NET 1.1 خیلی خیلی بهتر و قابل قبول تر شده).

این شکل، Data Access Stack رو نشون میده و دیدنش خالی از لطف نیست. شکل واضحه و نیازی به توضیح نداره:


http://www.msdnbrasil.com.br/Tecnologias/arquitetura/ReferenceBuildingBlocks/Development/DataAccess/daag_arquivos/daag02.gif


اما چطوری میتونیم یک Custom ADO.NET Data Provider درست کنیم؟ بازهم طبق معمول، کافیه تا Interface های مشخصی رو پیاده سازی کنیم. Bob Beauchemin در مقاله 9 سال پیش خودش (http://msdn.microsoft.com/en-us/magazine/cc301611.aspx) در مجله MSDN به این موضوع اشاره کرده که خوندنش خالی از لطف نیست.

موفق باشید.

[r00tkit]

بخونید تا گفته های اقای موسوی رو بهتر درک کنید

.NET Data Access Architecture Guide (http://msdn.microsoft.com/en-us/library/ee817654.aspx)


اینم data access stack
برای ربط ADO.NET با بقیه

http://i.msdn.microsoft.com/dynimg/IC95151.gif