I have a database where the original person that set it up, somehow created the tables within the DB to prefix with a name instead of the usual "dbo".
For example: [test_data].[test_data].field1
Instead of the usual: [test_data].[dbo].field1
Note the DBname is actually in twice if you follow the usual entry. I'm comparing this to all my other databases that follow the usual convention of DBname.dbo.fieldname.
This became a problem when the main system this was installed on failed, and I've had to restore it to a new system using the backups from SQL. The .NET code is still the same as original.
I'm having issues gaining access to the DB thru a .NET app, and in the process I discovered this prefix change was done. Data is perfectly fine when using SQL itself.
I was getting an ambigious error message about a missing table, but in working thru the error code generated, it's actually complaining that it can't access ANY tables because they're reported as invalid objects -- don't exist or corrupt. Of course they don't exist! If you try to open a table with just the table name itself, it assumes (essentialy) "dbo", not a foreign name.
I took the particular error test code and ran it in SQL directly, and this is how I got to the prefix issue. Change the prefix to use what's ACTUALLY in the DB instead of it "assuming" the dbo, and it works properly.
It's way too big of an app to change the code, and I've not found anything in the code itself that places this prefix as a value to make use of it, so it seems to me that the change has to be made in the DB itself....
Is there a programatic way to change it back? Can't change it at the table levels using SSMS as that prefix "hides" itself, so I figure it's stored elsewhere.
Where is this non-standard entry actually being stored, and is it something I can actually change?