I have server with only two databases; in one database I have a table:
CREATE TABLE [dbo].[WR_Shipping](
[ShipmentID] [int] NOT NULL,
[OrderNumber] [int] NOT NULL,
[ShippedOn] [datetime] NULL,
[ShippingMethod] [nvarchar](100) NULL,
[ShippingTrackingNumber] [nvarchar](100) NULL,
[ShippedVIA] [nvarchar](100) NULL,
[TrackingURLAppConfig] [nvarchar](100) NULL,
[ShipmentNotes] [nvarchar](max) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
I can read from the table when logged on the SQL Server Manager as an admin without issue. My web application logs on to the server with a different user ID. I've checked that that user ID has SELECT, UPDATE, INSERT, DELETE, and EXECUTE permission on the entire database. I've also check to make sure that the effective permissions for this table are correct for this user. I've even logged on to SSMS as the web application would and can execute SELECT * FROM WR_Shipping without issue. However, I can execute SELECT * FROM Product with no problem.
I've dropped and recreated the table several times. I have the same table running in my production database, and I can connect to it without issue using the same code.
I've tried every way I can think of naming the table: WR_Shipping, wr_shipping, dbo.WR_Shipping, [database].dbo.WR_Shipping. None of those work; all generate the same error. However, they all work just fine from the SQL Server Management Console. I can't even run something as simple as SELECT * FROM WR_Shipping from the web app.
The error I receive is System.Data.SqlClient.SqlException: Invalid object name 'WR_Shipping'. This error is throw when I try to execute SqlCommand.ExecuteReader. That command is in a routine that I use all over my web app. It takes in a string (the SQL) and a connection, and returns an IDataReader.
Update
I've tried everything that has been suggested here to no avail. Every query I tried works, even against other tables in the same database and schema. This one table never worked. I ended up cloning the production database and using that as my test database instead of continuing to work with this database. Previously I had just been committing the same changes to both databases (production and test).
First, verify the connection string stored in the application's config file is correct.
Assuming all looks good, try these two items:
In your code, set a breakpoint before your command's ExecuteReader (or similar). When you hit the breakpoint, drill into the Command's Connection property, and check the connection string being used. Make sure the connection string is the one you were expecting.
If that doesn't identify the issue, and if you have permissions to use SQL Profiler, set up a session to capture the traffic hitting the database with the application's userid. When you try your code, see what the actual SQL command is that is being sent, and debug from there.
Related
I am trying to add an control to my page. I am following the wizard. Step 1, I select my connection string. The connection works, no error messages. Step 2, I choose "Specify a custom SQL statement or stored Procedure" radio button. Step 3, in the "SELECT" tab I click the "Stored Prodedure" radio button, then select the stored procedure I would like to use. I take this as confirmation that the connection string is working. Step 4, I press the "Test Query" button.
A pop up appears with the message "There was an error executing the query. Please check the syntax of the command and if present, the types and values of the parameters and ensure they are correct. Could not find stored procedure .
I've tested the procedure in SSMS, and it works. I took the query string that is in the stored procedure and changed the radio from Step 3 to "SQL Statement" and pasted the string into the box. The statement worked fine.
I also changed the permissions for the login specified in the connection string to the same permissions I have on the server. (Full admin rights!) That did not correct the issue. I only found a few questions in the forums regarding this issue, and they all pointed to permission issues, but I have ruled that out as I set the permissions.
The Wizard can find the procedure when I am walking through the Wizard, but it can't find it when I test.
I hope someone can point me in the right direction... Thanks!
* EDIT *
Just to expand on the #BlackjacketMack's answer:
When I use the wizard to create the SqlDataSource, and select the Stored Procedure from the the list, it appears that VS is defaulting to the dbo schema at runtime, even though it displays all the sprocs in each schema. (I verified this by changing the schema the sproc was on to dbo and testing it. The results were returned with no errors.) Within the wizard, I do not see any options to change the schema. If I click the "SQL Statement" radio button and type EXECUTE [APP001].[MyStoredProcedure], it works perfectly. I did try the GRANT EXECUTE as #otaku recommended, but that did not work. I also changed the default schema for the user specified in the connection string to [APP001] to no avail. So this appears to be an issue when using the dropdowns in the wizard. Manually entering the data so that the schema can be fully qualified did the trick!
Make sure the application that you are running have the appropriate grant execute on the database objects. Sometimes they are tied to a database role such as below where the stored procedure need to have the execute permission:
GRANT EXECUTE ON ][dbo].[MyStoreProc] TO U_ExecuteProcs
Qualify your procedure with the schema If the proc has a schema 'APP001' as you indicated in a comment, make sure the Sql being passed looks something like EXEC APP001.YourStoredProcedureName.
Use a profiler! One great way to approach this problem is run a profiler on your SQL...either the MS Profiler, or we use http://anjlab.com/en/projects/opensource/sqlprofiler which used to be free. Basically, you'll see exactly what SQL your application is sending and who the login they're sending it as.
If you gave yourself admin permissions as you indicated, I wouldn't define too many object specific permissions simply because they tend to go unmaintained.
I think defining the execution context within your stored procedure will resolve the issue , Here is the link:
http://technet.microsoft.com/en-us/library/ms188354.aspx
I have a table Product which have Quantity column, This table get updated thru .net application using Stored procedure based on flag variable. Now im having problem reported from user that even though the flag variable is not set table is getting updated with new values.
Now i need to isolated the cause for the issue.How will i check which update and through which application this table is getting modified. I have no idea about it.
What is the best approach to resolve this issue?
Assuming you are using SQL Server:
You can monitor calls to SQL Server using SQL Server Profiler. You can setup a filter to monitor queries affecting the Product table. The log will show what the query looked like, when the query was executed, the database user executing the query, the name of the application (if that is specified in the connection string) and a bunch of other things.
I'm switching my web host and backed up my database. Due to some restriction with my new host I could not restore the .bak file and had to send to them so they would restore it. Once they had restored it, I ran my application I get this
System.Data.SqlClient.SqlException: Invalid object name "<table name>"
whenever I try to query a table from the application. However, I have no problems logging in through management studio with same user name and password and querying the tables.
I'm running a mvc 3 site with SQL Server 2008
Does anyone know why I might getting these exceptions when trying to run my application?
EDIT:
Some more information:
the user name I was using in my old db was Kimpo54321 so all tables I had created got prefixed like this Kimpo54321. so I tried adding it to the very first query in my web app so it would be SELECT * FROM Kimpo54321.<tablename> and the query passed without the exception.
Now I did not have to prefix each table name with this earlier in my application and I don't want to apply it to all my queries. Is there a way to fix this?
EDIT:
I ran this to get a alter schema line for each table and changed everything to dbo and its finally working. thnx aaron for pointing me in the right direction finding the answer
SELECT 'ALTER SCHEMA dbo TRANSFER ' + s.Name + '.' + o.Name
FROM sys.Objects o
INNER JOIN sys.Schemas s on o.schema_id = s.schema_id
WHERE s.Name = 'yourschema'
And (o.Type = 'U' Or o.Type = 'P' Or o.Type = 'V')
Are you referencing the schema (e.g. dbo.table vs. table)? It is possible that your user at the new host has a different default schema than at your old host. How are you "querying the tables" - right-clicking and selecting one of the options, or using the exact same query issued by the application?
This is likely an issue where the Web App's user needs to be re-added to the restored database. Certain users do not maintain their permissions when a database is restored onto a different sql server.
The past two times we have rebooted our sql server, our website has gone down. The reason appears to be because the tempdb is getting recreated and the ASPState user is losing permission to read/write to the tempdb (it is an ASP site and session data is stored in the sql server)
This was not a problem until about two weeks ago. Does anyone know how I can prevent the sql server from resetting tempdb permissions after a reboot? Or why this only started happening recently? We are using MS SQL Server 2005.
First off, you shouldn't assign permissions to the tempdb directly. For the obvious reasons that it gets recreated on every reboot.
Which actually raises a question: why do you need to have direct permissions to this database anyway?
You don't need any permissions beyond just being able to connect to sql server in order to create temp tables. However, if you are creating real tables in the tempdb, then I highly suggest you change this to use a dedicated database for this purpose.
UPDATE
Based on Martin's comment all I can say is wow. I would never even have considered that this would have been an option.
Okay, now that I've recovered from the shock.
Create a new job in sql server that executes on a schedule. The schedule should be set to "Start Automatically whenever SQL Server Agent Starts". The job should recreate your necessary tempdb permissions.
In a nutshell, when the server is rebooted the SQL Server Agent will be restarted (provided the service is set that way). When it restarts it will kick off this job that will then fix your permissions. I'd expect the site to remain down for only a few seconds more than it takes for SQL server to completely restart.
I know this is an old question but found some new information regarding the tempdb behaviour on restarting.
The tempdb is essentially recreated from the 'model' db and that is the reason why all changes to it are lost. If you make a change to persist your changes even after restart make the same changes to the 'model' db as you would to the 'tempdb'.
Have a look at the following: Does tempdb Get Recreated From model at Startup?
The Model database is used as a template for TempDB. Add users and permissions to model and the same usere and permissions will be used on TempDB. I do not say that this is the optimal solution for every case but it worked for me in a situation where an application needed speciffic TempDB access.
Create a startup script on sql Server as below:
use master
go
drop proc AddAppTempDBOwner
go
create proc AddAppTempDBOwner as
declare #sql varchar(200)
select #sql = 'use tempdb' + char(13)
+ 'exec sp_addrolemember ''db_owner'', ''app'''
exec (#sql)
go
exec sp_procoption 'AddAppTempDBOwner', 'startup', 'true'
go
Here's a script to create a startup stored procedure, which loops over Logins and creates Users in tempdb as db_owner. This script does not have harcoded logins.
As a result even after SQL machine restarts all SQL logins will have privileges to access tempdb.
USE [master]
GO
IF EXISTS ( SELECT *
FROM sysobjects
WHERE id = object_id(N'AddUsersToTempDb')
and OBJECTPROPERTY(id, N'IsProcedure') = 1 )
BEGIN
DROP PROCEDURE AddUsersToTempDb
END
GO
CREATE PROCEDURE AddUsersToTempDb
AS
DECLARE #loginname as NVARCHAR(100);
DECLARE Login_Cursor CURSOR FOR
SELECT loginname
FROM master..syslogins
OPEN Login_Cursor;
FETCH NEXT FROM Login_Cursor INTO #loginname;
WHILE ##FETCH_STATUS = 0
BEGIN
IF (#loginname <> 'sa' AND (NOT #loginname LIKE '##%') AND (NOT #loginname LIKE '%\%'))
BEGIN
PRINT #loginname
IF EXISTS(SELECT * FROM [tempdb].sys.database_principals WHERE type_desc = 'SQL_USER' AND name = #loginname)
PRINT ' - user already exists'
ELSE
BEGIN
PRINT ' - creating user'
DECLARE #Sql VARCHAR(MAX)
SET #Sql =
'USE Tempdb' + char(13) +
'CREATE USER ' + #loginname + ' FOR LOGIN ' + #loginname + char(13) +
'EXEC sp_addrolemember db_owner, ' + #loginname
EXEC (#Sql)
END
END
FETCH NEXT FROM Login_Cursor INTO #loginname;
END;
CLOSE Login_Cursor;
DEALLOCATE Login_Cursor;
GO
EXEC sp_procoption 'AddUsersToTempDb', 'startup', 'true'
GO
The tempdb database in SQL server is (from everything I've ever read, heard, or experienced) completely dropped and recreated every time the service is started up. Thus, anything stored within or written to that database, including roles, users, or other access right settings, will be wiped out. Barring some fussy code to set/reset them whenever the instance starts up, I don't think you can work around this. (I don't think anything set in the model database gets copied over to tempdb when it's created, but I've never even thought about that...)
Are any such settings being written to that databases? Are you sure that your system has not been recently changed or updated to do so? Possibly relevant, how often does the SQL instance get stopped and restarted? (It's not uncommon--if not wise--for SQL to run for months if not yers without a restart...)
I am trying to set up the SQL Adapter in BizTalk 2009 to use a Stored Procedure in our SQL 2008 DB. For some reason, when I click "generate" in the wizard, and then click "next," I receive the following message:
Failed to execute SQL Statement. Please ensure that the supplied syntax is correct. New Transaction cannot enlist in the specified transaction coordinator.
I know the stored proc works, because we call it from C# code as well and I don't have a problem with it. I'm pretty sure I'm missing something basic, but I can't find what it is, and the only information I can find on using Stored Procs through the BizTalk SQL Adapter only show Select statements, so I don't know if there's some other setting I"m missing.
Here's the Stored Proc:
SET NOCOUNT ON;
Declare #Client int
set #Client = (Select Client_Id from Clients where Client_Name = #clientName)
Insert Into [FTP_Data].[dbo].[FileLog](Client_Id, Client_Name, FileType, Received)
Values(#Client, #clientName, #fileType, GETDATE());
Edit/Update: When I move the solution off my developer box and onto the actual server box, it works fine. As far as I can tell, the only difference is that the actual BizTalk Server components (instead of just the developer stuff) are on the same machine as the SQL Server to which I'm connecting. I would think that should be an issue, though...
"New Transaction cannot enlist in the specified transaction coordinator". Seems to indicate a possible DTC error. Is this the SQL server that the BizTalk databases are installed on?