how can two or more applications use single ASPState database.
I had implemented SQL server session management. I have some asp.net applications deployed on my IIS where i want to implement SQL server session management, so i have ASPState DB, i want to share this DB for all applications.
DB- data base
If you're using the default ASPState database created by the supplied SQL scripts that come with .NET, the database is already designed for shared usage. Just configure each application to point to the same database. The session state is isolated in the db by using the application ID from IIS (i.e. /W3SVC/2165464565), so there's no collision of data.
Related
Is it possible to use Oracle database? Web app is currently using Oracle and may not have access to SQL Server.
Thanks.
RO
Yes it is possible in fact Oracle provides library of asp.net providers including :
Membership Provider
Role Provider
Site Map Provider
Session State Provider
Profile Provider
Web Events Provider
Web Parts Personalization Provider
Cache Dependency Provider
You can find them here.
http://www.oracle.com/technetwork/topics/dotnet/index-087367.html
Out-of-the-box that's not possible. ASP.NET supports the following session state providers:
In-Process - the session is stored into the memory of the web server
State Server - the session is serialized and stored into the memory of a specific server running the ASP.NET session state service. This could be a different machine from the web server
SQL Server - the session is serialized and persisted into a MS SQL Server database
The SQLServer sessionState mode uses, as it's names suggests, SQL Server. If you want to use Oracle you will have to write a custom session state provider by inheriting from the SessionStateStoreProviderBase class and overriding all the methods.
I want to know in which situation i am use this mode ?
Sql Server Mode is one way to handle sessions inside of a web farm for example. If you were to use in proc session state inside of a web farm, you would not be able to share a session over many boxes. Using Sql Server for the storage of the session means that you can load balance your users over the servers inside of the web farm and the session can be retrieved externally, inside of SQL Server. So one web server would allow you to use in proc session state. With many servers you need to store the session state in a common place so all web servers can see the same one.
It's mainly used when you want to use your app on a web farm, web garden, or cluster. Since page requests can come from multiple processes or computers, you can't use an in-process session state provider.
http://idunno.org/articles/277.aspx
I am working on asp.net membership website. I created the membership provider automatically, and now its stored in sql express database within the solution. I want to move all the tables to sql database instead of sql express. Last night I attached the sql express database to the sql server management studio, and I was able to see all the objects. Then, I run my solution in visual studio, and I got error: LOGIN FAILED for the sql express database, and the solution wasn't running.
I have two questions.
1. Why is that happening?
2. If I create the same database in sql server with the same objects, and then point to the sql server database instead of sql express database, will I have problems with the membershop provider?
Thanks in advance.
It sounds like you've moved a database from one host (running SQL Server Express) to another host (running a non-Express SKU). Is this correct?
Ensure that your membership connection string is pointing to the new location of the membership (the non-Express SQL Server). Ensure the logins and users are setup properly in the new SQL Server instance, as expected.
Attaching a database to a new server does not automatically create the necessary logins.
run exec sp_change_users_login 'Report' from within SSMS on your database.
If it comes back with anything in the result set, you'll need to run exec sp_change_users_login 'Auto_Fix', '<username>'
where is the username from the first result set.
I have my default website in IIS7 bound to an ASP.NET application. This application is using the ASP.NET State Server to store session data. I would like to add an additional ASP.NET MVC application to this website. Is it possible to share the session between these two applications using the state server? I've read that there are ways to do it storing session data in SQL Server, but I can't find any documentation on doing it with the state server.
Thanks,
Nathan
Best advice I have to to switch to SQL Server for the session state store. It's not difficult to set up if you already have SQL Available and use the following technique:
Sharing sessions across applications using the ASP.NET Session State Service
For this situation you are probably best to write your own custom session state provider that runs on a SQL database.
details are here:
http://msdn.microsoft.com/en-us/library/aa479034.aspx
the reason i'd write a custom provider is because simply settings up an SQL session provider will not be enough as the applications will use different session keys and therefore will not share state between them. by writing your own session provider you can have fine grained control over the whole process and therefore override the checks in place using the default sql session provider.
What's the preferred (best practice) means of connecting an ASP.Net Website to a database? I doubt it's as simple as using Trusted-Connection and giving the NT-Authority accounts access.
What do y'all do? Assuming a clean install of SQL Server (2008), what do you do to configure access to the database for a website?
I usually run ASP.NET app pool as a separate account (not NT AUTHORITY\NETWORK SERVICE) and use Windows authentication to access the SQL Server. This method has the advantage of not storing the password in config files.
Steps:
Create a user account to run your ASP.NET application on.
Create an application pool in IIS and run it on the created account.
Assign NTFS permissions that your application needs to the account.
Grant permission to login on SQL Server.
Assign the appropriate database roles to the created login.
This will work for many apps. For more complex security environments, you might need more sophisticated strategies.
I used to use trusted connections, but ended up feeling that that sometimes I ended up having to grant too many privileges to the service account used for the connection/app pool. Now I use SQL Server accounts and set up the application to encrypt the connection strings during Application_Start if they aren't already encrypted. In fact I encrypt any section that may contain user credentials. I use an appSetting to determine whether the encryption code runs so I don't encrypt my settings in the development environment.
I also use SQL Server accounts, just find it simpler to do and to troubleshoot.