پرش به محتوا

اتصال‌دهنده باز پایگاه‌داده

از ویکی‌پدیا، دانشنامهٔ آزاد

اتصال باز پایگاه داده (به انگلیسی: Open Database Connectivity یا ODBC) در رایانش، یک رابط برنامه‌نویسی کاربردی (API) استاندارد به زبان C برای دسترسی به سامانه مدیریت پایگاه داده‌ها (DBMS) است. طراحان ODBC قصد داشتند آن را از سیستم‌های پایگاه داده و سیستم‌عامل‌ها مستقل کنند.[نیازمند منبع] یک برنامه نوشته‌شده با استفاده از ODBC می‌تواند با تغییرات اندکی در کد دسترسی به داده‌ها، به سایر پلتفرم‌ها، هم در سمت کلاینت و هم در سمت سرور، پورت شود.

ODBC با استفاده از یک درایور ODBC به عنوان یک لایهٔ ترجمه بین برنامه و DBMS به استقلال از DBMS دست می‌یابد. برنامه از توابع ODBC از طریق یک مدیر درایور ODBC که با آن پیوند خورده است استفاده می‌کند و درایور، پرس‌وجو را به DBMS منتقل می‌کند. یک درایور ODBC را می‌توان مشابه یک درایور چاپگر یا درایورهای دیگر دانست که مجموعه استانداری از توابع را برای استفاده برنامه فراهم می‌کند و قابلیت‌های خاص DBMS را پیاده‌سازی می‌نماید. برنامه‌ای که می‌تواند از ODBC استفاده کند، «سازگار با ODBC» نامیده می‌شود. هر برنامه سازگار با ODBC می‌تواند به هر DBMS که درایور آن نصب شده باشد دسترسی داشته باشد. درایورها برای تمامی DBMSهای بزرگ، بسیاری از منابع داده دیگر مانند سیستم‌های دفترچه آدرس و مایکروسافت اکسل، و حتی برای فایل‌های متنی یا مقادیر جداشده با کاما (CSV) وجود دارند.

ODBC در اوایل دههٔ ۱۹۹۰ توسط مایکروسافت و سیمبا تکنولوژی توسعه یافت و به پایه و اساس رابط سطح تماس (CLI) استانداردشده توسط گروه دسترسی اس‌کیوال در حوزهٔ یونیکس و رایانه‌های بزرگ تبدیل شد. ODBC چندین ویژگی را که به عنوان بخشی از تلاش‌های مربوط به CLI حذف شده بودند، حفظ کرد. نسخهٔ کامل ODBC بعدها به آن پلتفرم‌ها بازگردانده شد و به یک استاندارد دفاکتو تبدیل شد که به‌طور قابل‌توجهی شناخته‌شده‌تر از CLI است. CLI همچنان شبیه به ODBC باقی مانده است و برنامه‌ها را می‌توان با تغییرات اندکی از یک پلتفرم به پلتفرم دیگر پورت کرد.

تاریخچه

[ویرایش | اشتراک‌گذاری]

پیش از ODBC

[ویرایش | اشتراک‌گذاری]

معرفی پایگاه داده رابطه‌ای مبتنی بر رایانه‌های بزرگ در طول دههٔ ۱۹۷۰ منجر به گسترش روش‌های دسترسی به داده شد. به‌طور کلی این سیستم‌ها همراه با یک پردازشگر فرمان ساده کار می‌کردند که به کاربران اجازه می‌داد دستورهای شبیه به زبان انگلیسی را تایپ کرده و خروجی دریافت کنند. شناخته‌شده‌ترین نمونه‌ها عبارتند از اس‌کیوال از آی‌بی‌ام و QUEL از پروژهٔ اینگرس. این سیستم‌ها ممکن بود به برنامه‌های دیگر اجازهٔ دسترسی مستقیم به داده‌ها را بدهند یا ندهند، و آن‌هایی که این کار را می‌کردند از روش‌های گوناگونی استفاده می‌نمودند. معرفی اس‌کیوال با هدف حل مشکل استانداردسازی زبان انجام شد، اگرچه تفاوت‌های اساسی در پیاده‌سازی باقی ماند.

از آنجا که زبان اس‌کیوال تنها دارای ویژگی‌های برنامه‌نویسی ابتدایی بود، کاربران اغلب می‌خواستند از اس‌کیوال در برنامه‌ای نوشته‌شده به زبان دیگری، مانند فرترن یا C استفاده کنند. این امر به شکل‌گیری مفهوم اس‌کیوال جاسازی‌شده منجر شد که به کدهای اس‌کیوال اجازه می‌داد در داخل زبان دیگری «جاسازی» شوند. برای نمونه، یک دستور اس‌کیوال مانند SELECT * FROM city می‌تواند به عنوان متن در کد منبع C درج شود و در هنگام کامپایل به یک فرمت سفارشی تبدیل شود که مستقیماً تابعی را در یک کتابخانه فراخوانی می‌کند که دستور را به سیستم اس‌کیوال منتقل می‌کند. نتایج بازگردانده‌شده از دستورها با استفاده از کدهای کتابخانه‌ای مشابه، دوباره به فرمت‌های دادهٔ C مانند char* یا char[] تفسیر می‌شدند.

رویکرد اس‌کیوال جاسازی‌شده با مشکلات متعددی مواجه بود. مانند انواع مختلف اس‌کیوال، اس‌کیوال‌های جاسازی‌شده‌ای که از آن‌ها استفاده می‌کردند نیز به‌شدت متفاوت بودند، نه تنها از پلتفرمی به پلتفرم دیگر، بلکه حتی در زبان‌های مختلف روی یک پلتفرم — سیستمی که اجازهٔ فراخوانی IBM Db2 را می‌داد، بسیار متفاوت از سیستمی به نظر می‌رسید که SQL/DS خود را فراخوانی می‌کرد. یکی دیگر از مشکلات کلیدی مفهوم اس‌کیوال جاسازی‌شده این بود که کد اس‌کیوال فقط در کد منبع برنامه قابل تغییر بود، به‌طوری‌که حتی تغییرات کوچک در پرس‌وجو مستلزم تلاش قابل‌توجه برنامه‌نویس برای تغییر بود. بازار اس‌کیوال از این مورد با عنوان اس‌کیوال ایستا یاد می‌کرد، در مقابل اس‌کیوال پویا که می‌توانست در هر زمانی تغییر کند، مانند رابط‌های خط فرمان که با تقریباً تمام سیستم‌های اس‌کیوال عرضه می‌شدند، یا یک رابط برنامه‌نویسی که اس‌کیوال را به صورت متن ساده تا زمان فراخوانی رها می‌کرد. سیستم‌های اس‌کیوال پویا در طول دههٔ ۱۹۸۰ به یکی از تمرکزهای اصلی عرضه‌کنندگان اس‌کیوال تبدیل شدند.

پایگاه‌های دادهٔ قدیمی رایانه‌های بزرگ و سیستم‌های جدیدتر مبتنی بر ریزرایانه که بر پایهٔ آن‌ها ساخته شده بودند، به‌طور کلی فاقد یک پردازشگر فرمان شبیه به اس‌کیوال بین کاربر و موتور پایگاه داده بودند. در عوض، دسترسی به داده‌ها به‌طور مستقیم توسط برنامه انجام می‌شد — یک کتابخانهٔ برنامه‌نویسی در مورد سیستم‌های بزرگ رایانه‌های بزرگ، یا یک رابط خط فرمان یا سیستم فرم‌های تعاملی در مورد dBASE و برنامه‌های مشابه. داده‌های dBASE به‌طور کلی توسط سایر برنامه‌های در حال اجرا روی دستگاه قابل دسترسی مستقیم نبودند. ممکن بود به آن برنامه راهی برای دسترسی به این داده‌ها، غالباً از طریق کتابخانه‌ها، داده شود، اما این کار با هیچ موتور پایگاه داده دیگری یا حتی پایگاه‌های دادهٔ مختلف در همان موتور کار نمی‌کرد. در عمل، همهٔ این سیستم‌ها ایستا بودند که مشکلات قابل‌توجهی را ایجاد می‌کرد.

تلاش‌های اولیه

[ویرایش | اشتراک‌گذاری]

تا اواسط دههٔ ۱۹۸۰، پیشرفت سریع ریزرایانه‌ها و به‌ویژه معرفی رابط کاربری گرافیکی و برنامه‌های کاربردی داده‌محور مانند Lotus 1-2-3 منجر به افزایش علاقه به استفاده از رایانه‌های شخصی به عنوان پلتفرم سمت کلاینت انتخابی در رایانش کلاینت-سرور شد. تحت این مدل، رایانه‌های بزرگ (ماین‌فریم‌ها) و مینی‌کامپیوترها عمدتاً برای ارائهٔ داده‌ها از طریق شبکه محلی به ریزرایانه‌ها استفاده می‌شدند تا آن داده‌ها را تفسیر، نمایش و دستکاری کنند. برای کارکرد این مدل، وجود یک استاندارد دسترسی به داده‌ها یک ضرورت بود — در حوزهٔ رایانه‌های بزرگ بسیار محتمل بود که تمام رایانه‌های یک مرکز از یک فروشنده باشند و کلاینت‌ها پایانه‌های رایانه‌ای باشند که مستقیماً با آن‌ها ارتباط برقرار می‌کنند، اما در حوزهٔ ریزرایانه‌ها چنین استانداردسازی وجود نداشت و هر کلاینتی ممکن بود با استفاده از هر سیستم شبکه‌ای به هر سروری دسترسی داشته باشد.

تا اواخر دههٔ ۱۹۸۰، چندین تلاش برای فراهم کردن یک لایهٔ انتزاعی برای این منظور در جریان بود. برخی از آن‌ها مربوط به رایانه‌های بزرگ بودند و به گونه‌ای طراحی شده بودند که به برنامه‌های در حال اجرا روی آن دستگاه‌ها اجازه دهند بین انواع مختلف SQL ترجمه انجام دهند و یک رابط مشترک واحد فراهم کنند که سپس توسط سایر برنامه‌های رایانه‌های بزرگ یا ریزرایانه‌ها فراخوانی شود. این راه‌حل‌ها شامل معماری پایگاه دادهٔ رابطه‌ای توزیع‌شدهٔ آی‌بی‌ام (DRDA) و Data Access Language شرکت Apple Computer بود. با این حال، بسیار رایج‌تر، سیستم‌هایی بودند که به‌طور کامل روی ریزرایانه‌ها اجرا می‌شدند، از جمله یک پشتهٔ پروتکل کامل که شامل هرگونه پشتیبانی لازم برای شبکه یا ترجمهٔ فایل بود.

یکی از نمونه‌های اولیهٔ چنین سیستمی DataLens متعلق به Lotus Development بود که در ابتدا با نام Blueprint شناخته می‌شد. Blueprint که برای لوتس ۱-۲-۳ توسعه یافته بود، از انواع منابع داده، از جمله SQL/DS, DB2، FOCUS و انواع سیستم‌های مشابه رایانه‌های بزرگ، و همچنین سیستم‌های ریزرایانه‌ای مانند dBase و تلاش‌های اولیهٔ مایکروسافت/اشتون-تیت که در نهایت به Microsoft SQL Server تبدیل شدند، پشتیبانی می‌کرد.[۱] برخلاف ODBC بعدی، Blueprint یک سیستم کاملاً مبتنی بر کد بود و فاقد هرگونه زبانی شبیه به دستورهای SQL بود. در عوض، برنامه‌نویسان از ساختارهای داده برای ذخیرهٔ اطلاعات پرس‌وجو استفاده می‌کردند و با پیوند دادن بسیاری از این ساختارها به یکدیگر، یک پرس‌وجو را می‌ساختند. لوتس به این ساختارهای مرکب «درخت‌های پرس‌وجو» (query trees) می‌گفت.[۲]

در همین زمان، یک تیم صنعتی شامل اعضایی از Sybase (تام هاگین)، Tandem Computers (جیم گری و رائو یندلوری) و مایکروسافت (کایل گایگر) روی مفهوم استانداردشدهٔ اس‌کیوال پویا کار می‌کردند. بخش عمده‌ای از این سیستم بر اساس سیستم DB-Library سای‌بیس بود، به‌طوری‌که بخش‌های مختص سای‌بیس حذف شده و چندین الحاقیه برای پشتیبانی از سایر پلتفرم‌ها اضافه شده بود.[۳] سیستم DB-Library توسط یک حرکت سراسری در صنعت تقویت شد؛ حرکتی که از سیستم‌های کتابخانه‌ایِ محکم پیوندخورده به یک زبان خاص، به سمت سیستم‌های کتابخانه‌ایِ ارائه‌شده توسط سیستم‌عامل که زبان‌های روی آن پلتفرم را ملزم به انطباق با استانداردهای خود می‌کردند، تغییر جهت داد. این بدان معنا بود که یک کتابخانهٔ واحد می‌توانست (به‌طور بالقوه) با هر زبان برنامه‌نویسی روی یک پلتفرم معین استفاده شود.

نخستین پیش‌نویس از «API دسترسی به داده‌های مایکروسافت» (Microsoft Data Access API) در آوریل ۱۹۸۹، تقریباً هم‌زمان با اعلام Blueprint توسط لوتس منتشر شد.[۴] با وجود پیشتازی بزرگ Blueprint — که زمانی که MSDA هنوز یک پروژه روی کاغذ بود، در حال اجرا بود — لوتس در نهایت به تلاش‌های MSDA پیوست، چرا که آشکار شد SQL به استاندارد دفاکتوی پایگاه داده تبدیل خواهد شد.[۲] پس از مشارکت قابل‌توجه صنعت، در تابستان ۱۹۸۹ این استاندارد به «اتصال اس‌کیوال» (SQL Connectivity یا SQLC) تبدیل شد.[۵]

SAG و CLI

[ویرایش | اشتراک‌گذاری]

در سال ۱۹۸۸، چندین شرکت ارائه‌دهنده، عمدتاً از جوامع یونیکس و پایگاه داده، گروه دسترسی اس‌کیوال (SAG) را در تلاشی برای تولید یک استاندارد پایهٔ واحد برای زبان SQL تشکیل دادند. در نخستین جلسه، بحث قابل‌توجهی در این باره وجود داشت که آیا این تلاش باید صرفاً روی خود زبان SQL متمرکز باشد، یا استانداردهای گسترده‌تری را هدف قرار دهد که شامل یک سیستم جاسازی زبان اس‌کیوال پویا نیز بشود؛ چیزی که آن‌ها آن را رابط سطح تماس (CLI) می‌نامیدند.[۶] کایل گایگر از مایکروسافت در حالی که با پیش‌نویس اولیه‌ای از آنچه در آن زمان هنوز با نام دسترسی به داده‌های مایکروسافت (MS Data Access) شناخته می‌شد در جلسه شرکت کرده بود، از جف بالبونی و لاری بارنز از دیجیتال اکویپمنت کورپوریشن (DEC) دعوت کرد تا به جلسات SQLC نیز بپیوندند. SQLC یک راه‌حل بالقوه برای درخواست ایجاد CLI بود که توسط DEC هدایت می‌شد.

«گروه چهار نفرهٔ» جدید SQLC یعنی مایکروسافت، تندم، DEC و سای‌بیس، نسخهٔ به‌روزرسانی‌شده‌ای از SQLC را در ژوئن ۱۹۹۰ به جلسهٔ بعدی SAG آوردند.[۷] سازمان SAG با گشودن تلاش‌های استانداردسازی به روی هر طرح رقابتی به این موضوع پاسخ داد، اما از میان پیشنهادات فراوان، تنها Oracle Corp سیستمی داشت که رقابت جدی ایجاد می‌کرد. در نهایت، SQLC آرا را به دست آورد و به پیش‌نویس استاندارد تبدیل شد، اما این امر تنها پس از حذف بخش‌های بزرگی از API محقق شد — سند استاندارد در طول این مدت از ۱۲۰ صفحه به ۵۰ صفحه تقلیل یافت. همچنین در همین دوره بود که نام «رابط سطح تماس» (Call Level Interface) به‌طور رسمی پذیرفته شد.[۷] در سال ۱۹۹۵، SQL/CLI به بخشی از استاندارد بین‌المللی SQL یعنی ISO/IEC 9075-3 تبدیل شد.[۸] خود سازمان SAG در سال ۱۹۹۶ توسط گروه X/Open تصاحب شد و به مرور زمان به بخشی از محیط کاربردی مشترک The Open Group تبدیل گردید.

مایکروسافت به کار با استاندارد اصلی SQLC ادامه داد و بسیاری از ویژگی‌های پیشرفته‌ای را که از نسخهٔ CLI حذف شده بودند، حفظ کرد. این موارد شامل ویژگی‌هایی مانند مکان‌نماهای قابل‌پیمایش (scrollable cursors) و پرس‌وجوهای اطلاعات میتادیتا می‌شد. دستورهای موجود در API به چند گروه تقسیم شدند؛ گروه هسته (Core) کاملاً مشابه CLI بود، پسوندهای سطح ۱ دستورهایی بودند که پیاده‌سازی آن‌ها در درایورها آسان بود، در حالی که دستورهای سطح ۲ شامل ویژگی‌های پیشرفته‌تری مانند مکان‌نماها بودند. یک پیشنهاد استاندارد در دسامبر ۱۹۹۱ منتشر شد و نظرات صنعت در طول سال ۱۹۹۲ جمع‌آوری و روی سیستم اعمال شد که به تغییر نام دیگری به ODBC منجر گردید.[۹]

JET و ODBC

[ویرایش | اشتراک‌گذاری]

در این مدت، مایکروسافت در حال توسعهٔ سیستم پایگاه دادهٔ Jet خود بود. Jet سه زیرسیستم اصلی را با هم ترکیب کرده بود: یک موتور پایگاه دادهٔ مبتنی بر ISAM (که به‌طور گیج‌کننده‌ای آن هم Jet نامیده می‌شد)، یک رابط مبتنی بر C که به برنامه‌ها اجازه می‌داد به آن داده‌ها دسترسی داشته باشند، و مجموعه‌ای از کتابخانه‌های پیوند پویای (DLL) درایور که به همان رابط C اجازه می‌دادند ورودی و خروجی را به سایر پایگاه‌های دادهٔ مبتنی بر ISAM مانند Paradox و xBase هدایت کنند. Jet امکان استفاده از یک مجموعه فراخوانی را برای دسترسی به پایگاه‌های دادهٔ رایج ریزرایانه‌ای به روشی مشابه Blueprint (که تا آن زمان به DataLens تغییر نام داده بود) فراهم می‌کرد. با این حال، Jet از SQL استفاده نمی‌کرد؛ درست مانند DataLens، این رابط به زبان C بود و از ساختارهای داده و فراخوانی توابع تشکیل شده بود.

تلاش‌های استانداردسازی SAG فرصتی را برای مایکروسافت فراهم کرد تا سیستم Jet خود را با استاندارد جدید CLI سازگار کند. این کار نه تنها ویندوز را به پلتفرمی برتر برای توسعهٔ CLI تبدیل می‌کرد، بلکه به کاربران اجازه می‌داد از SQL برای دسترسی همزمان به Jet و سایر پایگاه‌های داده استفاده کنند. آنچه کم بود، تجزیه‌کنندهٔ (parser) SQL بود که می‌توانست آن فراخوانی‌ها را از فرم متنی آن‌ها به رابط C مورد استفاده در Jet تبدیل کند. برای حل این مشکل، مایکروسافت با شرکت PageAhead Software شریک شد تا از پردازشگر پرس‌وجوی موجود آن‌ها یعنی SIMBA استفاده کند. SIMBA به عنوان یک تجزیه‌کننده در بالای کتابخانهٔ C ی Jet استفاده شد و Jet را به یک پایگاه دادهٔ SQL تبدیل کرد. و از آنجا که Jet می‌توانست آن فراخوانی‌های مبتنی بر C را به پایگاه‌های دادهٔ دیگر هدایت کند، این امر به SIMBA نیز اجازه داد تا سایر سیستم‌ها را پرس‌وجو کند. مایکروسافت درایورهایی را برای اکسل قرار داد تا اسناد صفحهٔ گستردهٔ آن را به جداول پایگاه دادهٔ قابل دسترسی با SQL تبدیل کند.[۱۰]

انتشار و توسعهٔ مداوم

[ویرایش | اشتراک‌گذاری]

نسخهٔ ۱٫۰ در سپتامبر ۱۹۹۲ منتشر شد.[۱۱] در آن زمان، پشتیبانی مستقیم کمی از پایگاه‌های دادهٔ SQL (در مقایسه با ISAM) وجود داشت و درایورهای اولیه به خاطر کارایی پایین شناخته می‌شدند. بخشی از این موضوع به دلیل مسیری که فراخوانی‌ها از طریق پشتهٔ مبتنی بر جت (Jet) طی می‌کردند اجتناب‌ناپذیر بود؛ فراخوانی‌های ODBC به پایگاه‌های دادهٔ SQL ابتدا از گویش SQL شرکت Simba Technologies به فرمت داخلی مبتنی بر C در جت تبدیل می‌شدند و سپس برای تبدیل مجدد به فراخوانی‌های SQL برای پایگاه داده، به یک درایور فرستاده می‌شدند. هر دو شرکت Digital Equipment و اوراکل با Simba Technologies قرارداد بستند تا درایورهایی برای پایگاه‌های دادهٔ خود نیز توسعه دهند.[۱۲]

در حدود سال ۱۹۹۳، شرکت اوپن‌لینک سافت‌ور (OpenLink Software) یکی از نخستین درایورهای شخص ثالث ODBC توسعه‌یافتهٔ مستقل را برای PROGRESS DBMS عرضه کرد[۱۳] و به فاصلهٔ کوتاهی کیت توسعهٔ نرم‌افزار (SDK) مربوط به UDBC (یک API معادل چندپلتفرمی برای ODBC و SAG/CLI) را به همراه درایورهای مرتبط برای PROGRESS، سای‌بیس، اوراکل و سایر DBMSها برای استفاده در سیستم‌عامل‌های یونیکس‌مانند (AIX, HP-UX, Solaris, Linux و غیره)، VMS، Windows NT، OS/2 و سایر سیستم‌عامل‌ها ارائه داد.[۱۴]

در همین میان، تلاش‌ها برای استانداردسازی CLI به درازا کشید و تا مارس ۱۹۹۵ طول کشید تا نسخهٔ قطعی آن نهایی شود. تا آن زمان، مایکروسافت پیش‌تر مجوزی برای کد منبع به شرکت Visigenic Software اعطا کرده بود تا ODBC را روی پلتفرم‌های غیرویندوزی توسعه دهد. ویزیژنیک، ODBC را به classic Mac OS و طیف وسیعی از پلتفرم‌های یونیکس پورت کرد؛ جایی که ODBC به سرعت به استاندارد دفاکتو تبدیل شد.[۱۵] امروزه CLI «واقعی» کمیاب است. این دو سیستم همچنان شبیه به هم باقی مانده‌اند و بسیاری از برنامه‌ها را می‌توان با تغییرات اندک یا بدون هیچ تغییری از ODBC به CLI پورت کرد.[۱۶]

با گذشت زمان، عرضه‌کنندگان پایگاه‌های داده کنترل رابط‌های درایور را به دست گرفتند و پیوندهای مستقیمی به محصولات خود ارائه دادند. چشم‌پوشی از تبدیل‌های میانی به و از Jet یا پوشش‌های (wrappers) مشابه غالباً به کارایی بالاتری منجر می‌شد. با این حال، تا آن زمان مایکروسافت تمرکز خود را به مفهوم OLE DB[۱۷] خود معطوف کرده بود (که اخیراً مجدداً احیا شده است[۱۸])؛ مفهومی که دسترسی مستقیم به طیف وسیع‌تری از منابع داده، از دفترچه‌های آدرس گرفته تا فایل‌های متنی را فراهم می‌کرد. چندین سیستم جدید نیز به دنبال آن آمدند که توجهات را بیش از پیش از ODBC دور کرد؛ از جمله ActiveX Data Objects (ADO) و ADO.net که در طول چرخهٔ عمر خود کم‌وبیش با ODBC تعامل داشتند.

در حالی که مایکروسافت توجه خود را از کار مستقیم روی ODBC دور کرد، حوزهٔ یونیکس به‌طور فزاینده‌ای از آن استقبال کرد. این روند توسط دو تغییر در بازار پیش رانده شد: معرفی رابط‌های کاربری گرافیکی (GUI) مانند GNOME که نیاز به دسترسی به این منابع را به شکلی غیرمتنی فراهم می‌کردند، و ظهور سیستم‌های پایگاه دادهٔ متن‌باز (نرم‌افزار آزاد) مانند PostgreSQL و MySQL، که ابتدا در بستر یونیکس شکل گرفتند. پذیرش بعدی ODBC توسط اپل برای استفاده از بستهٔ استاندارد سمت یونیکس iODBC در Mac OS X 10.2 (جَگوار)[۱۹] (که شرکت اوپن‌لینک سافت‌ور از سال ۲۰۰۱ به‌طور مستقل برای Mac OS X 10.0 و حتی Mac OS 9 فراهم کرده بود[۲۰])، جایگاه ODBC را به عنوان استاندارد دسترسی به داده‌های چندپلتفرمی بیش از پیش تثبیت کرد.

در حدود سال ۱۹۹۳، شرکت اوپن‌لینک سافت‌ور یکی از نخستین درایورهای شخص ثالث ODBC توسعه‌یافتهٔ مستقل را برای PROGRESS DBMS عرضه کرد،[۲۱] و دیری نگذشت که کیت توسعهٔ نرم‌افزار (SDK) مربوط به UDBC (یک API چندپلتفرمی معادل ODBC و SAG/CLI) و درایورهای مرتبط با آن را برای PROGRESS، سای‌بیس، اوراکل و سایر سیستم‌عامل‌ها، جهت استفاده در سیستم‌عامل‌های یونیکس‌مانند (AIX، HP-UX، Solaris، Linux و غیره)، VMS، Windows NT، OS/2 و سایر سیستم‌عامل‌ها منتشر نمود.[۲۲]

در همین میان، تلاش‌ها برای استانداردسازی CLI به درازا کشید و تا مارس ۱۹۹۵ طول کشید تا نسخهٔ قطعی آن نهایی شود. تا آن زمان، مایکروسافت پیش‌تر مجوزی برای کد منبع به شرکت Visigenic Software اعطا کرده بود تا ODBC را روی پلتفرم‌های غیرویندوزی توسعه دهد. ویزیژنیک، ODBC را به classic Mac OS و طیف وسیعی از پلتفرم‌های یونیکس پورت کرد؛ جایی که ODBC به سرعت به استاندارد دفاکتو تبدیل شد.[۲۳] امروزه CLI «واقعی» کمیاب است. این دو سیستم همچنان شبیه به هم باقی مانده‌اند و بسیاری از برنامه‌ها را می‌توان با تغییرات اندک یا بدون هیچ تغییری از ODBC به CLI پورت کرد.[۲۴]

با گذشت زمان، عرضه‌کنندگان پایگاه‌های داده کنترل رابط‌های درایور را به دست گرفتند و پیوندهای مستقیمی به محصولات خود ارائه دادند. چشم‌پوشی از تبدیل‌های میانی به و از Jet یا پوشش‌های مشابه غالباً به کارایی بالاتری منجر می‌شد. با این حال، تا آن زمان مایکروسافت تمرکز خود را به مفهوم OLE DB[۲۵] خود معطوف کرده بود (که اخیراً مجدداً احیا شده است[۲۶])؛ مفهومی که دسترسی مستقیم به طیف وسیع‌تری از منابع داده، از دفترچه‌های آدرس گرفته تا فایل‌های متنی را فراهم می‌کرد. چندین سیستم جدید نیز به دنبال آن آمدند که توجهات را بیش از پیش از ODBC دور کرد؛ از جمله ActiveX Data Objects (ADO) و ADO.net که در طول چرخهٔ عمر خود کم‌وبیش با ODBC تعامل داشتند.

همزمان با اینکه مایکروسافت تمرکز خود را از کار مستقیم روی ODBC برداشت، حوزهٔ یونیکس به‌طور فزاینده‌ای از آن استقبال کرد. این روند توسط دو تغییر در بازار پیش رانده شد: معرفی رابط‌های کاربری گرافیکی (GUI) مانند GNOME که نیاز به دسترسی به این منابع را به شکلی غیرمتنی فراهم می‌کردند، و ظهور سیستم‌های پایگاه دادهٔ متن‌باز مانند PostgreSQL و MySQL، که ابتدا در بستر یونیکس شکل گرفتند. پذیرش بعدی ODBC توسط اپل برای استفاده از بستهٔ استاندارد سمت یونیکس iODBC در Mac OS X 10.2 (جَگوار)[۲۷] (که شرکت اوپن‌لینک سافت‌ور از سال ۲۰۰۱ به‌طور مستقل برای Mac OS X 10.0 و حتی Mac OS 9 فراهم کرده بود[۲۸])، جایگاه ODBC را به عنوان استاندارد دسترسی به داده‌های چندپلتفرمی بیش از پیش تثبیت کرد.

شرکت Sun Microsystems از سیستم ODBC به عنوان مبنایی برای استاندارد باز خود یعنی Java Database Connectivity (JDBC) استفاده کرد. از بسیاری جهات، JDBC را می‌توان نسخه‌ای از ODBC برای زبان برنامه‌نویسی Java به جای C در نظر گرفت. پل‌های (bridges) JDBC به ODBC به برنامه‌های مبتنی بر جاوا اجازه می‌دهند تا از طریق درایورهای ODBC به منابع داده دسترسی داشته باشند، آن هم در پلتفرم‌هایی که فاقد درایور بومی JDBC هستند؛ هرچند که امروزه این موارد نسبتاً نادر هستند. برعکس، پل‌های ODBC به JDBC به برنامه‌های مبتنی بر C اجازه می‌دهند تا از طریق درایورهای JDBC به منابع داده در پلتفرم‌ها یا پایگاه‌های داده‌ای که فاقد درایورهای مناسب ODBC هستند، دسترسی پیدا کنند.

ODBC امروز

[ویرایش | اشتراک‌گذاری]

ODBC امروزه همچنان به‌طور گسترده مورد استفاده قرار می‌گیرد و درایورهای آن برای بیشتر پلتفرم‌ها و بیشتر پایگاه‌های داده در دسترس هستند. یافتن درایورهای ODBC برای موتورهای پایگاه داده‌ای که برای جاسازی (Embedded) در نظر گرفته شده‌اند، مانند SQLite، غیرمتداول نیست؛ روشی که به ابزارهای موجود اجازه می‌دهد به عنوان فرانت‌اند برای این موتورها جهت آزمایش و رفع اشکال عمل کنند.[۲۹]

در سال‌های اخیر، ODBC همچنین برای اتصال به منابع دادهٔ ابری و پلتفرم‌های SaaS مانند Salesforce، گوگل بیگ‌کوئری و اسنوفلیک به کار گرفته شده است. در دسترس بودن درایورهای چندپلتفرمی (برای ویندوز، مک‌اواس و لینوکس) امکان یکپارچه‌سازی با ابزارهای مدرن تجزیه‌وتحلیل و هوش تجاری مانند پاور بی‌آی، تابلئو و RStudio را فراهم کرده است. این امر میزان کارایی و اهمیت ODBC را فراتر از پایگاه‌های دادهٔ رابطه‌ای سنتی، به انباره‌های دادهٔ ابری و جریان‌های کاری علم داده گسترش داده است.

  • ۱٫۰: منتشرشده در سپتامبر ۱۹۹۲[۳۰]
  • ۲٫۰: ح. ۱۹۹۴
  • ۲٫۵
  • ۳٫۰: ح. ۱۹۹۵، جان گودسون از Intersolv و فرانک پلو و پل کتون از IBM ورودی‌های قابل‌توجهی برای ODBC 3.0 فراهم کردند[۳۱]
  • ۳٫۵: ح. ۱۹۹۷
  • ۳٫۸: ح. ۲۰۰۹، همراه با ویندوز ۷[۳۲]
  • ۴٫۰: توسعه در ژوئن ۲۰۱۶ اعلام شد[۳۳] و نخستین پیاده‌سازی آن همراه با SQL Server 2017 در سپتامبر ۲۰۱۷ منتشر شد و درایورهای دسکتاپ اضافی در اواخر ۲۰۱۸ مشخصات نهایی در گیت‌هاب

درایورهای پایگاه داده دسکتاپ

[ویرایش | اشتراک‌گذاری]

منبع:[۳۴]

  • ۱٫۰ (اوت ۱۹۹۳): از پردازشگر پرس‌وجوی SIMBA تولید شده توسط PageAhead Software استفاده کرد.
  • ۲٫۰ (دسامبر ۱۹۹۴): همراه با ODBC 2.0 استفاده شد.
  • ۳٫۰ (اکتبر ۱۹۹۵): از ویندوز ۹۵ و Windows NT Workstation یا NT Server 3.51 پشتیبانی می‌کند. در این نسخه تنها درایورهای ۳۲ بیتی گنجانده شده بودند.
  • ۳٫۵ (اکتبر ۱۹۹۶): از مجموعه کاراکترهای دوبایتی (DBCS) پشتیبانی می‌کند و استفاده از نام‌های منابع دادهٔ فایل (DSNs) را در خود جای داده است. درایور مایکروسافت اکسس در نسخهٔ RISC برای استفاده در پلتفرم‌های آلفا برای ویندوز ۹۵/۹۸ و Windows NT 3.51 و سیستم‌عامل‌های بعد از آن منتشر شد.
  • ۴٫۰ (اواخر ۱۹۹۸): از فرمت یونی‌کد موتور مایکروسافت جت همراه با سازگاری با فرمت ANSI نسخه‌های قبلی پشتیبانی می‌کند.

درایورها و مدیران

[ویرایش | اشتراک‌گذاری]

درایورها

[ویرایش | اشتراک‌گذاری]

ODBC بر اساس مدل درایور دستگاه ساخته شده است؛ جایی که درایور، منطق مورد نیاز برای تبدیل یک مجموعه استاندارد از دستورها و توابع به فراخوانی‌های اختصاصی مورد نیاز سیستم زیرساخت را کپسوله می‌کند. برای نمونه، یک درایور چاپگر مجموعه استانداردی از دستورهای چاپ (همان API) را به برنامه‌هایی که از سیستم چاپ استفاده می‌کنند ارائه می‌دهد. فراخوانی‌های انجام‌شده به آن APIها توسط درایور به قالبی تبدیل می‌شوند که توسط سخت‌افزار واقعی، مانند PostScript یا PCL استفاده می‌شود.

در مورد ODBC، درایورها توابع بسیاری را کپسوله می‌کنند که می‌توان آن‌ها را به چند دستهٔ کلی تقسیم کرد. دستهٔ نخست توابع عمدتاً مربوط به یافتن، اتصال به و قطع اتصال از DBMSای است که درایور با آن ارتباط برقرار می‌کند. دستهٔ دوم برای ارسال دستورهای SQL از سیستم ODBC به DBMS استفاده می‌شود و هر دستوری را که به‌طور داخلی پشتیبانی نمی‌شود، تبدیل یا تفسیر می‌کند. برای نمونه، یک DBMS که از مکان‌نماها (cursors) پشتیبانی نمی‌کند، می‌تواند این قابلیت را در درایور شبیه‌سازی کند. سرانجام، دستهٔ دیگری از دستورهایی که بیشتر به صورت داخلی استفاده می‌شوند، برای تبدیل داده‌ها از قالب‌های داخلی DBMS به مجموعه‌ای از قالب‌های استاندارد ODBC (که بر اساس قالب‌های زبان C هستند) به کار می‌روند.

یک درایور ODBC به یک برنامهٔ سازگار با ODBC اجازه می‌دهد تا از یک منبع داده (که معمولاً یک DBMS است) استفاده کند. برخی درایورهای غیر DBMS برای منابع داده‌ای مانند فایل‌های CSV با پیاده‌سازی یک DBMS کوچک در داخل خود درایور وجود دارند. درایورهای ODBC برای بیشتر DBMSها، از جمله Oracle، PostgreSQL، MySQL، Microsoft SQL Server (اما نه برای نسخهٔ Compact یا همان نسخهٔ CE)، Mimer SQL، Sybase ASE، SAP HANA[۳۵][۳۶] و IBM Db2 وجود دارند. از آنجا که فناوری‌های مختلف قابلیت‌های متفاوتی دارند، بیشتر درایورهای ODBC تمامی قابلیت‌های تعریف‌شده در استاندارد ODBC را پیاده‌سازی نمی‌کنند. برخی درایورها قابلیت‌های اضافی دیگری را که توسط استاندارد تعریف نشده‌اند، ارائه می‌دهند.[source: 1]

مدیر درایور

[ویرایش | اشتراک‌گذاری]

درایورهای دستگاه معمولاً توسط یک لایهٔ مدیریتی مجزا شمارش، راه‌اندازی و مدیریت می‌شوند که ممکن است قابلیت‌های اضافی را فراهم کند. برای نمونه، سیستم‌های چاپ اغلب شامل قابلیتی برای ارائهٔ امکان اسپولینگ در بالای درایورها هستند و اسپولینگ چاپ را برای هر چاپگر پشتیبانی‌شده‌ای فراهم می‌کنند.

در ODBC، مدیر درایور (DM) این ویژگی‌ها را فراهم می‌کند.[۳۷] مدیر درایور می‌تواند درایورهای نصب‌شده را شمارش کرده و آن‌ها را به صورت یک فهرست، غالباً در قالب یک رابط کاربری گرافیکی، نمایش دهد.

اما برای عملکرد سیستم ODBC، مفهوم «نام منبع داده» (Data Source Name یا DSN) در مدیر درایور اهمیت بیشتری دارد. DSNها اطلاعات اضافی مورد نیاز برای اتصال به یک منبع دادهٔ خاص (در مقابل خود DBMS) را جمع‌آوری می‌کنند. برای نمونه، از یک درایور یکسان MySQL می‌توان برای اتصال به هر سرور MySQL استفاده کرد، اما اطلاعات اتصال برای اتصال به یک سرور خصوصی محلی با اطلاعات مورد نیاز برای اتصال به یک سرور عمومی میزبانی‌شده در اینترنت متفاوت است. DSN این اطلاعات را در یک قالب استاندارد ذخیره می‌کند و مدیر درایور آن‌ها را در طول درخواست‌های اتصال در اختیار درایور قرار می‌دهد. مدیر درایور همچنین دارای قابلیتی برای نمایش فهرستی از DSNها با استفاده از نام‌های قابل خواندن برای انسان و انتخاب آن‌ها در زمان اجرای برنامه برای اتصال به منابع مختلف است.

مدیر درایور همچنین قابلیت ذخیره‌سازی DSNهای ناقص را همراه با کد و منطقی دارد که در زمان اجرا از کاربر می‌خواهد اطلاعات مفقود را وارد کند. برای نمونه، می‌توان یک DSN را بدون رمز عبور لازم ایجاد کرد. هنگامی که یک برنامهٔ ODBC تلاش می‌کند با استفاده از این DSN به DBMS متصل شود، سیستم متوقف شده و پیش از ادامه، از کاربر می‌خواهد رمز عبور را وارد کند. این امر برنامه‌نویس کاربردی را از نیاز به نوشتن این نوع کد و همچنین دانستن اینکه چه سؤالاتی باید پرسیده شود، بی‌نیاز می‌کند. تمامی این موارد در درایور و DSNها گنجانده شده است.

پیکربندی‌های پل‌زنی

[ویرایش | اشتراک‌گذاری]

یک پل (Bridge) نوع خاصی از درایور است: درایوری که از فناوری مبتنی بر درایور دیگری استفاده می‌کند.

پل‌های ODBC به JDBC (ODBC-JDBC)

[ویرایش | اشتراک‌گذاری]

یک پل ODBC به JDBC شامل یک درایور ODBC است که از خدمات یک درایور JDBC برای اتصال به یک پایگاه داده استفاده می‌کند. این درایور فراخوانی توابع ODBC را به فراخوانی متدهای JDBC تبدیل می‌کند. برنامه‌نویسان معمولاً زمانی از چنین پلی استفاده می‌کنند که درایور ODBC را برای برخی پایگاه‌های داده در اختیار ندارند، اما به یک درایور JDBC دسترسی دارند. نمونه‌ها: پل ODBC-JDBC شرکت OpenLink, پل ODBC-JDBC شرکت SequeLink.

پل‌های JDBC به ODBC (JDBC-ODBC)

[ویرایش | اشتراک‌گذاری]

یک پل JDBC به ODBC شامل یک درایور JDBC است که از یک درایور ODBC برای اتصال به یک پایگاه دادهٔ مقصد استفاده می‌کند. این درایور فراخوانی متدهای JDBC را به فراخوانی توابع ODBC تبدیل می‌کند. برنامه‌نویسان معمولاً زمانی از چنین پلی استفاده می‌کنند که یک پایگاه دادهٔ معین فاقد درایور JDBC باشد، اما از طریق یک درایور ODBC در دسترس باشد. شرکت Sun Microsystems یکی از این پل‌ها را در JVM گنجاند، اما آن را به عنوان یک راهکار موقت در زمانی که درایورهای JDBC کمی وجود داشتند، در نظر گرفت (پل داخلی JDBC-ODBC در جاوا ۸ از JVM حذف شد[۳۸]). شرکت سان هرگز این پل را برای محیط‌های عملیاتی در نظر نگرفته بود و به‌طور کلی استفاده از آن را توصیه نمی‌کرد. تا تاریخ ۲۰۰۸ عرضه‌کنندگان مستقل دسترسی به داده، پل‌های JDBC-ODBC را ارائه می‌دهند که از استانداردهای فعلی برای هر دو مکانیسم پشتیبانی می‌کنند و عملکرد بسیار بهتری نسبت به مورد داخلی JVM دارند.[نیازمند منبع] نمونه‌ها: پل JDBC-ODBC شرکت OpenLink, پل JDBC-ODBC شرکت SequeLink, پل JDBC-ODBC شرکت ZappySys.

پل‌های OLE DB به ODBC

[ویرایش | اشتراک‌گذاری]

یک پل OLE DB به ODBC شامل یک ارائه‌دهندهٔ OLE DB است که از خدمات یک درایور ODBC برای اتصال به یک پایگاه دادهٔ مقصد استفاده می‌کند. این ارائه‌دهنده فراخوانی متدهای OLE DB را به فراخوانی توابع ODBC تبدیل می‌کند. برنامه‌نویسان معمولاً زمانی از چنین پلی استفاده می‌کنند که یک پایگاه دادهٔ معین فاقد ارائه‌دهندهٔ OLE DB باشد، اما از طریق یک درایور ODBC در دسترس باشد. مایکروسافت یک نمونه از آن را با نام MSDASQL.DLL به عنوان بخشی از MDAC (بسته مؤلفه‌های سیستم)، همراه با سایر درایورهای پایگاه داده، عرضه می‌کند تا توسعه را در زبان‌های سازگار با COM (مانند Visual Basic) ساده کند. اشخاص ثالث نیز چنین پل‌هایی را توسعه داده‌اند؛ به ویژه شرکت OpenLink Software که ارائه‌دهندهٔ ۶۴ بیتی OLE DB برای منابع دادهٔ ODBC آن، خلأ موجود را زمانی که مایکروسافت در ابتدا این پل را برای سیستم‌عامل‌های ۶۴ بیتی خود منسوخ کرد، پر کرد.[۳۹] (مایکروسافت بعدها از تصمیم خود صرف‌نظر کرد و نسخه‌های ۶۴ بیتی ویندوز از ویندوز سرور ۲۰۰۸ و Windows Vista SP1 به بعد، با نسخهٔ ۶۴ بیتی MSDASQL عرضه شدند) نمونه‌ها: پل OLEDB-ODBC شرکت OpenLink بایگانی‌شده در ۲۷ مارس ۲۰۱۷ توسط Wayback Machine، پل OLEDB-ODBC شرکت SequeLink[پیوند مرده].

پل‌های ADO.NET به ODBC

[ویرایش | اشتراک‌گذاری]

یک پل ADO.NET به ODBC شامل یک ارائه‌دهنده ADO.NET است که از خدمات یک درایور ODBC برای اتصال به یک پایگاه دادهٔ مقصد استفاده می‌کند. این ارائه‌دهنده فراخوانی متدهای ADO.NET را به فراخوانی توابع ODBC تبدیل می‌کند. برنامه‌نویسان معمولاً زمانی از چنین پلی استفاده می‌کنند که یک پایگاه دادهٔ معین فاقد ارائه‌دهندهٔ ADO.NET باشد، اما از طریق یک درایور ODBC در دسترس باشد. مایکروسافت یکی از این موارد را به عنوان بخشی از MDAC (بسته مؤلفه‌های سیستم)، همراه با سایر درایورهای پایگاه داده عرضه می‌کند تا توسعه را در زبان C# ساده کند. اشخاص ثالث نیز چنین پل‌هایی را توسعه داده‌اند. نمونه‌ها: پل ADO.NET-ODBC شرکت OpenLink, پل ADO.NET-ODBC شرکت SequeLink.

جستارهای وابسته

[ویرایش | اشتراک‌گذاری]

منابع

[ویرایش | اشتراک‌گذاری]
کتاب‌شناسی
  • Geiger, Kyle (1995). Inside ODBC. Microsoft Press. ISBN 978-1-55615-815-5.
پانویس
  1. ↑ McGlinn, Evan (1988), Blueprint Lets 1-2-3 Access Outside Data", InfoWorld, vol. 10, no. 14, ۴ آوریل ۱۹۸۸, pp. 1, 69
  2. 1 2 Geiger 1995, p. 65.
  3. ↑ Geiger 1995, p. 86–87.
  4. ↑ Geiger 1995, p. 56.
  5. ↑ Geiger 1995, p. 106.
  6. ↑ Geiger 1995, p. 165.
  7. 1 2 Geiger 1995, p. 186–187.
  8. ↑ ISO/IEC 9075-3 – Information technology – Database languages – SQL – Part 3: Call-Level Interface (SQL/CLI)
  9. ↑ Geiger 1995, p. 203.
  10. ↑ Harindranath, G; Jože Zupančič (2001). New perspectives on information systems development: theory, methods, and practice. Springer. p. 451. ISBN 978-0-306-47251-0. Retrieved 28 ژوئیه 2010. The first ODBC drivers […] used the SIMBA query processor, which translated calls into the Microsoft Jet ISAM calls, and dispatched the calls to the appropriate ISAM driver to access the backend […]
  11. ↑ "Linux/UNIX ODBC – What is ODBC?".
  12. ↑ "Our History", Simba Technologies
  13. ↑ Idehen, Kingsley Uyi (اکتبر 1994). "ODBC and progress V7.2d". Usenet Newsgroup comp.databases. Retrieved 13 دسامبر 2013.
  14. ↑ Idehen, Kingsley Uyi (18 ژوئیه 1995). "Need ODBC/Ingres driver for DEC OSF/1". Usenet Newsgroup comp.databases.oracle. Retrieved 13 دسامبر 2013.
  15. ↑ Sippl, Roger (1996) "SQL Access Group's Call-Level Interface", Dr. Dobbs, ۱ فوریه ۱۹۹۶
  16. ↑ "Similarities and differences between ODBC and CLI", InfoSphere Classic documentation, IBM, ۲۶ سپتامبر ۲۰۰۸
  17. ↑ "OLE DB and SQL Server: History, End-Game, and some Microsoft "dirt"". 25 سپتامبر 2011.
  18. ↑ "Announcing the new release of OLE DB Driver for SQL Server". 6 اکتبر 2017.
  19. ↑ Anderson, Andrew (20 ژوئن 2003). "Open Database Connectivity in Jaguar". O'Reilly MacDevCenter.com. O'Reilly Media, Inc. Retrieved 13 دسامبر 2013.
  20. ↑ Sellers, Dennis (17 ژوئیه 2001). "ODBC SDK update out for Mac OS Classic, Mac OS X". MacWorld. IDG Consumer & SMB. Retrieved 13 دسامبر 2013.
  21. ↑ Idehen, Kingsley Uyi (اکتبر 1994). "ODBC and progress V7.2d". Usenet Newsgroup comp.databases. Retrieved 13 دسامبر 2013.
  22. ↑ Idehen, Kingsley Uyi (18 ژوئیه 1995). "Need ODBC/Ingres driver for DEC OSF/1". Usenet Newsgroup comp.databases.oracle. Retrieved 13 دسامبر 2013.
  23. ↑ Sippl, Roger (1996) "SQL Access Group's Call-Level Interface", Dr. Dobbs, ۱ فوریه ۱۹۹۶
  24. ↑ "Similarities and differences between ODBC and CLI", InfoSphere Classic documentation, IBM, ۲۶ سپتامبر ۲۰۰۸
  25. ↑ "OLE DB and SQL Server: History, End-Game, and some Microsoft "dirt"". 25 سپتامبر 2011.
  26. ↑ "Announcing the new release of OLE DB Driver for SQL Server". 6 اکتبر 2017.
  27. ↑ Anderson, Andrew (20 ژوئن 2003). "Open Database Connectivity in Jaguar". O'Reilly MacDevCenter.com. O'Reilly Media, Inc. Retrieved 13 دسامبر 2013.
  28. ↑ Sellers, Dennis (17 ژوئیه 2001). "ODBC SDK update out for Mac OS Classic, Mac OS X". MacWorld. IDG Consumer & SMB. Retrieved 13 دسامبر 2013.
  29. ↑ Werner, Christian (2018) "SQLite ODBC Driver" بایگانی‌شده در ۲۰۱۴-۰۶-۲۶ توسط Wayback Machine, ۲۰۱۸-۰۲-۲۴
  30. ↑ Antal, Tiberiu Alexandru. "Access to an Oracle database using JDBC" (PDF). کلوژ-نپوکا: Technical University of Cluj-Napoca. p. 2. Archived from the original (PDF) on 22 ژوئیه 2011. Retrieved 27 اکتبر 2009. ODBC 1.0 was released in September 1992
  31. ↑ Microsoft Corporation. Microsoft ODBC 3.0 Programmer's Reference and SDK Guide, Volume 1. Microsoft Press. February 1997. (شابک ‎۹۷۸۱۵۷۲۳۱۵۱۶۷)
  32. ↑ "What's New in ODBC 3.8". Microsoft. Retrieved 13 ژانویه 2010. Windows 7 includes an updated version of ODBC, ODBC 3.8.
  33. ↑ Rukmangathan, Krishnakumar (7 ژوئن 2016). "A new release of ODBC for Modern Data Stores". Microsoft Data Access / SQL BI Technologies Blog. Microsoft. Retrieved 3 ژانویه 2017. After more than 15 years since the last release, Microsoft is looking at updating the Open Data Base Connectivity (ODBC) specification.
  34. ↑ "History of the Desktop Database Drivers". 19 ژانویه 2017.
  35. ↑ "SAP HANA System Properties". DB-Engines. Archived from the original on 23 مارس 2016. Retrieved 28 مارس 2016.
  36. ↑ "Connect to SAP HANA via ODBC - SAP HANA Developer Guide for SAP HANA Studio - SAP Library". help.sap.com. Retrieved 28 مارس 2016.
  37. ↑ Sybase. "Introduction to ODBC". infocenter.sybase.com. Sybase. Retrieved 8 اکتبر 2011.
  38. ↑ "Java JDBC API". docs.oracle.com. Retrieved 18 دسامبر 2018.
  39. ↑ مایکروسافت، «نقشه راه فناوری‌های دسترسی به داده»، مؤلفه‌های منسوخ MDAC، مایکروسافت «راهنمای برنامه‌نویس ADO» پیوست الف: ارائه‌دهندگان، ارائه‌دهنده OLE DB مایکروسافت برای ODBC، بازیابی‌شده در ۳۰ ژوئیه ۲۰۰۵. بایگانی‌شده در ۵ اکتبر ۲۰۰۱ توسط Wayback Machine

پیوند به بیرون

[ویرایش | اشتراک‌گذاری]
برگرفته از «https://fa.wikipedia.org/w/index.php?title=اتصال‌دهنده_باز_پایگاه‌داده&oldid=44710373»