This problem has appeared on my PC a few days ago, without any changes I have made to the Visual Studio/SQL Server settings.
When trying to perform any manual operation on the database file (*.mdf) in Visual Studio, I get the following error:
The specified procedure could not be found. (Exception from HRESULT: 0x8007007F)
(For example, when trying to create a new table, or when showing an existing table's data)
How I can fix this error?
Be sure you or someone else has not changed your rights on master. In order to add anything a record is added to that table.
Addendum:
You can run the following script to determine who has what permissions and whether they are implicit or explicit.
WITH perms_cte as
(
select USER_NAME(p.grantee_principal_id) AS principal_name,
dp.principal_id,
dp.type_desc AS principal_type_desc,
p.class_desc,
OBJECT_NAME(p.major_id) AS object_name,
p.permission_name,
p.state_desc AS permission_state_desc
from sys.database_permissions p
inner JOIN sys.database_principals dp
on p.grantee_principal_id = dp.principal_id
)
--users
SELECT p.principal_name, p.principal_type_desc, p.class_desc, p.[object_name], p.permission_name, p.permission_state_desc, cast(NULL as sysname) as role_name
FROM perms_cte p
WHERE principal_type_desc <> 'DATABASE_ROLE'
UNION
--role members
SELECT rm.member_principal_name, rm.principal_type_desc, p.class_desc, p.object_name, p.permission_name, p.permission_state_desc,rm.role_name
FROM perms_cte p
right outer JOIN (
select role_principal_id, dp.type_desc as principal_type_desc, member_principal_id,user_name(member_principal_id) as member_principal_name,user_name(role_principal_id) as role_name--,*
from sys.database_role_members rm
INNER JOIN sys.database_principals dp
ON rm.member_principal_id = dp.principal_id
) rm
ON rm.role_principal_id = p.principal_id
order by 1
--- thanks to Jamie Thomson for this ditty
A more few suggestions;
Trace the call using profiler and confirm you are connecting as the user you think you are - sp_who2 might be another way to verify that.
Verify your process is in the correct database. Use the c# connection and run SELECT DB_NAME() - write the result somewhere you can read to confirm.
If this works from one environment but not another I would strongly suspect the connection string.
Check that you do not have authentication errors reported in your SQL logs. These again would indicate possible connection issues.
The conventional wisdom on this error is that it likely reflects a lost or corrupted DLL (in either SQL Server or Visual Studio). And the SOP is to reinstall, though it seems that that does not always work either.
Try to run Visual Studio as administrator
Right click Visual Studio --> Run as Administrator.
Try to connect to the database in SQL Server Management Studio. That'll at least narrow down whether it's a database permission issue or something else. Also, check to confirm that the database exists and you have permission to access it. (Like Joe suggested.)
Assuming that checks out... My googling found a guy with a very similar sounding problem. He said that the runas administrator thing Adel suggested worked for him, but there were other issues that could also cause the error message, including VS not being able to find the IIS virtual server specified in the Web Application Project file (permissions? renamed?). Confirm that the file exists and you have permission to access it.
http://connect.microsoft.com/VisualStudio/feedback/details/317124/system-runtime-interopservices-comexception-in-webapplication-project
Related
Database names and logins are anonymized in what follows. There are some answers
on SO that are similar to this situation, but not exactly the same, hence my question.
Attempting to deploy an assembly to production database FOO_PROD fails with message:
Msg 33009, Level 16, State 2, Line 17
The database owner SID recorded in the master database differs from the
database owner SID recorded in database 'FOO_PROD'. You should correct
this situation by resetting the owner of database 'FOO_PROD' using the
ALTER AUTHORIZATION statement.
Indeed, the following two queries demonstrate the difference in SID.
First, we look at the SID of FOO_PROD:
SELECT SD.[SID],
SL.Name as [LoginName]
FROM master..sysdatabases SD INNER JOIN master..syslogins SL
on SD.SID = SL.SID
WHERE SD.Name = 'FOO_PROD'
which shows the result of:
SID, LoginName
0x010500000000000515000000C4B7E63D99D15C20332A47A24B100000, BATZ\boink
Second, we look at the SID of FOO_PROD in the master database:
SELECT SD.[SID],
SL.Name as [LoginName]
FROM master..sysdatabases SD INNER JOIN master..syslogins SL
on SD.SID = SL.SID
WHERE SD.Name = 'master'
which shows the result of:
SID, LoginName
0x01, [sa]
We notice that indeed, just as Visual Studio complained, the SIDs do not
match. They must be made to match in order to proceed (apparently).
Constraints: The SID on FOO_PROD cannot be changed because several other systems
that use the database expect it to have the SID and LoginName it currently has.
Question 1: Is the solution then to change the SID, LoginName on the master database? Would
it hurt anything or be a bad idea to do so?
Say you respond that it is ok to change the SID, LoginName on master, then,
how does one make the change to the 'master' database? Well, I've
not done it before, but candidate solutions and commentary can be found here:
The database owner SID recorded in the master database differs from the database owner SID
However, this situation is different from those presented in the link above, I
think, in that the change must happen to/on the master database ala:
exec sp_changedbowner [BATZ\boink]
Question 2: Is that the correct way to do it?
Naturally I'll check with stakeholders if such a change to master database will
cause undesired outcomes, but I hope to get some guidance here before I even
check on that.
Update based on #srutzky's updated answer:
-- Step 1
SELECT sd.[name], sd.[owner_sid], sp.[name]
FROM sys.databases sd
INNER JOIN sys.server_principals sp
ON sp.[sid] = sd.[owner_sid]
WHERE sd.[name] = N'FOO_PROD';
returns:
name, owner_sid, name
FOO_PROD, 0x010500000000000515000000C4B7E63D99D15C20332A47A24B100000, BATZ\boink
Then
-- Step 2
USE [FOO_PROD];
SELECT dp.[sid], sp.[name]
FROM sys.database_principals dp
INNER JOIN sys.server_principals sp
ON sp.[sid] = dp.[sid]
WHERE dp.[name] = N'dbo';
returns:
sid, name
0x01, sa
Yes, the SIDs really do need to match as a mismatch is an indication of a potentially harmful DB being restored to the instance; this is a safe-guard.
BUT, first we need to know exactly what we are looking at. While there is definitely a mismatch in the owner SIDs between the record in FOO_PROD and the record in master (hence the error message), your queries are not looking at the value in FOO_PROD. Your two queries are looking at the value in master for the owner of FOO_PROD, and in master (again) for the owner of master (entirely irrelevant here), respectively.
Step 1
Do not use sys* objects for anything as those are compatibility Views so that older stuff written for SQL Server 2000 and prior still work (well, dbo.sys* tables in msdb are still valid). Starting with SQL Server 2005, only sys.* objects (no need to specify master.) should be used. Meaning, use:
SELECT sd.[name], sd.[owner_sid], sp.[name]
FROM sys.databases sd
INNER JOIN sys.server_principals sp
ON sp.[sid] = sd.[owner_sid]
WHERE sd.[name] = N'FOO_PROD';
Step 2
You need to check the value IN the database itself for the owner's SID as it has it recorded, which is not in sys.databases (or even in master..sysdatabases). When checking the Database's value for it's owner, you need to look in sys.database_principals for the dbo User as follows:
USE [FOO_PROD];
SELECT dp.[sid], sp.[name]
FROM sys.database_principals dp
INNER JOIN sys.server_principals sp
ON sp.[sid] = dp.[sid]
WHERE dp.[name] = N'dbo';
Step 3
Using sp_changedbowner is required if you are on SQL Server 2005, but starting with SQL Server 2008 that stored procedure is deprecated in favor of the newer ALTER AUTHORIZATION (though it still works). But yes, this is the way to make them the same as it will sync both locations to whichever Login you specify.
However, you need to make sure that BATZ\boink is a valid Windows Login for the domain that the SQL Server instance belongs to, AND that this particular Windows Login has an SID of 0x010500000000000515000000C4B7E63D99D15C20332A47A24B100000. If the Login does not exist, hopefully you will be able to create it via CREATE LOGIN.
Since the owner in the database is SA, and you want to change the owner recorded in Master to SA, just run
alter authorization on database::[foo_prod] to sa
I am trying to understand the linked-servers in SQL Server Studio 2012 that I am using to develop a big report. I have looked through some of the post but I didn't see anything related to permission or how to do it with non-default instance servers that we have. My first question is: can I use create linked-server querying when I only have read permission? Second: I would appreciate if someone can elaborate more on the syntax. Below is the syntax that I am having problem with. Our server name is not just the server name but it has servername\databasename due to IT's reason for a non-default instance (this is what our IT department told me).
SELECT *
FROM [server1\databse1 name].[dbo].[table name]. tab1
INNER JOIN [server2\database2 name].[dbo].[table name] tab2
ON tab1.ID = tab2.ID`
Thank you so much.
can I use create linked-server querying when I only have read permission?
Answer: No you will need sysadmin permissions to add a linked server. If you only have read permissions on the server you will need to ask your DBA to do it for you.
I would appreciate if someone can elaborate more on the syntax. Below is the syntax that I am having problem.....
Your syntax will be something like this...
Assuming databse1Name is located on the Linked server and database2Name is on the server where you are logged on.
SELECT * FROM
[ServerName].[databse1Name].[dbo].[table name]. tab1
INNER JOIN [database2Name].[dbo].[table name] tab2
ON tab1.ID = tab2.ID
If it is a specific Instance on the linked server then you would write your query something like...
SELECT * FROM
[ServerName\InstanceName].[databse1Name].[dbo].[table name]. tab1
INNER JOIN [database2Name].[dbo].[table name] tab2
ON tab1.ID = tab2.ID
Today I was trying to restore a database over an already existing database, I simply right clicked the database in SSMS --> Tasks --> Take Offline so I could restore the database.
A small pop up window appeared and showed Query Executing..... for sometime and then threw an error saying Database is in use cannot take it offline. From which I gathered there are some active connections to that database so I tried to execute the following query
USE master
GO
ALTER DATABASE My_DatabaseName
SET OFFLINE WITH ROLLBACK IMMEDIATE
GO
Again at this point the SSMS showed Query Executing..... for a sometime and then threw the following error:
Msg 5061, Level 16, State 1, Line 1
ALTER DATABASE failed because a lock could not be placed on database 'My_DatabaseName'. Try again later.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
After this I could not connect to the database through SSMS. and when I tried to Take it offline using SSMS it threw an error saying:
Database is in Transition. Try later .....
At this point I simply could'nt touch the database anything I tried it returned the same error message Database is in Transition.
I got on google read some questions where people had faced similar issue and they recommended to close the SSMS and open it again, So did I and
Since it was only a dev server I just deleted the database using SSMS and restored on a new database.
My question is what could have possibly caused this ?? and how I can Avoid this to happen in future and if I ever end up in the same situation in future is there any other way of fixing it other then deleting the whole database ???
Thank you
Check this out. This will help you release locks. Works great! https://dba.stackexchange.com/questions/57432/database-is-in-transition-error
use this
select
l.resource_type,
l.request_mode,
l.request_status,
l.request_session_id,
r.command,
r.status,
r.blocking_session_id,
r.wait_type,
r.wait_time,
r.wait_resource,
request_sql_text = st.text,
s.program_name,
most_recent_sql_text = stc.text
from sys.dm_tran_locks l
left join sys.dm_exec_requests r
on l.request_session_id = r.session_id
left join sys.dm_exec_sessions s
on l.request_session_id = s.session_id
left join sys.dm_exec_connections c
on s.session_id = c.session_id
outer apply sys.dm_exec_sql_text(r.sql_handle) st
outer apply sys.dm_exec_sql_text(c.most_recent_sql_handle) stc
where l.resource_database_id = db_id('<YourDatabase>')
order by request_session_id;
and then
for each processnumber
kill <processnumber>
Check out this article.
http://oostdam.info/index.php/sectie-blog/289-sql-error-952-8ways-to-solve-it
I use TSQL most of the time, so I have not run into this issue yet.
What version is the SQL Server database and at what patch level?
Next time, do a usp_who2 to see what threads are running.
http://craftydba.com/wp-content/uploads/2011/09/usp-who2.txt
Since the output is in a table, you can search by database.
Kill all threads using the database before the trying the ALTER statement.
A night about 6 months ago, I had a terrible time getting a 2000 database offline due to an application constantly hitting it. I eventually disabled the user account so I would not get any more logins.
I just deployed a new stored proc to our test environment only to have it fail upon execution due to the fact the test system didn't contain a table that the stored proc relied upon. I believe this is due to deferred name resolution.
The thing is, I feel that at times in the past, I have attempted to create stored procs that failed due to missing dependencies. I could be wrong though.
Anyway, is it possible to somehow enforce name resolution during creation of a stored proc? If so, is there any way to get this working with sqlcmd as well as SSMS?
This way we could find out about missing dependencies upon the rollout of scripts rather upon their first execution.
On a side note, I was interested to read about this apparent deviation from the MSDN doco regarding how deferred resolution works.
Edit: We have a mix of 2005/2008 (out of my control), so I'd need a 2005 solution to work on both instances.
You could investigate WITH SCHEMABINDING though that may not work for you for the reasons indicated in the comments to the connect item linked to by Damien.
If on SQL Server 2008 you could also look at sys.sql_expression_dependencies
CREATE PROC bar
AS
SELECT *
FROM DoesNotExist
JOIN AlsoDoesNotExist ON 1=1
GO
CREATE TABLE DoesNotExist
(
X INT
)
GO
SELECT OBJECT_NAME(referencing_id) AS referencing_entity_name,
referenced_entity_name
FROM sys.sql_expression_dependencies
WHERE referenced_id IS NULL
Returns
referencing_entity_name referenced_entity_name
------------------------------ ------------------------------
bar AlsoDoesNotExist
How could I know the physical location (so I can see it in Windows Explorer) path of a FILESTREAM data that I've just inserted into DB?
There is one option for this: method PhysicalPathName(). If you are on SQL Server 2012 or upper now, this code will work for you:
SELECT stream.PhysicalPathName() AS 'Path' FROM Media
OPTION (QUERYTRACEON 5556)
For SQL Server 2008/2008 R2 you will need to enable trace flag 5556 for the whole instance:
DBCC TRACEON (5556, -1)
GO
or for the particular connection in which you are calling PhysicalPathName() method:
DBCC TRACEON (5556, -1)
GO
I know this is an older post but as it still comes up high in the Google search rankings I thought I'd post an answer. Certainly in later versions of SQL (I've not tried this on 2008) you can run the following query:
SELECT t.name AS 'table',
c.name AS 'column',
fg.name AS 'filegroup_name',
dbf.type_desc AS 'type_description',
dbf.physical_name AS 'physical_location'
FROM sys.filegroups fg
INNER JOIN sys.database_files dbf
ON fg.data_space_id = dbf.data_space_id
INNER JOIN sys.tables t
ON fg.data_space_id = t.filestream_data_space_id
INNER JOIN sys.columns c
ON t.object_id = c.object_id
AND c.is_filestream = 1
Source
As Pawel has mentioned, it is not a good idea to access the FILESTREAM files using Windows Explorer. If you are still determined to go ahead and explore this, the following tip might help.
The FILESTREAM file names are actually the log-sequence number from the database transaction log at the time the files were created. Paul Randal has explained it in this post. So One option is to find out the log sequence number and look for a file named after that in the file stream data container.
First you need to understand that the FileStream is being stored on the server hosting your SQL Server 2008 database. If you have a DBA, ask them where they created it the FileStream at. Of course, you'll then need rights to the server to navigate it to see the directories. You won't be able to manipulate the files in any way either, but you will be able to see them. Most DBA's won't be keen on letting you know where the FileStream is located at.
However, you can get at the path by a few other means. One way that comes to mind is by selecting upon the PathName() of the FileStream field. Assume that the FileStream enabled field is ReportData, and the table in which it resides is TblReports. The following t-sql syntax will yield an UNC to the location:
select top 1 ReportData.PathName(0)
from dbo.datReport
I believe you can also get at the path by other means through enterprise manager, but I forget how to at the moment.
--filestream file path
SELECT col.PathName() AS path FROM tbl