2,497
社区成员
发帖
与我相关
我的任务
分享新人求助---BDE连接不上ORACLE数据库
在安装BDE后，在DATABASE处新建ORACLE，之后再SERVIER NAME选择下拉框报处“invalid filename”,我手动输入我的数据库名称，在USER NAME那里输入用户名，保存后，点右边的ORACLE右边的+号连接数据库，报错"ORA-03114:not connected to oracle". 请问这个要怎么配置才能弄好呢？
我的数据库是10.1.0版本，client是10.2.0版本，另外，我在client文件夹下没有找到tnsnames.ora文件。
我的数据库是10.1.0版本，client是10.2.0版本，另外，我在client文件夹下没有找到tnsnames.ora文件。
...全文
请发表友善的回复…
发表回复
xxzqbxxzqb 2012-10-08
- 打赏
- 举报
我当时也就连接个Pradox，牛B一点是SQL 7或2000 ，楼主一下子就Oracle10，起点都不一样，哈哈哈
xxzqbxxzqb 2012-10-08
- 打赏
- 举报
精彩。
不过回过头来看一下楼主的疑问：
[Quote=引用楼主 的回复:]
在安装BDE后，在DATABASE处新建ORACLE，之后再SERVIER NAME选择下拉框报处“invalid filename”,我手动输入我的数据库名称，在USER NAME那里输入用户名，保存后，点右边的ORACLE右边的+号连接数据库，报错"ORA-03114:not connected to oracle". 请问这个要怎么配置才能弄好呢？
我的数据库是10.1.0版本，clien……
[/Quote]
如果楼主用BDE来连接Oracle，那么我猜想楼主是不是初学者？ 商业软件是不会这样搞的。
所以我才会告诉他不要用BDE了。
我刚学Delphi的时候，用Table控件连接数据库都让我如醉如痴，而之后Table 连同Query根本就不再用。
不过回过头来看一下楼主的疑问：
[Quote=引用楼主 的回复:]
在安装BDE后，在DATABASE处新建ORACLE，之后再SERVIER NAME选择下拉框报处“invalid filename”,我手动输入我的数据库名称，在USER NAME那里输入用户名，保存后，点右边的ORACLE右边的+号连接数据库，报错"ORA-03114:not connected to oracle". 请问这个要怎么配置才能弄好呢？
我的数据库是10.1.0版本，clien……
[/Quote]
如果楼主用BDE来连接Oracle，那么我猜想楼主是不是初学者？ 商业软件是不会这样搞的。
所以我才会告诉他不要用BDE了。
我刚学Delphi的时候，用Table控件连接数据库都让我如醉如痴，而之后Table 连同Query根本就不再用。
biololo 2012-09-30
- 打赏
- 举报
[Quote=引用 11 楼 的回复:]
的确，楼上考虑的很详细，也很周全了。佩服。
[/Quote]
哪里哪里，小生只是略知一二
的确，楼上考虑的很详细，也很周全了。佩服。
[/Quote]
哪里哪里，小生只是略知一二
biololo 2012-09-29
- 打赏
- 举报
[Quote=引用 9 楼 的回复:]
对于楼上的说法，我也解释一下：
1、第三方控件的使用，有人喜欢一个第三方的控件也不用，这样代码的可复制性比较好；另外有些人喜欢使用第三方控件，因为高效。这属于见仁见智的问题，有利有弊，根据自己的需要选择。
2、数据库的设计，建议把大部分的操作都放在数据库中，客户端只需要调用相应的存储过程或者函数即可。这样有很多优势，其中之一就是需要变更数据库平台时，客户端的改动最小；
3、至于UniDAC……
[/Quote]
1：对于『可复用性』，背后隐藏一个标准的问题，就是无论是UniDAC还是RemObject这些框架，总是会部分兼容MIDAS/DataSnap架构，但不会说这些控件中间件厂商彼此互相兼容，所以在使用Delphi提供的标准数据访问组件的时候，你才会觉得在代码这个级别的复用性还行。但复用性其实不是关键，因为在做团队开发的时候，总是会要求发环境一致，如果你需要将其他团队的框架移植过来，恐怕控件还不是最主要的障碍。
我想，还有一个蛮重要的原因就是你买了Delphi，一个license如果是D7也要6000RMB吧，如果是XE2也要30000RMB，既然花了这么多钱，再说它的框架也不难用，若非遇到变态的需求，干嘛不首先考虑delphi的组件呢？在广泛使用UniDAC和RemObject组件的国产软件中，有多少是从开发license到部署license的都认真付费的呢？所以呢，要根据需要和荷包来决定，在需求允许的范围内，如果付费是一件很有所谓的事情，那就要让花出去的每分钱都尽量有效益，不管这个钱是开发者花还是用户花；如果付费不是问题，那你就怎么无敌怎么来。
2：对于楼上的『数据库设计』和楼上上上的『移植方便』，当软件的逻辑倚重数据库执行，所谓夸数据库的移植就必定不太平。因为一般稍微复杂的数据处理，程序员和官方文档中都推荐使用SQL来解决的，只要使用SQL就存在方言的问题，平台差异性的问题，这个和SQL是存在于stored procedure中还是app中都一样，需要修改SQL。
如果SQL存在app中，如果架构设计得当，在数据库变动时，仍然可使得客户端相关代码改动比较小，例如加一个数据访问层，不管这个访问层是service还是remote interface甚至只是代码接口，都可以。这种做法有利有弊。优势是，部署、升级、维护、版本管理都相对容易，对于目标数据库的权限及环境要求一般不复杂；缺点是，执行效率相对低，调试复杂，尤其是在线调试复杂。
如果SQL被实现在stored procedure中，诚然，如楼上所讲，在数据库变动时app代码改动较小，这是一个天然的优势，而且这样做SQL的执行效率也较高。但也要知道随之而来的缺点，就是数据库的安全设置会变得复杂，有时候很难解决，例如如果你要和一个重要的数据系统集成，人家不让你在目标数据库上安装任何函数和存储过程，只允许抽取数据呢，是不是有些麻烦。。。如果目标数据库有很多个呢。。。如果你的数据库做了拆分呢。。。另外，部署、升级、维护、版本管理都要针对每个数据库进行，要保持所有数据库的SP的版本都一致，当你的服务停机时间只能很短服务又很重要的时候，失败了又要安装回滚，是不是压力就很大？
对于楼上的说法，我也解释一下：
1、第三方控件的使用，有人喜欢一个第三方的控件也不用，这样代码的可复制性比较好；另外有些人喜欢使用第三方控件，因为高效。这属于见仁见智的问题，有利有弊，根据自己的需要选择。
2、数据库的设计，建议把大部分的操作都放在数据库中，客户端只需要调用相应的存储过程或者函数即可。这样有很多优势，其中之一就是需要变更数据库平台时，客户端的改动最小；
3、至于UniDAC……
[/Quote]
1：对于『可复用性』，背后隐藏一个标准的问题，就是无论是UniDAC还是RemObject这些框架，总是会部分兼容MIDAS/DataSnap架构，但不会说这些控件中间件厂商彼此互相兼容，所以在使用Delphi提供的标准数据访问组件的时候，你才会觉得在代码这个级别的复用性还行。但复用性其实不是关键，因为在做团队开发的时候，总是会要求发环境一致，如果你需要将其他团队的框架移植过来，恐怕控件还不是最主要的障碍。
我想，还有一个蛮重要的原因就是你买了Delphi，一个license如果是D7也要6000RMB吧，如果是XE2也要30000RMB，既然花了这么多钱，再说它的框架也不难用，若非遇到变态的需求，干嘛不首先考虑delphi的组件呢？在广泛使用UniDAC和RemObject组件的国产软件中，有多少是从开发license到部署license的都认真付费的呢？所以呢，要根据需要和荷包来决定，在需求允许的范围内，如果付费是一件很有所谓的事情，那就要让花出去的每分钱都尽量有效益，不管这个钱是开发者花还是用户花；如果付费不是问题，那你就怎么无敌怎么来。
2：对于楼上的『数据库设计』和楼上上上的『移植方便』，当软件的逻辑倚重数据库执行，所谓夸数据库的移植就必定不太平。因为一般稍微复杂的数据处理，程序员和官方文档中都推荐使用SQL来解决的，只要使用SQL就存在方言的问题，平台差异性的问题，这个和SQL是存在于stored procedure中还是app中都一样，需要修改SQL。
如果SQL存在app中，如果架构设计得当，在数据库变动时，仍然可使得客户端相关代码改动比较小，例如加一个数据访问层，不管这个访问层是service还是remote interface甚至只是代码接口，都可以。这种做法有利有弊。优势是，部署、升级、维护、版本管理都相对容易，对于目标数据库的权限及环境要求一般不复杂；缺点是，执行效率相对低，调试复杂，尤其是在线调试复杂。
如果SQL被实现在stored procedure中，诚然，如楼上所讲，在数据库变动时app代码改动较小，这是一个天然的优势，而且这样做SQL的执行效率也较高。但也要知道随之而来的缺点，就是数据库的安全设置会变得复杂，有时候很难解决，例如如果你要和一个重要的数据系统集成，人家不让你在目标数据库上安装任何函数和存储过程，只允许抽取数据呢，是不是有些麻烦。。。如果目标数据库有很多个呢。。。如果你的数据库做了拆分呢。。。另外，部署、升级、维护、版本管理都要针对每个数据库进行，要保持所有数据库的SP的版本都一致，当你的服务停机时间只能很短服务又很重要的时候，失败了又要安装回滚，是不是压力就很大？
kenlewis 2012-09-29
- 打赏
- 举报
的确，楼上考虑的很详细，也很周全了。佩服。
kenlewis 2012-09-28
- 打赏
- 举报
对于楼上的说法，我也解释一下：
1、第三方控件的使用，有人喜欢一个第三方的控件也不用，这样代码的可复制性比较好；另外有些人喜欢使用第三方控件，因为高效。这属于见仁见智的问题，有利有弊，根据自己的需要选择。
2、数据库的设计，建议把大部分的操作都放在数据库中，客户端只需要调用相应的存储过程或者函数即可。这样有很多优势，其中之一就是需要变更数据库平台时，客户端的改动最小；
3、至于UniDAC付费的问题，已经选用ORACLE数据库了，几十万都花出去了，就别在意一个控件了，是吧？又回到第一个问题了——根据自己的需要选择；
1、第三方控件的使用，有人喜欢一个第三方的控件也不用，这样代码的可复制性比较好；另外有些人喜欢使用第三方控件，因为高效。这属于见仁见智的问题，有利有弊，根据自己的需要选择。
2、数据库的设计，建议把大部分的操作都放在数据库中，客户端只需要调用相应的存储过程或者函数即可。这样有很多优势，其中之一就是需要变更数据库平台时，客户端的改动最小；
3、至于UniDAC付费的问题，已经选用ORACLE数据库了，几十万都花出去了，就别在意一个控件了，是吧？又回到第一个问题了——根据自己的需要选择；
biololo 2012-09-28
- 打赏
- 举报
[Quote=引用 7 楼 的回复:]
我给楼主提个建议吧，换ODAC或者UniDAC吧。
优点：
1、不需要装Oracle客户端，你单EXE程序即可连接ORACLE服务器；
2、速度快，比BDE的方式快很多，测试大数据量的时候就知道了；
3、移植方便。你通过ODAC或者UniDAC写的程序，尤其是UniDAC，将来如果移植到SQLSERVER或者MySQL或者其他数据库上，客户端代码不需要做修改。
[/Quote]
我不赞成楼上的建议
1：主要问题不是需要安装Oracle client，而是BDE依赖ODBC，所以如果是两层式结构的话，需要在客户端设置ODBC，如果只是简单替换其他连接方式，从架构和安全上来看，没有解决多大问题，如果替换为三层式结构的话，这些设置倒不是障碍。
2：UniDAC是要钱的。。。。
3：更换数据访问组件，如果原有架构设计不好，会导致大量控件、对象需要被替换，而且一些BDE组件是没有对应UniDAC的控件的，例如 BatchMove之类
4：如果只是需要快一些的话，ADO和dbExpress都很好用
5：我一直反对考虑夸数据库，因为随着功能的复杂，会逐渐依赖于某些特殊的数据库特性，尤其是在使用SQL的时候，各种数据库之间的实现差异会很大，设置不同版本的之间也有差异。如果要做跨数据库，可能大部分功能都是集中在数据的录入，简单的修改删除，和简单查询，稍微复杂的一些的查询修改功能，就搞不定了。
我给楼主提个建议吧，换ODAC或者UniDAC吧。
优点：
1、不需要装Oracle客户端，你单EXE程序即可连接ORACLE服务器；
2、速度快，比BDE的方式快很多，测试大数据量的时候就知道了；
3、移植方便。你通过ODAC或者UniDAC写的程序，尤其是UniDAC，将来如果移植到SQLSERVER或者MySQL或者其他数据库上，客户端代码不需要做修改。
[/Quote]
我不赞成楼上的建议
1：主要问题不是需要安装Oracle client，而是BDE依赖ODBC，所以如果是两层式结构的话，需要在客户端设置ODBC，如果只是简单替换其他连接方式，从架构和安全上来看，没有解决多大问题，如果替换为三层式结构的话，这些设置倒不是障碍。
2：UniDAC是要钱的。。。。
3：更换数据访问组件，如果原有架构设计不好，会导致大量控件、对象需要被替换，而且一些BDE组件是没有对应UniDAC的控件的，例如 BatchMove之类
4：如果只是需要快一些的话，ADO和dbExpress都很好用
5：我一直反对考虑夸数据库，因为随着功能的复杂，会逐渐依赖于某些特殊的数据库特性，尤其是在使用SQL的时候，各种数据库之间的实现差异会很大，设置不同版本的之间也有差异。如果要做跨数据库，可能大部分功能都是集中在数据的录入，简单的修改删除，和简单查询，稍微复杂的一些的查询修改功能，就搞不定了。
kenlewis 2012-09-28
- 打赏
- 举报
我给楼主提个建议吧，换ODAC或者UniDAC吧。
优点：
1、不需要装Oracle客户端，你单EXE程序即可连接ORACLE服务器；
2、速度快，比BDE的方式快很多，测试大数据量的时候就知道了；
3、移植方便。你通过ODAC或者UniDAC写的程序，尤其是UniDAC，将来如果移植到SQLSERVER或者MySQL或者其他数据库上，客户端代码不需要做修改。
优点：
1、不需要装Oracle客户端，你单EXE程序即可连接ORACLE服务器；
2、速度快，比BDE的方式快很多，测试大数据量的时候就知道了；
3、移植方便。你通过ODAC或者UniDAC写的程序，尤其是UniDAC，将来如果移植到SQLSERVER或者MySQL或者其他数据库上，客户端代码不需要做修改。
biololo 2012-09-28
- 打赏
- 举报
使用BDE连接Orale的步骤
1：首先安装Oracle Client，在安装的时候记得将管理工具选上，便于后期维护设置。
2：在Oracle client home目录下打开oracle network manager，新建服务命名。
按照步骤提示，设置好正确的网络服务命名，连接方式，主机地址，端口等等
以上是使用管理工具的配置过程，当然你也可以直接修改tnsnames.ora中的内容，因为UI上所有的设置都会被存入到该文件中，该文件的相关信息请参考Oracle帮助
3：设置ODBC。打开ODBC administrator，在User DSN或System DSN页中点击Add添加data source，注意在添加Data Source的时候选择Oracle驱动，不建议选择微软的ODBC for Oracle
在Oracle ODBC Driver Configuration中设置好你的Data Source Name，然后选择TNS Service Name（在下拉框中你可以找到刚才你设置的SN），随后设置好User ID（你需要登录Oracle的schema），其他保持默认即可。
4：打开BDE，New Database，database driver name选择 Oracle的ODBC驱动
5：点击 apply 按钮
6：选中新添加的节点，在configuration页中ODBC DSN的下拉框中选择刚才创建的名称
7：点击 apply 按钮，关闭BDE，并且如果有确认是否激活为默认的BDE文件时，选择是
1：首先安装Oracle Client，在安装的时候记得将管理工具选上，便于后期维护设置。
2：在Oracle client home目录下打开oracle network manager，新建服务命名。
按照步骤提示，设置好正确的网络服务命名，连接方式，主机地址，端口等等
以上是使用管理工具的配置过程，当然你也可以直接修改tnsnames.ora中的内容，因为UI上所有的设置都会被存入到该文件中，该文件的相关信息请参考Oracle帮助
3：设置ODBC。打开ODBC administrator，在User DSN或System DSN页中点击Add添加data source，注意在添加Data Source的时候选择Oracle驱动，不建议选择微软的ODBC for Oracle
在Oracle ODBC Driver Configuration中设置好你的Data Source Name，然后选择TNS Service Name（在下拉框中你可以找到刚才你设置的SN），随后设置好User ID（你需要登录Oracle的schema），其他保持默认即可。
4：打开BDE，New Database，database driver name选择 Oracle的ODBC驱动
5：点击 apply 按钮
6：选中新添加的节点，在configuration页中ODBC DSN的下拉框中选择刚才创建的名称
7：点击 apply 按钮，关闭BDE，并且如果有确认是否激活为默认的BDE文件时，选择是
biololo 2012-09-28
- 打赏
- 举报
楼上的，如果不知道如何做，请不要说『放弃』之类的话
xxzqbxxzqb 2012-09-24
- 打赏
- 举报
应该放弃这种方式了。
woniugongzuoshi 2012-09-22
- 打赏
- 举报
SERVER NAME那里应该输入服务器名或服务器IP地址
fox600123 2012-09-22
- 打赏
- 举报
没有tnsnames.ora是不可能连上ORACLE的（用第三方的某些控件例外），10G以上版本的tnsnames.ora位置已经移到类似这样的路径里了
F:\app\Administrator\product\11.2.0\dbhome_1\NETWORK\ADMIN
F:\app\Administrator\product\11.2.0\dbhome_1\NETWORK\ADMIN
我看见佛 2012-09-21
- 打赏
- 举报
又是BDE，BDE的连接方式据我所知道是过时了的。
