I'm working on an ASP.NET Web Forms application with SqlMembershipProvider. As it is running on Azure too, I use KB2006191 Updated ASP.NET scripts for use with SQL Azure for tables and SPs.
Apparently, they do not work smoothly with a standalone SQL Server 2008 R2 SP1. Especially dbo.aspnet_Users_DeleteUser fires an internal error:
Msg 8624, Level 16, State 1, Procedure aspnet_Users_DeleteUser, Line 111
Internal Query Processor Error: The query processor could not produce a query plan. For more information, contact Customer Support Services.
Edit:
I broke down the issue to one SQL statement which actually fails (even if I hard-code a value for #UserId):
DELETE FROM dbo.aspnet_Users WHERE UserId = #UserId
Original:
I tried fixing my SQL Server installation by downloading a Cumulative Update Package and setting trace flag 4199. However, this did not help. To be honest, I'm not too sure whether I applied the patch properly. I'm doing further research on this.
Moreover, I tried to rewrite the SP a little, as I found some tips on the web. This did not help either, and the same query is generated by aspnet_regsql for standalone SQL Server anyway. Actually, I tried to get rid of a subquery around line 111 by turning this:
IF ((#TablesToDeleteFrom & 1) <> 0 AND
(#TablesToDeleteFrom & 2) <> 0 AND
(#TablesToDeleteFrom & 4) <> 0 AND
(#TablesToDeleteFrom & 8) <> 0 AND
(EXISTS (SELECT UserId FROM dbo.aspnet_Users WHERE #UserId = UserId)))
... into this:
IF ((#TablesToDeleteFrom & 15) <> 0)
Did anybody come across similar issues dealing with membership and both Azure and standalone SQL Server?
According to Scott Hanselman and this blog post, the ASP.NET Universal Providers For SqlExpress 1.1 package (System.Web.Providers) is the officially supported method of enabling the SQL membership, role and session providers across SQL Azure and standalone SQL Server.
Related
here is the question: I'm trying to publish ASP.Net project on Azure. Half way there, i have verified connection to Azure and now i just need to attach database. But when i publish it - it gives strange error:
Error 1 Web deployment task failed. (The database compatibility level '12' is not within the supported range of 80 to 130.) 0 0
Before that i had a problem with connection string password and login, but after creating a new web app it sorted. Now this.
Any ideas of how to fix it?
Please connect to the SQL Azure server using SQL Server Management Studio and run the following statement:
ALTER DATABASE MyFirstDb SET COMPATIBILITY_LEVEL = 130;
You can find a list of the compatibility level here
I have created a stored procedure :
CREATE PROCEDURE usp_PettyCash_GetSingleUserInfo
(
#MaerskID varchar(50)
)
AS
BEGIN
SELECT ISNULL(MaerskID,'') AS UniqueID, ISNULL(FirstName,'') AS FirstName, ISNULL(MiddleName,'') AS MiddleName, ISNULL(LastName,'') AS LastName, ISNULL(EmployeeType,'') AS EmployeeType
FROM Users a
LEFT OUTER JOIN t_PettyCash_EmployeeInfo b ON a.MaerskID = b.UniqueID
WHERE a.MaerskID = #MaerskID
END
GO
And it works fine in my live database server. To make some modification, I BACKUP my database and restore it in my local pc. The problem is, when I run my web app from local pc, it gives the exception,
Could not find stored procedure 'usp_PettyCash_GetSingleUserInfo'
I gave my pc's database user admin rights but still it gives the error. I am not sure what actually the problem is. I don't think the problem is in my code because, when I connect to my live database, everything is FINE. Please help. Of course, I first tested the stored procedure in local pc before going for live DB. that time everything works fine, but now its not.
I am using SQL Server 2000 Enterprise Edition and VS2005 ASP.Net & C# 2.0.
To solve this issue.
1.)Drop Existing SP.
2.)Create new SP.
Now you will get the result.I also faced that problem but this trick works for me.One this more please check the SQL server on both end.
Hope it helps
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.
I have a Sql Server 2008 Express database file that's currently being used by an ASP.NET application, and I'm not sure how to query the database without taking the website down.
I'm unable to copy the database files (.mdf and .ldf files) to another directory, since they're in use by the web server. Also, if I attach the databases to an instance of the sql server (using the 'Create Database [DB name] on (filename = '[DB filename.mdf]') for attach;' command at the sqlcmd prompt), then the application pool user becomes unable to access the database (i.e. the webpages start producing http 500 errors. I think this might have to do with the username for the application pool becoming somehow divorced from the login credentials in the sql server database).
Any suggestions? I realize this is probably a newbie question, since it seems like a rather fundamental task. However, due to my inexperience, I really don't know what the answer is, and I'm pretty stumped at this point, since I've tried a couple of different things.
Thanks!
Andrew
if I attach the databases to an instance of the sql server (using the 'Create Database [DB name] on (filename = '[DB filename.mdf]') for attach;' command at the sqlcmd prompt),
Don't do this to a live database - it's attempting to be setup an MDF to be written to by two different databases...
Use Backup/Restore
As you've found, Attach/ReAttach requires the database to be offline - use the Backup/Restore functionality:
MSDN: Using SSMS to Backup the Database
MSDN: Using SSMs to Restore the Backup
Be aware that the backup/restore doesn't maintain logins (& jobs if you have any associated with the database) - you'll have to recreate & sync if using an account other than those with uber access.
Maybe Linked Server would work?
Another alternative would be to setup another SQL Server Express/etc instance on a different box, and use the Linked Server functionality to create a connection to the live/prod data. Use a different account than the one used for the ASP application...
Is the ASP.NET 4.0 SQL session state mechanism backward-compatible with the ASP.NET 2.0 schema for session state, or should/must we create a separate and distinct session state database for our ASP.NET 4.0 apps?
I'm leaning towards the latter anyway, but the 2.0 database seems to just work, though I'm wondering if there are any substantive differences between the ASPState database schema / procedures between the 2.0 and 4.0 versions of ASP.NET. Thank you.
There was no quick answer on this from anybody, so I did some digging. I generated an ASPState database using the aspnet_regsql.exe tool from .NET 2.0, and then I did the same thing using the same tool but from .NET 4.0. Then, I generated scripts from each of those resulting SQL Server databases and used a comparison tool to isolate the differences.
What I found is: The only material difference between the ASPState schema from .NET 2.0 to .NET 4.0 versions is the dbo.DeleteExpiredSessions stored procedure. That's the stored procedure called periodically by a SQL Server Agent scheduled job also installed by the tool.
Consequently, it would seem that the schema for ASPState 2.0 and ASPState 4.0 are perfectly compatible and so it's not necessary, from a technical standpoint, to segregate ASP.NET 2.0 and ASP.NET 4.0 session state – but I'll likely do it anyway.
(This finding was a bit surprising, as ASPState changed a lot from .NET 1.1 to .NET 2.0.)
Details for each version's changed stored proc:
.NET 2.0 ASPState DeleteExpiredSessions stored procedure:
CREATE PROCEDURE dbo.DeleteExpiredSessions
AS
DECLARE #now datetime
SET #now = GETUTCDATE()
DELETE [ASPState].dbo.ASPStateTempSessions
WHERE Expires < #now
RETURN 0
GO
.NET 4.0 ASPState DeleteExpiredSessions stored procedure:
CREATE PROCEDURE dbo.DeleteExpiredSessions
AS
SET NOCOUNT ON
SET DEADLOCK_PRIORITY LOW
DECLARE #now datetime
SET #now = GETUTCDATE()
CREATE TABLE #tblExpiredSessions
(
SessionID nvarchar(88) NOT NULL PRIMARY KEY
)
INSERT #tblExpiredSessions (SessionID)
SELECT SessionID
FROM [ASPState].dbo.ASPStateTempSessions WITH (READUNCOMMITTED)
WHERE Expires < #now
IF ##ROWCOUNT <> 0
BEGIN
DECLARE ExpiredSessionCursor CURSOR LOCAL FORWARD_ONLY READ_ONLY
FOR SELECT SessionID FROM #tblExpiredSessions
DECLARE #SessionID nvarchar(88)
OPEN ExpiredSessionCursor
FETCH NEXT FROM ExpiredSessionCursor INTO #SessionID
WHILE ##FETCH_STATUS = 0
BEGIN
DELETE FROM [ASPState].dbo.ASPStateTempSessions WHERE
SessionID = #SessionID AND Expires < #now
FETCH NEXT FROM ExpiredSessionCursor INTO #SessionID
END
CLOSE ExpiredSessionCursor
DEALLOCATE ExpiredSessionCursor
END
DROP TABLE #tblExpiredSessions
RETURN 0
GO
As for why the above change was necessary, I found the following MSDN blog post:
Deadlock when storing Asp.net sessions in SQL server during peak load
Excerpt, in reference to the older procedure:
...
This would take the locks on all
the expired records for deletion and
these locks may be promoted to page
locks. This can give rise to deadlocks
with other ‘session state write
statements’ when the number of records
marked for deletion increases. By
default this stored procedure is
supposed to run every minute.
...
Consequently, the newer version of the stored proc may be advisable for ASP.NET 2.0 apps, too.
One more thing I learned from the blog post that I did not know: ASP.NET 4.0 session state mechanism now offers compression. Search on compressionEnabled at sessionState Element (ASP.NET Settings Schema).
Finally, I also just found something relevant from Microsoft, at ASP.NET Side-by-Side Execution Overview. Excerpt:
...
If SQL Server is used to manage
session state, all versions of ASP.NET
(of the .NET Framework) that are
installed on the same computer can
share the SQL state server that is
installed with the latest version of
ASP.NET. The schema for session state
is the same in all versions of
ASP.NET.
(Though there are some differences in implementation not specific to the schema.)