SQL “无效的对象名称：dbo.etc”错误的根本原因？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3967800/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Root cause of an "Invalid object name: dbo.etc" error?
提问by Frosty840
I'm doing some maintenance programming on a fairly large project, which was started by someone who's now left the company...
我正在为一个相当大的项目做一些维护编程，这个项目是由现在离开公司的人开始的......
I've just backed up one of the company's databases, and then reattached it to our test server. That much appears to be working okay.
我刚刚备份了公司的一个数据库，然后将其重新附加到我们的测试服务器。这似乎工作正常。
I then go through the program's usual login procedure, and that part also appears to work.
然后我完成程序的通常登录程序，该部分似乎也可以工作。
However, once I get to a point in the program where it needs to execute a stored procedure, I get back an error telling me Invalid object name 'Informix.dbo.customer'.
但是，一旦我到达程序中需要执行存储过程的地方，我就会收到一个错误消息，告诉我Invalid object name 'Informix.dbo.customer'.
Running the same function on the original database works fine, and returns the data I expect to see.
在原始数据库上运行相同的函数工作正常，并返回我希望看到的数据。
Explanations for similar errors I've found seem to refer to Schemas, but that's where things get a little odd. The original database doesn't obviously haveany Schemas; In its "Security" folder it just has a "Users" folder, containing dbo, and a "Roles" folder, containing the "Database Roles" folder, with the usual db_owner, etc. stuff, and an empty folder named "Application Roles".
我发现的类似错误的解释似乎是指架构，但这就是事情变得有点奇怪的地方。原始数据库显然没有任何模式；在其“Security”文件夹中，它只有一个“Users”文件夹，其中包含 dbo 和一个“Roles”文件夹，其中包含“Database Roles”文件夹，以及通常的 db_owner 等内容，以及一个名为“Application Roles”的空文件夹”。
The Security folder on the backed-up-and-restored database is full of all kinds of crap. Three users in addition to dbo, a "Schemas" folder, "Certificates" folder, two encryption key folders... I can't delete any of these.
备份和恢复数据库上的安全文件夹充满了各种垃圾。除了 dbo 之外的三个用户，一个“Schemas”文件夹，“Certificates”文件夹，两个加密密钥文件夹......我无法删除任何这些。
From my limited understanding of the SQL login system, the user I'm logging in as is getting non-dbo-permissions from this collection of random crap, and so is being denied access to the parts of the database owned by dbo.
根据我对 SQL 登录系统的有限了解，我登录的用户从这个随机垃圾集合中获得了非 dbo 权限，因此被拒绝访问 dbo 拥有的数据库部分。
For my own understanding, what is the core of the problem that's throwing up these Invalid object nameerrors? And for practical matters, what can I do to rectify this situation and actually have the program I'm using work on the test database in the same way as it does on the live one?
就我自己的理解而言，抛出这些Invalid object name错误的问题的核心是什么？对于实际问题，我可以做些什么来纠正这种情况，并使我正在使用的程序以与在实时数据库上相同的方式在测试数据库上工作？
采纳答案by Pondlife
If I understand correctly, you're executing a procedure (SomeProc) in a database (SomeDB) and it's giving the error Invalid object name 'Informix.dbo.customer'? That simply means that SomeProc cannot find an object called "customer" in a schema called "dbo" in a database called "Informix". There are several possible reasons for this:
如果我理解正确，您正在数据库 (SomeDB) 中执行一个过程 (SomeProc) 并且它给出了错误Invalid object name 'Informix.dbo.customer'？这只是意味着 SomeProc 无法在名为“Informix”的数据库中名为“dbo”的模式中找到名为“customer”的对象。这有几个可能的原因：
- The object doesn't exist, possibly because the schema and/or database don't exist
- The object exists, but the user running the procedure doesn't have permission to even see it
- The object exists, but the database is case-sensitive and some part of the name doesn't match the name in your code
- 对象不存在，可能是因为架构和/或数据库不存在
- 该对象存在，但运行该过程的用户甚至无权查看它
- 对象存在，但数据库区分大小写，并且名称的某些部分与代码中的名称不匹配
You'll need to investigate more to find out what the cause is in your case, but as a complete guess, your production server has both the Informix and SomeDB databases, but your test server has only SomeDB?
您需要进行更多调查以找出您的情况的原因，但作为一个完整的猜测，您的生产服务器同时具有 Informix 和 SomeDB 数据库，但您的测试服务器只有 SomeDB？
Finally, when posting questions please always include your SQL Server version (2000/2005/2008) and edition (Express, Standard, Enterprise); they can be very important when talking about schemas and permissions, because features and behaviour can be different.
最后，在发布问题时，请始终包括您的 SQL Server 版本（2000/2005/2008）和版本（Express、Standard、Enterprise）；在谈论架构和权限时，它们可能非常重要，因为功能和行为可能不同。
回答by Mark PM
It might be an issue with the owner of the object (SP in your case). Check the owner in SQL management studio
这可能是对象所有者的问题（在您的情况下为 SP）。在 SQL 管理工作室检查所有者
