本地临时表

SQL SERVER的临时表有本地临时表和全局临时表之分,在联机丛书中这样描述:

  有本地和全局两种类型的临时表,二者在名称、可见性和可用性上均不相同。本地临时表的名称以单个数字符号 (#) 打头;它们仅对当前的用户连接是可见的;当用户从 Microsoft® SQL Server™ 2000 实例断开连接时被删除。全局临时表的名称以数学符号 (##) 打头,创建后对任何用户都是可见的,当所有引用该表的用户从 SQL Server 断开连接时被删除。

  笔者日前所在的项目中使用了本地临时表,笔者对此做了些探索。由于业务需要,用户需要非常复杂报表,需要从多个基础表中用非常复杂的逻辑选取出数据,使用单一的SQL逻辑不清晰,会给日后的维护工作带来困难,因此决定使用SQL SERVER提供的本地临时表。

  采用了以下方式:使用DLEPHI+ADO 直接连接数据库,调用存储过程,在存储过程中创建临时表,然后按用户要求的逻辑抓取基础数据写入到临时表中,最后返回临时表中的数据集。

  程序写完后,功能都可以实现,并且结果也没有错误,但是笔者产生了怀疑,联机丛书中说本地临时表对当前的用户连接是可见的,但是,笔者的程序是公用一个ADO连接,然后再调用存储过程,在存储过程中创建了临时表,这样说来,这个临时表是不是在这个连接中全部可见呢?那第二次打开同一报表,调用同一存储过程的时候是不是会出错,或者第二次写入的数据与第一次写入的数据混杂在一起呢?于是,笔者开始了实验,在程序中反复调用同一存储过程,结果发现并没有问题,既没有报错也没有出现数据混杂的情况,笔者开始疑惑了,难道是联机丛书写错了?然后笔者开始猜想,难得在同一连接中如果反复创建同名的临时表,系统会自动重建,于是笔者又做了试验,在查询分析器中,反复创建同名的本地临时表,发现系统会报错,从而否定了笔者的猜想。接着,笔者又进行了试验,在DELPHI程序中,在一个按钮事件中使用CREATE TABLE语句,创建了本地临时表,在另一个按钮事件中调用一个存储过程,向这个本地临时表插入数据,再返回数据集,结果发现能够成功,而同时在查询分析器中调用这个存储过程就会报没有这个数据表,这就证明了联机丛书的描述是对的,确实是当前连接的用户可见。而后,修改了试验程序,将CREATE TABLE的语句写入到存储过程中,在前台程序的一个按钮事件中先调用该存储过程创建临时表,然后在另一个按钮事件中向这个临时表插入数据并查询,结果在执行第二个按钮事件时系统报错了,说找不到这个数据表,这样看来,存储过程中创建的本地临时表在前台程序中是访问不到的。

  从这些试验中,笔者得出这样的结论,在存储过程中创建的本地临时表,相当于存储过程的变量,只在存储过程内可见,而在前台程序中创建的本地临时表,就和微软联机丛书中所写的一样,是对当前的用户连接可见。了解了这些,可以在不同场合不同需求下使用不同的方法来创建本地临时表,这样,会使临时表发挥它最大的用处。

  以上在实际中的点滴经验,和各位分享,希望能为各位的工作学习提供一点点帮助,另外,不对之处恳请大家指正 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值