SQL SERVER的临时表有本地临时表和全局临时表之分，在联机丛书中这样描述：
有本地和全局两种类型的临时表，二者在名称、可见性和可用性上均不相同。本地临时表的名称以单个数字符号 (#) 打头；它们仅对当前的用户连接是可见的；当用户从 Microsoft® SQL Server™ 2000 实例断开连接时被删除。全局临时表的名称以数学符号 (##) 打头，创建后对任何用户都是可见的，当所有引用该表的用户从 SQL Server 断开连接时被删除。
笔者日前所在的项目中使用了本地临时表，笔者对此做了些探索。由于业务需要，用户需要非常复杂报表，需要从多个基础表中用非常复杂的逻辑选取出数据，使用单一的SQL逻辑不清晰，会给日后的维护工作带来困难，因此决定使用SQL SERVER提供的本地临时表。
采用了以下方式：使用DLEPHI＋ADO 直接连接数据库，调用存储过程，在存储过程中创建临时表，然后按用户要求的逻辑抓取基础数据写入到临时表中，最后返回临时表中的数据集。
程序写完后，功能都可以实现，并且结果也没有错误，但是笔者产生了怀疑，联机丛书中说本地临时表对当前的用户连接是可见的，但是，笔者的程序是公用一个ADO连接，然后再调用存储过程，在存储过程中创建了临时表，这样说来，这个临时表是不是在这个连接中全部可见呢？那第二次打开同一报表，调用同一存储过程的时候是不是会出错，或者第二次写入的数据与第一次写入的数据混杂在一起呢？于是，笔者开始了实验，在程序中反复调用同一存储过程，结果发现并没有问题，既没有报错也没有出现数据混杂的情况，笔者开始疑惑了，难道是联机丛书写错了？然后笔者开始猜想，难得在同一连接中如果反复创建同名的临时表，系统会自动重建，于是笔者又做了试验，在查询分析器中，反复创建同名的本地临时表，发现系统会报错，从而否定了笔者的猜想。接着，笔者又进行了试验，在DELPHI程序中，在一个按钮事件中使用CREATE TABLE语句，创建了本地临时表，在另一个按钮事件中调用一个存储过程，向这个本地临时表插入数据，再返回数据集，结果发现能够成功，而同时在查询分析器中调用这个存储过程就会报没有这个数据表，这就证明了联机丛书的描述是对的，确实是当前连接的用户可见。而后，修改了试验程序，将CREATE TABLE的语句写入到存储过程中，在前台程序的一个按钮事件中先调用该存储过程创建临时表，然后在另一个按钮事件中向这个临时表插入数据并查询，结果在执行第二个按钮事件时系统报错了，说找不到这个数据表，这样看来，存储过程中创建的本地临时表在前台程序中是访问不到的。
从这些试验中，笔者得出这样的结论，在存储过程中创建的本地临时表，相当于存储过程的变量，只在存储过程内可见，而在前台程序中创建的本地临时表，就和微软联机丛书中所写的一样，是对当前的用户连接可见。了解了这些，可以在不同场合不同需求下使用不同的方法来创建本地临时表，这样，会使临时表发挥它最大的用处。
以上在实际中的点滴经验，和各位分享，希望能为各位的工作学习提供一点点帮助，另外，不对之处恳请大家指正！
