I usually store my connectionstring in web.config or in the application settings of my Visual Studio project. The application I'm currently working on makes a lot of trips to the database which means it will look up the connectionstring every time. Should I be putting the connectionstring in the cache or should I be looking at storing the whole SqlConnection object in the cache to eliminate the need to open and close them all the time?
Update: Seems like the consensus is to store the connection string in a configuration file and leave the caching in the trusting hand of ADO.NET
I wouldn't cache the connection object, that will defeat the built-in connection pooling -- ADO.NET will handle connections (assuming you instantiate and close them) efficiently by itself.
As far as the connection string itself, you shouldn't need to cache it if you load it from connection -- the connection manager object in the .NET 2.0 framework loads the config into memory when you first access it, so there are no repeat trips to the file system.
The web.config is cached. But even if it wasn't, don't forget that ado.net maintains a connection pool - its not opening a new connection every time you make a call to the db.
I usually cache the connection string in a global configuration object in my application. This value is loaded up at the beginning of program execution from where ever it is stored -- file, encrypted file, config file, etc. ADO.NET is very good at caching connection objects to the database so I would not cache the SqlConnection object.
Keep it in a configuration file. Use a robust data access strategy provided by tools like NHibernate or Linq to Sql.
From what I can recall the contents of the .config file are held in memory anyway... I'll get back to you.
Edit: What HE said
A possible solution:
Store the initial encrypted connection string ( in Web.Config or App.Config) for a login allowed to run only one stored procedure for authentication. Than switch the login dynamically from encrypted values stored in a config table in the db.
Related
I need help!
We have winforms app with existing large db (SQL), and I have started the project that aims to reproduce some of the logic on the web. For this purpose I decided to use Asp.Net MVC database first approach.
But! There are a lot of Views, Procedures and Functions in our db that based on connected user host_name()+host_id() (for example, filtering views by permissions or filling the temp tables for current user (connection)), but Web connection (with IIS) provides the same host_id() and host_name() for all it's connections, so I try to find approach that will allow me to recognize the connection (one user can have few connections) in SQL with the minimum db object changes.
Have any idea?
You can supply the value for HOST_NAME() from the client by including the WSID=newName in the connection string.
So in your application code, you'll have to obtain the connecting machine's hostname, then generate a connection string on the fly containing the WSID parameter, and pass that connection string to Entity Framework.
I am building a website using asp.net MVC. I have two connection strings in the web.config, one for local db and one for the server db. I am testing my work on local and then put it on the server. the server connection string (user name and password) is also in the web.config. Tomorrow when I sell the product, I want to make sure I don't give this web.config to the clients. but It can happen by mistake. How can I prevent this?
My suggestion would be to use one of two methods:
A ConnectionStrings.config or a Web.Config transform. As usual there are pros and cons for both.
Using a separate config file for connection strings
Each developer can have a local copy of their connection strings
ConnectionStrings can be marked to ignore and never committed to source control
However
- Requires each client/developer to be individually managed
Web.config transforms
Each connection string/build configuration can be source controlled
Requires publish of application rather than just a build
However
Can become difficult to maintain with large numbers of transforms.
Personally I prefer having a ConnectionStrings.config - I don't like having production credentials in source control. It also has the nice side effect of giving a build error if you've forgotten it so you can't leave them out by mistake.
Don't use user name and password in the connection string, but use integrated security.
Instead of this.
User ID=****; Password=****;
Use this.
Integrated Security=true;
And make sure your logon user has access to the local database. And the IIS server has access to the server database.
See here for configuring IIS to be able to access SQL Server.
Is it safe to write connection string in web.config in an ASP.net application.
The application will be using 2 databases and I think the connection string can be retrieved easily.
Can anyone please suggest a secure place(web.config or other file) for writting the connection string except encrypting it.
Web.config is the right place for this. You can encrypt the connection string if that's a concern for you. Encrypting the connection string in Web.config it's already supported in ASP.NET and it seems that you already know that...
Link for reference.
If your worry is the outside "hackers" stealing your web.config file, then it doesn't make a difference where you store it, since if they have access to the web.config file, they probably have access to any other location where you may store the CS anyways.
If on the other hand you want to protect from an internal threat, then try saving it into a separate file (even a simple text file will do) and give that file special access permissions that only allow you and the application access and noone else. Also, you may be able to do the same thing with web.config itself.
i want to know where a session is stored when i set it in asp.net application. Does it consume RAM or hard disk space?
Actually, i save a datatable into a session variable. I save it into session because calculation of the datatable takes long time. In order not to calculate the datatable again, i get it from the session.
But i am curious about the time when the datatable will grow much larger than now. Will it stuck the ISS?
Thanks
Session state in ASP.NET is by default stored in process memory (which is RAM).
You can change this in web.config by altering the values of the configuration/system.web/sessionState element:
<configuration>
<system.web>
<sessionState mode="...">
</system.web>
</configuration>
The available options are:
InProc (default)
StateServer - will store in a seperate process which can be on a seperate computer
Off
SqlServer - will store state information in a sql server database
Custom - allows you to provide your own session store
Depending on how you configure the Session in your Web.Config, the Session can be stored In-Memory, Asp.NET State Server, Sql Server.
By default, the session is stored in-memory, which means the Ram. If the data-table gets large and there are a number of concurrent users, you may get an exception. Depends on how many users are accessing the system concurrently, what is the Ram on your system etc.
Session state can be stored in different places that you can choose. Here's a good explanation on MSDN
The default is in memory on the server where you web application runs, so if your session grows too large you will indeed have ram/paging problems.
But why session? Is the data in the datatable user-specific? Otherwise Cache would be more appropriate.
If you are using InProc session, then it will be stored in memory. So if you have enough memory it will be in memory. Once you hit your limit look forward to it paging out to disk.
You can also use out of process session storage like the SQL server. This is configurable in the web.config. Note that you will need to have a database configured for it. You can also check out MSDN to read up on the storage types.
Old link above, but still partially useful. Another quick look and I'm found a better link that goes more into detail.
The typical InProc session state is stored in memory of the web server.
I am using ADO.NET Provider on Windows Mobile (C#) to connect to SQLite database.
Will keeping database connection open for application life create any issue? I am thinking to keep it open because,
It will not allow user to delete database file (as it's already in use).
It will not allow other processes to modify it (as it's already in use).
Does not require to open connection each time.
Please let me know if there will be any issue with it.
The best way is to keep reference of the connection object in a static way. You should know that the connection can drop after a while, and you must prepare the code to handle reconnection.
Something like clsDbUtils.getConn() would do the job inside if sees the connection is no longer valid.