三层中新增数据,自增字段如何处理

hare007 2006-10-12 05:02:46
在三层中,自增字段(id),在新增完数据后,需要返回id,用delphi的数据感知控件,能实现吗?
...全文
1196 58 打赏 收藏 转发到动态 举报
写回复
用AI写文章
58 条回复
切换为时间正序
请发表友善的回复…
发表回复
ChangWeiTu 2006-12-08
  • 打赏
  • 举报
回复
强烈鄙视问题解决后不结贴的人!
强烈鄙视技术问题解决后把贴子转移到非技术区的人!
鄙视你们!

http://community.csdn.net/Expert/topic/5216/5216675.xml?temp=.9262659
cobi 2006-12-07
  • 打赏
  • 举报
回复
似乎这里好久没有这么热闹的帖子啦!凑个热闹

我是今年年初写三层服务器程序的时候发现不能用自增字段的(sorry,好久没动手了,有些东西都忘得差不多了)。当时我的做法就是一般的处理:cds-datasetprovider-adoquery,设置了datasetprovider的属性popropogateChanges为true,目的是服务器能够在完成更新后可以把id回传,结果运行出错,提示autoinc字段不能这样处理。上BDN查找了一下,也就是发现了http://bdn.borland.com/article/20847这个帖子,好像还有一个吧,按照里面的介绍修改了provider.pas的代码,也不通过。估计这个是delphi的bug吧~所以在设计上也就没有使用autoinc字段了~

至于大家这里争论的,我觉得有点抓不住关键吧~Cassava(车超)的回复是如何去获取一个可增的Id,但显然用存储过程获取的Id不是这个概念上的自增加id吧!自增加字段应该是新增记录保存后由数据库自行分配的一个值,这个值不用我们去关心。而我们用存储过程获得的id,则是我们可以使用规则定义并产生的一个字段值,所以我认为这里是两个不同的概念。

按照楼主的提法,他应该是希望使用一个id由数据库产生并回传。根据我自己的实验记录,不应该直接使用autoinc字段,自己定义一个字段(int或varchar的都可以),通过后台存储过程计算这个字段的值并在中间层进行赋值处理就可以了。ddqqyy(ddqqyy)的回复里面给出了完整的思路,BDN的例子也是这样处理的。

不过,ddqqyy(ddqqyy)的回复里最后用到了clientdataset.refresh,其实没有必要这样做。只要datasetprovider的属性popropogateChanges为true,后台所作的修改就会自动提交到客户端,注意,被提交数据中在中间层被修改了的才会回传,这样子网络的负荷会明显少很多。而refresh则是对clientdataset中的所有数据进行一次再查询,这个负荷会很大

这是我对三层里面使用自增字段的一些看法,请各位指教指教
madyak 2006-12-07
  • 打赏
  • 举报
回复
呵呵,很久不用DELPHI了,生怕再忘光了。当年这可是吃饭的家伙。
Northwindrocker 2006-12-07
  • 打赏
  • 举报
回复
但是我认为
********************************************
回复人:Cassava(车超) ( 五级(中级)) 信誉:100 2006-11-7 18:22:57 得分:0
?

如果主从表都是单一的数据,那么只需要调用存储就能实现了,
如:
CREATE PROCEDURE aaa
as
declare @AutoID int
inser into a(a)values('a')
set @AutoID=SCOPE_IDENTITY()
inser into b(AutoID,a)values(@AutoID,'b')

************************************************
这段代码是可取的,实际上是把数据库自动产生的ID让数据库自己去处理。并不需要回传到client端阿,这样的存储过程我也是写过的。不过我没做过三层,不敢说这个就一定适合三层。
Northwindrocker 2006-12-07
  • 打赏
  • 举报
回复
看了半天学习了很多,不过总结下来还是oracle简单,一个sequence解决这个问题,需要用自增用sequence产生,sequence的当前数可以查到。
dovelee 2006-12-07
  • 打赏
  • 举报
回复
好帖!很过瘾啊!
madyak 2006-11-09
  • 打赏
  • 举报
回复
请你不要误解,俺可没说你技术水平低,论坛里有很多高手是一个小角。
说我盛气凌人,我不并觉得。只是我说自增ID的负面作用的几个问题。只是有人闭着眼说,自增ID好,有多么多么好,而不正面回答问题。如果一个系统以自增ID结构为主,只那个存储过程,是远远不够的,必需有一个系统的针对那些问题的解决方案。

如果你坚持说这样很简单,没有增加工量作,我没话可说。

也许你是高手吧。希望你能在论坛上多解决些问题,不建议所有象你一样的高手在这里潜水或者太谦虚了。也许你很少在网上发表些见解,这个贴中算是难得一见了,从你的一个角上就能看出来。希望在这个主题里没有影响到你。

很久不用DELPHI了,但本人对DELPHI还是很有感情的,偶尔也来一下看看,增加些人气。
五维思考 2006-11-09
  • 打赏
  • 举报
回复
madyak(无天) :

1、“3150379,不知道你是谁的马甲”这是我唯一的号,请不要以小人之心度君子之腹。
2、“信誉度怎么这么低?”信誉度低怎么了,你挂着两个星觉得好看是你的事,信誉度低的技术上就不如你了吗,可笑。
3、“回答问题时,不见你的影子”一定要整天在这里回答问题的人才有权利在这里讨论吗?笑话。
4、“有人回答了,你来说风凉话。”争开你的眼睛仔细看看,哪一句是风凉话,你回答问题,我也回答问题,不同意你的观点就叫风凉话吗?

5、别总是说话盛气凌人的,你自己回头看看自己说的话,好象就你设计过三层结构,就你有经验,即使是这样,也应该谦虚一些吧,本人不才,N层结构也设计了一些,楼主这个问题我也曾经遇到过,但Cassava(车超)说的方法确实可行,我也没有说其他办法不行,只是说他的方法算是正解,你别总是网络流量网络流量的,就你知道广域网程序设计要考虑网络流量?别人都不知道?好象Cassava(车超)的方法就注定了要增加网络流量一样,可笑,只能说明你的设计思路太单一罢了。
madyak 2006-11-09
  • 打赏
  • 举报
回复
很久没这样争论过了。
只是觉得在三层用自增ID麻烦,尤其是牵涉到主从表。如果再是个新手,弄不好做出来的东西是三层外表,两层的骨头。如果想做好,就必需有专门处理ID主从绑定的代码,这样一弄明显增加了工作量。对老手还不要紧,但对新手来说,绑定这部分很难,至少我不愿意这么干,除非在特殊环境下,不得已而为之。
处理这些主从表同时增加,个为觉得核心代码和主要逻辑是如何绑定主从,且比较麻烦,尤其是一主对多从,或者主-半主-从串联起等。有人反对没什么,只是他们坚持自己的观点,但不拿出解决这些问题的办法。简单点就是有论点,没论据,吵了半天才说出来了一些。为了坚持用自增ID的可用性和不复杂性,却一字不提主从绑定的部分,这对新手来说是误导。
问题焦点不是能不能解决,而是解决起来很麻烦,如果提前主从关联外键就是已知了,这样明显减小了不小的工作量。
comanche 2006-11-09
  • 打赏
  • 举报
回复
不要火药味那么大嘛

认真看完了贴子内容后, 发现都是可以达成目标的, 不过偶本人是不支持Cassava(车超) 的作法, 过于浪费网络, 如果客户机在广域网上是非常慢的, 公文包模式现在基本上认为是必须的

楼主不见了呵, 看看楼主怎么说
madyak 2006-11-09
  • 打赏
  • 举报
回复
3150379(3150379)谦虚二次用得极为不当,如果在这里大家都谦虚的话,互相推让着答问题,或者知道也装着不知道,我看论坛就应该关闭了。

凡事没有绝对的,只是说一个比较实用的规则而已。看楼主问得问题,应该是对三层开发有很多细节上的东西不太了解。说这些只是提醒他注意,用自增ID后面可能会有很多的麻烦

3150379,不知道你是谁的马甲,信誉度怎么这么低?
回答问题时,不见你的影子,有人回答了,你来说风凉话。是不是建议大家都象你学习呢?
五维思考 2006-11-09
  • 打赏
  • 举报
回复
晕,还吵起来了啊?madyak(无天),别看你有两个星星,谦虚点好不,程序设计不是一成不变的,相同的功能实现方法很多,而这些实现方法的好坏标准也不一样,那要视功能细节要求而定,别总陷到自己的模式里。
楼主的提问非常简捷“在三层中,自增字段(id),在新增完数据后,需要返回id,用delphi的数据感知控件,能实现吗?”,有些文学功底的人都能够看出来他的困惑是不知道如何取得返回ID,你在这里吵什么,你说的那些如果说有道理的话,也仅限在你的思维模式下罢了。
你以为说一句“主从表”就表述很清楚了吗?给你举个例子吧,你的目的是从A城市到B城市,你跟我说说是坐“飞机、火车、汽车”这三种方式最先到达?AB距离、天气、路况、机场和车站远近等等你都不知道,你还吵着说坐XXX肯定快,简直笑话。
quicksand201 2006-11-08
  • 打赏
  • 举报
回复
就事论事,如果每次做主从关联都要先从数据库取唯一标识,这样网络的流量会很大
最好这个唯一标识由中间层管理,不过这样做工作量会大很多
Cassava 2006-11-07
  • 打赏
  • 举报
回复
如果是返回id到客户端,是不需要什么代码就可以实现了的啊
如果是同时提交是需要多写些代码,但这些代码也不是很复杂啊
主从表都是单一记录数据的,就更简单了啊
madyak 2006-11-07
  • 打赏
  • 举报
回复
你上面不是说,不需什么代码吗?早这样说不就结了,这就是你说的不需代码般的简捷吗?
Cassava 2006-11-07
  • 打赏
  • 举报
回复
如果主从表都是单一的数据,那么只需要调用存储就能实现了,
如:
CREATE PROCEDURE aaa
as
declare @AutoID int
inser into a(a)values('a')
set @AutoID=SCOPE_IDENTITY()
inser into b(AutoID,a)values(@AutoID,'b')
Cassava 2006-11-07
  • 打赏
  • 举报
回复
回传ID到客户端的当然是先添加主表记录,从表可以在客户端添加完了,再更新到数据库。

如果想主从表都在客户端添加完了,再一次性提交到服务器更新到数据库也是可以实现的
先输完主从表数据,然后写一个主从表更新的接口方法把数据传到服务器,然后服务器先调用存储过程先添加主表数据且
返回ID到服务端,然后再根据返回的主表关联ID再添加从表的数据进数据库
madyak 2006-11-07
  • 打赏
  • 举报
回复
呵呵,那你是不是在客户端每增加一条数据,就要提交一次数据呢?
如果你真这样做三层,我无话可说。
Cassava 2006-11-07
  • 打赏
  • 举报
回复
Cassava(车超) 我很纳闷,你做过三层没有?你返回到哪去,客户端还是服务端?
你是不是没做过三层呀?
觉得你没有客户端和服务端的概念
----------------------------------------
虽然水平没你高了,但请不要怀疑我没有做过三层啊

返回客户端
madyak 2006-11-07
  • 打赏
  • 举报
回复
Cassava(车超) 我很纳闷,你做过三层没有?你返回到哪去,客户端还是服务端?
加载更多回复(38)
数据集组件,大家也许会首选ADO,然后说BDE太老了,DBX不敢用。其实delphi优秀的数据集组件真不少,除了上诉的数据集组件,还有ZEOSDB、SQL Direct、UniDAC等,要是专业的数据集组件,更是百花盛开,如FIBPLUS、SDAC、ODAC、DOA等等,商业和开源不尽其!这里只讨论UniDAC和ADO的一些比较。 Delphi能发展到现在,和一些著名的第三方控件厂商大力支持分不开,这其包括Devart公司(Corelab)公司。Corelab公司做数据集驱动非常出名,就拿ODAC、SDAC和DBX驱动来说,已经远胜其他同行的第三方控件公司。UniDAC是Devart公司最近的力作,将ODAC、SDAC、IBDAC等驱动综合集成在一块。UniDAC无论是做三层还是两层,都远胜于ADO。下面说一些UniDAC的优点: 1、非常完美的支持多数据库的数据集套件。这一点,ADO也支持多数据库,但ADO除了MSSQL驱动之外,其他驱动支持的非常差。就拿Oracle驱动来说,在调用oracle复杂的存储过程参数,总是或多或少有些问题;MSSQL企业管理器如果用了第三方驱动(比如是oracle),在导入导出数据也尚存在问题!更别提不是主流的IB数据库驱动。UniDAC支持Oracle、MSSQL、MYSQL、IB/FB、PostgreSQL。 2、对三层特性支持非常好!也许你也会问,三层也是访问DB,ADO也支持啊?!但三层最好方式是无状态方式,在高并发的处理,一般不允许本地有数据集缓存。ADO没有单向数据集特性,所有的数据下载到本地,不停的开辟内存或释放大内存,对三层的内存是一个极大考验。TUniQuery有一个UniDirectional属性,支持单向速度,这点和DBX的想法不谋而合。况且,单向数据集特性速度非常快,在三层,配合TDataSetProvider,间件将其Data包发送到客户端,速度无可比拟。ADO也有流或XML格式包,但无论是XML或流格式,数据包远比CDS的包大几倍。CDS封包技术很好! 3、一些非常有用的属性或方法。常言道,细微之处见体贴。UniDAC有一些过人的方法或属性。比如,刷新单条记录(RefreshRecord)、多表更新的属性(UpdatingTable)、宏替换参数(Macros)、集成删除/新增/修改/刷新/锁定SQL语句、FetchRows,更让人称道的是引入了UpdateSQL组件。 在处理MSSQL新增后的自增字段,和ADO一样可以直接自动返回自增字段值,这一点,BDE不能做到、DBX不能做到、ZEOSDB不能做到。更令人称奇是,配合TUniUpdateSQL,还能自动返回自增字段值。 TUniUpdateSQL是一个好东西,ADO缺少TUdateSQL运作模式,默认的更新机制是主键字段+已变化的字段做where条件。在一般情况下是没问题,但如果这个表没有主键或where条件字段小数位很长导致误餐,就会产生更新找不到记录。TUdateSQL可以保证这点,运作灵活又透明。 4、对oracle支持非常好。别的不说,光是一个oracle连接的Direct Mode,不用安装oracle官方肥硕客户端(网上也有精10M左右简版的客户端),只要客户机支持TCP/IP协议即可。如果用ADO连接Oracle,必须保证先安装oracle客户端,还要配置连接文件,一堆繁琐事情。UniDAC对oracle支持的非常完美,和专业化的DOA差不多!
其实delphi优秀的数据集组件真不少,除了上诉的数据集组件,还有ZEOSDB、SQL Direct、UniDAC等,要是专业的数据集组件,更是百花盛开,如FIBPLUS、SDAC、ODAC、DOA等等,商业和开源不尽其!这里只讨论UniDAC和ADO的一些比较。 Delphi能发展到现在,和一些著名的第三方控件厂商大力支持分不开,这其包括Devart公司(Corelab)公司。Corelab公司做数据集驱动非常出名,就拿ODAC、SDAC和DBX驱动来说,已经远胜其他同行的第三方控件公司。UniDAC是Devart公司最近的力作,将ODAC、 SDAC、IBDAC等驱动综合集成在一块。UniDAC无论是做三层还是两层,都远胜于ADO。下面说一些UniDAC的优点: 1、非常完美的支持多数据库的数据集套件。这一点,ADO也支持多数据库,但ADO除了MSSQL驱动之外,其他驱动支持的非常差。就拿 Oracle驱动来说,在调用oracle复杂的存储过程参数,总是或多或少有些问题;MSSQL企业管理器如果用了第三方驱动(比如是oracle),在导入导出数据也尚存在问题!更别提不是主流的IB数据库驱动。UniDAC支持Oracle、MSSQL、MYSQL、IB/FB、 PostgreSQL。 2、对三层特性支持非常好!也许你也会问,三层也是访问DB,ADO也支持啊?!但三层最好方式是无状态方式,在高并发的处理,一般不允许本地有数据集缓存。ADO没有单向数据集特性,所有的数据下载到本地,不停的开辟内存或释放大内存,对三层的内存是一个极大考验。TUniQuery有一个 UniDirectional属性,支持单向速度,这点和DBX的想法不谋而合。况且,单向数据集特性速度非常快,在三层,配合 TDataSetProvider,间件将其Data包发送到客户端,速度无可比拟。ADO也有流或XML格式包,但无论是XML或流格式,数据包远比 CDS的包大几倍。CDS封包技术很好! 3、一些非常有用的属性或方法。常言道,细微之处见体贴。UniDAC有一些过人的方法或属性。比如,刷新单条记录(RefreshRecord)、多表更新的属性(UpdatingTable)、宏替换参数(Macros)、集成删除/新增/修改/刷新/锁定SQL 语句、FetchRows,更让人称道的是引入了UpdateSQL组件。 在处理MSSQL新增后的自增字段,和ADO一样可以直接自动返回自增字段值,这一点,BDE不能做到、DBX不能做到、ZEOSDB不能做到。更令人称奇是,配合TUniUpdateSQL,还能自动返回自增字段值。 TUniUpdateSQL是一个好东西,ADO缺少TUdateSQL运作模式,默认的更新机制是主键字段+已变化的字段做where条件。在一般情况下是没问题,但如果这个表没有主键或where条件字段小数位很长导致误餐,就会产生更新找不到记录。TUdateSQL可以保证这点,运作灵活又透明。 4、对oracle支持非常好。别的不说,光是一个oracle连接的Direct Mode,不用安装oracle官方肥硕客户端(网上也有精10M左右简版的客户端),只要客户机支持TCP/IP协议即可。如果用ADO连接 Oracle,必须保证先安装oracle客户端,还要配置连接文件,一堆繁琐事情。UniDAC对oracle支持的非常完美,和专业化的DOA差不多! 当然,最大的缺点是,非常贵,最贵的档次,差不多可以买半套的D2009!

1,593

社区成员

发帖
与我相关
我的任务
社区描述
Delphi 网络通信/分布式开发
社区管理员
  • 网络通信/分布式开发社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧