From time to time my customers, or their end users, call me with a problem that requires some direct editing in the database for some application.
Previously I solved those kinds of changes with the help of the good old Sql Server Management Studio, writing some T-SQL directly. But I’m not very comfortable doing so, one reason is T-SQL is not very friendly, another reason is I dont have any history to look back to. I could write management scripts in stored procedures, but that just feels clunky.
A much better solution is to use LinqPad to query and edit the data. For a few bucks I get intellisense C# with Linq and can do whatever I need very quick.
However – I do have C# projects for my data access, and there are a few methods I sometimes like to run alongside the data changes. Plus some data maintenance comes with requirements to add features to the API.
So – my current workflow is to use an EF context inside a testproject in my Visual Studio solution. And inside that I write testclasses and methods with the maintenance code I need:
I like how I keep the maintenance code easily available for future reference this way. And also the closeness to the C# application code. Ideas for improvement are much easier to implement than if I’m inside SSMS.
Notice the long descriptive method name, and for the class name I just use date as it is only expected to work on this time only.
Very important – thanks for the comment Jonas J – I do need to make sure to not run the test more than once – in my code I solve that with asserts, but that might be easy to forget. So a bettersolution might be to comment out the whole code – or at least the [TestMethod] line – after running the maintenance.