Chinaunix首页 | 论坛 | 博客
  • 博客访问: 103551030
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551031
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551032
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551033
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551034
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551035
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551036
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551037
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551038
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551029
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551040
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551041
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551042
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551043
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551044
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551045
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551046
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551047
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551048
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551049
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551050
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551051
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551052
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551053
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551040
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551056
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551057
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551058
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551059
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551060
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551061
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551063
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551064
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551065
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551066
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551067
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551068
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551059
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551070
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551071
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551072
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551073
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551074
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551075
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551076
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551077
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551078
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551079
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551080
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551081
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551082
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks

DB2 9 应用开发(733 考试)认证指南,第 5 部分: CLI/ODBC 编程(2)-sdccf-ChinaUnix博客
  • 博客访问: 103551083
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类:

2008-05-31 23:31:37

developerWorks



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283775) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283774) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283773) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283772) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283771) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283770) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283769) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283768) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283767) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283766) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283765) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283764) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283763) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283762) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283761) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283760) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283759) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283758) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283757) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283756) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283755) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283754) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283753) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283752) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283751) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283750) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283749) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283748) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283747) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283746) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283745) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283744) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283743) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283742) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283741) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283740) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283739) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283738) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283737) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283736) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283735) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283734) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283733) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283732) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283731) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283730) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283729) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283728) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283727) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283726) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283725) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获



CLI/ODBC 编程简介

结构化查询语言(Structured Query Language,SQL)是用于操纵数据库对象和它们包含的数据的一种标准语言。但是,由于 SQL 没有过程语言的性质,因此,通常是将高级编程语言的决策和顺序控制与 SQL 的数据存储、操纵和检索功能相结合来开发数据库应用程序。有一些方法可以将 SQL 与高级编程语言相结合,但最简单的方法是将 SQL 语句直接嵌入到用于创建应用程序的高级编程语言源代码文件中。这种技术被成为嵌入式 SQL 编程。

嵌入式 SQL 编程最大的缺点是所开发的应用程序缺乏互操作性。用嵌入式 SQL 为 DB2 开发的应用程序如果要与其他关系数据库管理系统(RDBMS)交互,必须进行修改(在某些情况下,甚至要完全重写)。由于不论为何种 RDBMS 编写的嵌入式 SQL 应用程序中都存在这样的限制,因此在 20 世纪 90 年代初,X/Open 公司和 SQL Access Group(SAG,现在属于 X/Open)就为可调用 SQL 接口联合开发了一种标准的规范。这种接口被称为 X/Open CLI。大部分 X/Open CLI 规范后来都被接受为 ISO CLI 国际标准的一部分。 X/Open CLI 的主要目的是通过允许数据库应用程序独立于任何一种数据库管理系统的编程接口,增加数据库应用程序的可移植性。

在 1992,Microsoft 为 Microsoft Windows 操作系统开发了一个名为 Open Database Connectivity (ODBC) 的可调用 SQL 接口。ODBC 基于 X/Open CLI 标准规范,它提供了 X/Open CLI 没有提供的扩展功能和能力。ODBC 位于一个操作环境之上,在此环境中,一个名为 ODBC Driver Manager 的组件在应用程序运行时动态地装载特定于数据源的 ODBC 驱动程序。每个特定于数据源的驱动程序负责实现 ODBC 规范中定义的一种或全部功能,并提供与该驱动程序所针对的特定数据源的交互。ODBC Driver Manager 提供了一个集中控制点;当一个 ODBC 应用程序执行时,发出的每个 ODBC 函数调用被发送到 ODBC Driver Manager,并从那里转发到适当的数据源驱动程序进行处理。通过驱动程序,可以将应用程序直接链接到一个 ODBC 驱动程序库,而不必链接到每种特定于产品的数据库本身。

DB2 Call Level Interface (DB2 CLI) 基于 ISO CLI 国际标准,它提供了 ODBC 规范中给出的大部分功能。使用 DB2 CLI 而不是 ODBC 的应用程序直接链接到 DB2 CLI 加载库,任何 ODBC Driver Manager 都可以加载这个库作为一个 ODBC 驱动程序。DB2 UDB 应用程序还可以独立地使用 DB2 CLI 装载库。但是,当以这种方式使用这个库时,应用程序本身不能与其他数据源通信。





回页首


在本系列的第四篇教程(见参考资料小节)中可以看到,嵌入式 SQL 应用程序是通过直接将 SQL 语句嵌入到使用高级编程语言编写的一个或多个源代码文件中而构建的。而 CLI/ODBC 应用程序则依赖于一组标准的应用程序编程接口(API)函数将 SQL 语句发送到 DB2 Database Manager 进行处理。嵌入式 SQL 应用程序和 CLI/ODBC 应用程序在以下方面也有不同之处:

  • CLI/ODBC 应用程序不需要显式地声明和使用主机变量;可以使用任何变量来发送数据或者从一个数据源检索数据。

  • CLI/ODBC 应用程序不必显式地声明游标。相反,每当执行 SQLExecute() 函数或 SQLExecDirect() 函数(稍后会更详细讨论这两个函数)时,会根据需要自动生成游标。

  • 在 CLI/ODBC 应用程序中,不需要显式地打开游标;当生成游标时,会自动打开游标。

  • CLI/ODBC 函数使用句柄 管理环境、连接和与 SQL 语句相关的信息。这种技术便于将那些信息当作抽象对象来对待。通过使用句柄,CLI/ODBC 应用程序就不必使用特定于数据库产品的数据结构,例如 DB2 SQL Communications Area (SQLCA) 和 SQL Descriptor Area (SQLDA) 数据结构。

  • CLI/ODBC 应用程序天生就具有建立到多个数据源或同一个数据源的多个连接的能力。(嵌入式 SQL 应用程序只有在使用 Type 2 连接的情况下,才能一次连接到多个数据源。)

嵌入式 SQL 应用程序和 CLI/ODBC 应用程序虽然有这么多不同之处,但是它们在概念上也有一个重要的共同点:CLI/ODBC 应用程序可以执行任何能在嵌入式 SQL 应用程序中动态准备的任何 SQL 语句。这一点是有保障的,因为 CLI/ODBC 应用程序将所有的 SQL 语句直接传递到数据源,以便动态执行这些语句。(CLI/ODBC 应用程序还可以执行一些不能动态准备的 SQL 语句,例如复合 SQL 语句,但是通常上不支持静态 SQL。)

由于是由数据源来处理 CLI/ODBC 应用程序提交的所有 SQL 语句,这就保证了 CLI/ODBC 应用程序的可移植性。而嵌入式 SQL 并不总是如此,因为如果所使用的关系数据库产品不同,动态准备 SQL 语句的方式也会有所不同。另外,由于有些数据库产品(包括 DB2)可以动态准备 COMMITROLLBACK SQL 语句,而有些数据库产品又不能,因此 CLI/ODBC 应用程序中通常不使用这些语句。相反,CLI/ODBC 应用程序依靠 SQLEndTran() 函数结束活动事务(不使用自动提交的情况下)。这种技术可保证不管使用何种数据库产品,CLI/ODBC 应用程序都能成功地结束事务。

阅读(283724) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

chinaunix网友2008-07-15 17:30:48

看了有收获