Diabetes is a topic near and dear to my heart. I have had close family suffer from it and a few pass away because of it. In fact, I’m a high risk, due to family genetics, of developing Adult Onset Diabetes (Type II) as both of my uncles on my mother’s side developed diabetes in their 40s. My grandmother and several of her brothers and sisters are also suffering from it as well.

All that being said – Scott Hanselman (http://www.hanselman.com/blog/TeamHanselmanAndDiabetesWalk2006.aspx) is walking to raise money for the fight against Diabetes.

Please visit and see if you can help out this very worth cause that definitely affects someone that you know. 

This was fun. It’s a completely different database and set of circumstances than last night’s fun and frivolity.

I finished an application, zipped up the folders and sent it off to a client. In this application there is a desktop app that talks to a web service that talks to a SQL Server 2005 Express database. Sounds fairly simple, right? Right.

Well, the client unzips it all to a directory, sets up the virtual application for the web service and starts trying to run the desktop portion. It starts up, pulls up all of the lookups that we have in the database and it all looks good. Now, I’m on the phone and elated at how smooth this is going. At this point, the client tries to create a new record which is going well (wow, even a little drop down calendar and oooh look at that, it’s all of the types of records that I could create so I don’t have to type there… wow… and more gushing) until they try to save… At this point, there is a wonderful error that pops up –

“Failed to update database ‘database name.mdf’ because the database is read-only.”

Crud! After getting them to check the file properties and other such things, I called Patrick Steele, who has been working with me on this project, to see what he thought about it. It’s been a long day, especially after last night’s SQL Server Express issues, so I’m not thinking all that clearly. Patrick, after running through some of the same questions that I had so I’m feeling a little better about my thinking, has the thought that it might be a security issue and that the ASPNET user might not have permissions to write to that directory. Sure enough, since the ASPNET user doesn’t have permissions the database loads in read-only mode. Fix that and the database and the app work just fine.

Yesterday I had to make a quick change to a SQL Server 2005 Express database that I’m using for an internal to SRT Solutions tool. I decided that the easiest way to do it was to leverage the auto-connect feature of SQL Server 2005 Express by just FTPing the mdb down, making my change and ftping it back up. This has worked a number of times in the past. Not this time. I got a “login failed for user ‘USERNAME'” when I tried to run the application. That was infuriating. I spent the next 4 hours or so working with the SQL Server Management Studio Express (Enterprise Manager lite for Express) assigning, unassigning permissions, users, attaching, detaching, backing up, restoring and everything else that I knew to do. I kept getting “User could not login to user’s default database” and general login failures. My personal favorite that I saw yesterday was “Could not attach, DatabaseName is not a primary database file. (Microsoft SQL Server, Error: 5171)”. Now, I’m usually pretty good with googling the answers, but this time I’m really coming up short.

All of this is proving to me that I’m a programmer, not an administrator. I’m digging the new functionality in SQL Server 2005 but I’m not going to be the one to administer the databases that I write code for.

Long story short – I raised the white flag. I IMed Jason Follas and asked him if he knew what was going on. He figured out that it had something to do with the master file that SQL Express was using for the auto-connect. He found this forum topic. Here’s the relevant snippet:

“When you first run SSE this way, it makes a local copy of master etc. in C:\Documents and Settings\<your user account name>\Local Settings\Application Data\Microsoft\Microsoft SQL Server Data\SQLEXPRESS.  That’s why it’s so slow the very first time it loads under a new user profile.  It may even timeout the first time you ever use it under a given profile.

Based on your description, it’s very possible something went bad in those files for some reason.  So, I would first make a backup and then delete the SQLExpress directory under C:\Documents and Settings\<your user account name>\Local Settings\Application Data\Microsoft\Microsoft SQL Server Data.  That will get rid of the local copy of master, etc.  Then, reboot. ”

Well – Lance (the author of the post and author of SQL Server 2005 Express Edition Starter Kit) was absolutely right. I killed the master files (after copious backups) and rebooted the machine. It’s working like a champ now. On reboot, it regenerated the master files needed and started right up.

Thanks Lance and Jason. 

In case you missed it on Day of .NET‘s web site – the cutoff for the call for papers is this Wed.

Day of .NET has a new logo thanks to Kerry Colligan.

Check out TechEdBloggers.net

Patrick Steele is doing the tutorial session on NUnit and how it works.

Dave Donaldson doing the main session and is talking about writing quality software with VSTS.