ODBC Rocks!

在发布了19年之后,ODBC已经成为软件工业的基石之一。本文将为您介绍为什么ODBC会扮演如此重要的角色,微软SQL Server和ODBC的关系,还会讨论未来ODBC的发展方向。 作为一个被广泛使用、跨平台、跨数据库的数据访问技术,ODBC已经取得了巨大的成功。ODBC可能是ISO/IEC 9075-3:2003 SQL调用级接口(Call Level Interface,全部SQL标准的第三部分)最广为人知的实现。ODBC包含在Windows、MacOS和所有主要的Linux版本中,也包含在很多Unix版本中,例如AIX、HP-UX、Solaris和FreeBSD。甚至PDA和Smartphone手机都包含ODBC! 虽然人们总是把ODBC作为C和C++程序应用接口(API),ODBC也可以在其他的编程语言环境下使用。举例来说,很多COBOL程序用ODBC来做数据访问,动态语言如PHP、Perl、Python、Ruby,还有一些快速应用开发工具(RAD)如微软Access也使用ODBC。 尽管ODBC多用于关系数据库的连接,其他数据源也很少能离得开ODBC驱动:文本文件、Excel表格,dBase、Paradox、C-ISAM、Btrieve还有VSAM等索引顺序存取方法(ISAM)数据源,你能想到的基本上都有相应的ODBC驱动程序。对于没有ODBC驱动的数据源,你很容易就能找到一个第三方的ODBC驱动,或者用驱动开发工具包来填补这个空缺。总而言之,没有一个关系数据库离得开ODBC驱动。 ODBC广泛用于企业级应用开发,大多数主流独立软件供应商(ISV)都提供对其的支持。ERP、CRM、SCM和微软office,都通过ODBC来做查询、分析、报表生成,还有ETL(数据抽取、转换和加载)。 是什么让ODBC在不同的软件业细分市场都如此流行呢?为什么ODBC在可以预见的未来还会继续流行下去? 对于数据源(Data Source)的拥有者,ODBC是必须的。ODBC同ADO.NET、JDBC和OLE DB一样, 作为工业标准的应用编程接口(API),使数据源可以被程序开发者、被第三方工具和程序包访问。为所有这些数据访问技术开发相对应的驱动需要花费大量的时间、财力和物力。如果资源有限或者时间紧迫,最好的策略是什么呢?应该是先实现ODBC驱动,之后再考虑实现别的驱动。为什么?第一,其它所有的API都可以桥接到ODBC上,一旦有了ODBC驱动,你就可以通过其它任何API来访问数据库。第二,即使不考虑桥接,ODBC可以给数据源用户提供最广泛的第三方软件支持,因为ODBC是最早最成熟的数据访问技术,累计了大量的工具和应用。 ODBC能,而且通常是在专有的(proprietary)API之上实现的。在ODBC发展的早期,很多人认为这是第一代ODBC驱动的缺点。但是后来的研究表明,把ODBC建立在专有的Native (Native)API上对性能的影响微乎其微。在某些情况下,如果ODBC驱动引入策略去克服底层Native API的薄弱环节,ODBC甚至比专有API更高效。对于一些数据库来讲,包括微软SQL Server,ODBC都能满足作为专有Native API的角色。 企业IT和企业开发人员生活在一个非常多变的环境中,他们必须支持多语言、多操作系统,还有多种数据源。他们的压力一方面来自整合和标准化应用平台,另一方面来自改进现有程序,重整业务流程,提高信息整合,还有引入商业智能(Business Intelligence)。如何应付这些压力呢? 在数据集成和数据整合的情景下,从ETL到BI,ODBC的普及是很有价值的,它能将数据从数据包和客户应用中提取出来。 .Net平台现在被广泛应用于新的开发中。但在许多情况下,从时间、业务风险、整体成本因素上考量,代码重用和修改现有程序更容易被接受。在这方面,ODBC能做的很多。通常来说,应用程序开发人员通过在Visual Studio里使用/CLR编译选项,可以很容易的重新编译现有的代码,使得它能在.Net应用里被重用。这极大地简化了现有的C++和ODBC的业务逻辑与一个现代化的用户界面之间的结合,用户可以快速开发.NET平台应用。ODBC为各种不同的数据源和操作系统提供了一个通用的API,可以同步的访问多个数据源。这些是信息整合,聚集和集成的基本要求,无论是在native应用中,还是通过.Net平台的ODBC数据提供程序(Data Provider for ODBC)。 除了直接重用现有的业务逻辑,ODBC也是替换其他专有的API的一个重要候选。比如在做数据库迁移的时候,把使用如DB – Library,CT-Library或者OCI的应用程序迁移到ODBC上,要比完全用.Net重写来得高效和低成本,因为ODBC同其他Native API是很相似的 。 ISV通常会支持多种不同的数据库,从而增加市场和客户吸引力。ODBC提供了多种办法来满足这一要求。总之,ODBC提供了一个通用的API,可以处理多个数据源,而且如上所述,有广泛且可用的驱动程序。当然,不同的数据源也有不同的特性,这反映在一系列不同的ODBC驱动程序上。 解决这一问题的最简单的办法是使用最严格的行为模式和SQL方言子集(SQL dialect subset)。ODBC提供转义序列(escape sequences)来解决SQL方言之间的细小分歧。如果这还不够,下一步应用程序可以通过ODBC查询驱动程序的特性、数据库的特性,动态的来处理。应用程序也可以判断出实际的驱动程序和数据库,在通用性和驱动程序特性之间权衡,从而满足严格的功能和性能要求。而且,ODBC对应用程序提交到数据源的SQL语句没有任何限制,因此不会影响SQL方言的丰富性。 一些ISV使用内部的数据抽象层来实现功能——用不同的API访问不同的数据库。即使是在这种情况下,ODBC也可以胜任。对于一些数据库,特别是微软SQL Server,ODBC是性能最好的API。 系统集成商和增值经销商(VAR,Value Added Reseller)从两方面受益于ODBC。他们可以确信,无论什么操作平台和其他基础设施,所有数据源都会有ODBC支持,从而不需要开发一个专门的工具。其次,相比于技能相对狭窄的技术人员,熟悉ODBC的技术人员可以满足更广泛的客户需求。 ODBC和微软的SQL Server 对于软件行业的方方面面来说,ODBC有广泛而持久的吸引力。虽然有时候低调了些,ODBC仍然是Microsoft数据平台一个重要的组成部分。现在,让我们讨论一下关于ODBC和Microsoft SQL Server之间关系的更多细节。 最早的时候, DB-Library是SQL Server唯一的客户端应用程序API。后来,SQL Server API家族又添加了ODBC,然后是OLE DB,以及最近的ADO.NET。DB-Library由于技术上的限制已经不推荐使用,只是为旧的应用程序提供向后兼容性。 “在OLE DB发布后,微软的专家们相信它将取代ODBC…

1

Component Checker 2.0使用简介

通过上一篇博客,我们已经知道Component Checker是一个用来检查MDAC安装版本的软件。简单地说,MDAC(Microsoft Data Access Components 的简称)是微软数据库访问组件,它是Windows平台上应用程序连接和访问数据库的接口。MDAC的应用十分广泛,但是由于历史原因偶尔会遇到兼容性问题,所以使用前通常要先检查MDAC的安装版本。 你可以通过注册表方便快捷地检查MDAC版本。在注册表中通过HKEY_LOCAL_MACHINE\Software\Microsoft\DataAccess\FullInstallVer便可以查看FullInstallVer和Version的值。但是,当系统中安装了多个版本的MDAC,注册表提供的信息不完全可靠。 怎样才能最可靠的检查MDAC的版本呢?你需要将系统中每个属于MDAC的DLL文件的版本号与Microsoft发布的所有MDAC版本所附带的DLL文件列表进行比较。显然,这是一个繁琐的过程。 Component Checker可以帮助你轻松完成版本检查。Component Checker的使用十分简单: 从Microsoft Download Center下载并安装Component Checker。 在Windows中运行Component Checker。 选择检测类型。你可以选择Perform analysis of your machine and automatically determine the release version (Default)进行自动检测,或者选择Perform analysis against a selected version并在下拉菜单中选择一个版本号。 Component Checker将尝试扫描所有的 MDAC DLL文件和注册表设置,从而确定计算机上的 MDAC 版本。此过程通常需要几分钟时间。 如果选择了自动检查,Component Checker会比较系统中通过各种途径安装的MDAC DLL,然后推荐一个最接近的版本号。完成后,会收到以下消息:The MDAC version that is closest to the version on your computer is…


MDAC Component Checker 2.0发布了

2008年12月,在圣诞前夕SQL中国研发中心Data Programmability团队发布了MDAC Component Checker 2.0版本。 Component Checker的产生源于MDAC版本不兼容给应用软件带来的困扰。在MDAC的发展历程中,存在2.1、2.5、2.6、2.7和2.8多个版本。它曾绑定在不同的Microsoft产品中(Microsoft SQL Server、Microsoft Visual Studio、Microsoft Office、Microsoft Back Office以及一些其他的微软产品),也曾作为独立发布软件(madc_typ.exe)在MSDN上发布。现在,MDAC作为系统组件捆绑在Windows XP SP2以及以后的Windows系统中。 由于应用程序使用MDAC所遇到的大多数问题都与版本不匹配有关,早在2005年,Microsoft就发布了Component Checker 1.0,用于检测Microsoft MDAC的安装版本,并可诊断并报告安装相关的各种问题。此次推出的新版本Component Checker 2.0由SQL中国研发中心上海Data Programmability团队开发。新版本的改进和新功能包括: 支持更多的Windows平台 支持生成MDAC快照(适用于Windows XP SP3和Windows Server 2003 SP2) 支持64位的Windows 谈到Component Checker 2.0研发的经验和挑战时,软件工程师Simon Yuan说:“Component Checker 2.0提供了对更多的Windows平台的支持,并且是兼容较低版本的Windows平台的。同时我们也考虑到了用户重新安装了更高版本的MDAC独立安装包这种情况,并提供了相应的支持。在开发和测试过程中我们需要考虑Windows平台和MDAC组件之间的各种可能的组合,并在每一个我们所支持的平台上进行了大量的测试。Component Checker 2.0的开发中,我深刻体会到了Microsoft对产品质量的严格要求。” 如果你想了解更多Component Checker的信息,请访问 MDAC Utility: Component Checker。更多SQL中国研发团队的信息和动态,请继续关注我们的博客。 庄永真 Program Manager

2

64位OLEDB Provider for ODBC (MSDASQL) 发布了!

很高兴地宣布Windows Server 2003上64位OLEDB Provider for ODBC 发布了!你可以从这里下载安装程序,也可以在不久后随“Windows Update”发布的版本里安装。 MSDASQL是一个桥接OLEDB与ODBC的组件,使得基于OLEDB和ADO(内部使用OLEDB)的应用程序可以操作基于ODBC驱动程序的数据源。MSDASQL随着Windows操作系统发布,而Windows Server 2008和Windows Vista SP1是最早内置64位版本MSDASQL的操作系统。 曾经在MSDN上有传言说64位MSDASQL将不会被发布。实际上,在接到大量客户需求的基础上,我们投入相当的资源开发了Windows Server 2003、Windows Vista SP1和 Windows Server 2008上的版本,以满足客户需求。所以,Microsoft并没有“抛弃”这项技术的计划 J 林默 WDAC项目经理

8