听起来你碰到了一个很典型的配置缓存/残留问题——明明手动删掉了ODBC数据源，代码里还挂着旧连接名，网站居然照样跑，改个名字直接崩，连重启都不管用。我结合之前踩过的坑，给你梳理几个大概率的原因和排查步骤：

1. 你删的可能不是代码实际用的DSN类型 #

你在ODBC管理器里删除的大概率是系统/用户DSN，但代码里调用的可能是文件DSN（后缀为.dsn的本地文件）。这种DSN不会显示在ODBC管理器的默认列表里，除非你手动导入。

• 排查方法：在服务器上搜索.dsn文件，常见路径是C:\Program Files\Common Files\ODBC\Data Sources或者网站根目录附近，看看有没有和代码里连接名同名的文件。
• 解决：找到后直接删除该文件，再重启网站测试。

2. IIS应用程序池进程没彻底被杀掉 #

有时候重启IIS甚至服务器，都可能没彻底终止对应网站的应用程序池进程，导致旧的ODBC连接信息还驻留在内存里。

• 手动杀进程：打开任务管理器，找到w3wp.exe进程（对应你的网站应用程序池），右键强制结束任务，再重新启动应用程序池。
• 命令行快捷操作：执行 taskkill /f /im w3wp.exe 强制杀掉所有IIS工作进程，再运行 iisreset 重启IIS服务。

3. 代码里的“连接名”其实是硬编码的连接字符串 #

有些时候代码里写的“连接名”只是个幌子，实际是完整的ODBC连接字符串硬编码在配置文件里，根本没用到你删的那个DSN。

• 检查配置文件：比如ASP.NET的web.config，或者其他应用的配置文件，看看<connectionStrings>节点里的内容——如果是类似 Driver={SQL Server};Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx; 的格式，那这完全不需要依赖DSN，你删不删DSN都不影响，改了名字自然就找不到数据库了。

4. 注册表残留了ODBC配置信息 #

ODBC的配置会存在注册表中，有时候删除DSN后，注册表的残留项还会让系统“误以为”连接还存在。

• 打开注册表编辑器（regedit.exe），导航到对应路径删除残留项：
  • 系统DSN残留：HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\[你的连接名] 和 HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources 下的对应条目
  • 用户DSN残留：HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\[你的连接名] 和 HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\ODBC Data Sources 下的对应条目
• 删除后重启IIS或服务器再测试。

5. 网站用的是32位ODBC，你只删了64位的 #

Windows 7上IIS默认是64位模式，但如果你的网站是32位应用（比如旧ASP程序），它会调用32位的ODBC数据源管理器，而你可能只在64位管理器里删了连接。

• 打开32位ODBC管理器：运行 C:\Windows\SysWOW64\odbcad32.exe，看看里面是不是还留着你删除的连接名，有的话直接删掉即可。

我之前碰到过一模一样的情况——用户删了64位DSN，但网站是32位的，32位ODBC里还躺着那个连接，导致一直能正常访问。按上面的步骤逐一排查，应该能找到问题根源。

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