I have written a very small C# program, that uses a very small SQL Server database, purely for some learning & testing purposes. The database is used in this one new pro
IIRC using AttachDbFilename
spins up a SqlServr.exe
process running under the user account your process is using, separate from the SqlServer instance running as a service (so stopping the MsSqlServer service doesn't stop this issue). In the case of a dirty exit, sometimes this process does not get cleaned up. I suspect that killing this process will free up the db files.
The most likely options:
You can check 1) with TaskManager and 2) by looking in Server Explorer. Your db should show a small red cross meaning 'closed'.
And you should rewrite your code to close connections ASAP. Use try/finally or using(){ }
blocks.
Try using Process Explorer written by Mark Russinovich, a Technical Fellow at Microsoft. It's a standard swiss-army tool in the pocket of Windows Admins/Developers. It can show you what processes are holding handles on resources in the system.
Once you've got Process Explorer installed, try the following:
The search results should display a process/service with a handle on one of the resources still held by a wrongly-terminated process.
I found this solution at: http://oreilly.com/catalog/errata.csp?isbn=0636920022220
Right-click the database in VS's database explorer and click close connection between debugging sessions and it worked for me.
I think there is already SqlTestDB.mdf is attached. I have faced this problem before, simply go to Ms Sql server and detach the database then rebuild your connection at Server Explorer in Visual Studio.
You are opening the dbase at the start and no certainty that it is being released when finished. Really you are waiting for the memory manager to sort it out, it depends then on how busy the system is as to when the file can be released.
I think that you need to change this to "Open when needed".
I for example put the code to access any database in it's own class, once the actions have been completed I release it.
Opening and closing does have overhead, but I have found I can live with it by doing the following,
Have more than one entry point in your class, one for single transactions, and another for multiple transactions. For example
S_UpdateSingleRecord(...)
M_UpdateManyRecords(...)
I find that in most applications these can be static, because they in themselves do not store data they only pass it through to and from the database. It only loses it's static status if I want to cache something for my application.
I use 'using' in the S_SingleTransaction() because it cleans it for me. But I leave the Multiple entrypoint open and close it when my calling function finishes. I have never had this lock problem with a single mdf and one application. It would come back into play with one mdf and multiple applications, in these cases you need to make use of the MSSQL as a service dbase instead, you would find it just as easy to setup in your Visual Studio, and then in other applications you already have that database on the list in your toolbar.