ASP.NET 4.6 WebForms应用#临时表跨页面失效问题及替代方案咨询

咱们遇到的问题 #

最近在做基于SQL Server的ASP.NET 4.6 WebForms项目时踩了个实打实的坑：

• 在Page1里用SQL Server创建了#本地临时表，跳转至Page2后
• 原本想把这个临时表的数据绑定到GridView做编辑操作，结果发现本地临时表的作用域根本跨不过页面请求
• 一开始考虑换成普通数据库表，但又怕多用户同时操作时互相干扰——毕竟之前误以为#临时表是专属当前浏览器用户的，不会出现数据串用的情况

为啥本地临时表不行？ #

先把SQL Server临时表的本质说透：

• #开头的本地临时表，仅在创建它的数据库连接会话内有效。而ASP.NET WebForms中，每个页面请求都是独立的数据库连接（除非硬维持长连接，这绝对是不推荐的操作），所以Page1的请求结束后，对应的数据库连接关闭，临时表会被SQL Server自动销毁，Page2的新连接自然看不到它
• 别想着用##全局临时表救场，那是所有用户共享的，只会让数据混乱更严重，完全不适合多用户并行操作的场景

最终解决方案（感谢@Faruq的建议） #

我们最终采用了为每个用户单独使用普通数据库表的方案，具体操作可以参考这几步：

1. 给普通表新增一个用户标识字段，比如UserId——可以用ASP.NET自带的User.Identity.Name，或者Session.SessionID这种会话唯一标识
2. Page1插入数据时，将当前用户的标识和业务数据一起存入表中
3. Page2查询数据时，只过滤当前用户标识对应的内容，彻底避免多用户数据串用的问题
4. 别忘了清理旧数据：比如在用户会话过期时触发删除，或者用SQL Server定时作业清理超过一定时长的用户数据，防止表体积过度膨胀

额外小提示 #

• 如果数据量不大，也可以考虑把数据存在ASP.NET的Session里，但要是数据量较大，会占用服务器内存，还是存在数据库里更稳妥
• 别折腾所谓的“会话级临时表”了，本质还是绕不开连接生命周期的问题，普通表加用户标识是最靠谱的方案

内容的提问来源于stack exchange，提问作者John D