Steve Verschaeve is a Database Architect at PwC Belgium and former MCT working with SQL Server since 2003. He holds an MCP, MCTS and MCITP certificate . If he’s not working you will find him messing around with Arduino.
He is also a member of the Microsoft Extended Experts Team (MEET) for SQL Server and the Belgian SQL Server User Group (SQLUG) co-organizing SQL Server Days since 2009.
I thought I would do some cleaning up in my SSDT solution which turned out a bad idea.
In my solution I have three database projects which all started with the name “Database”. It seemed a good idea at the time because I also have several unit test projects having the same name as the database projects so I started those projects names with “UnitTestAdventureWorks” and “DatabaseAdventureWorks”.
I changed my mind as the icons for the database projects and unit tests are different and it just looked a lot more cleaner without the names Database and UnitTest in their project names.
Once I got rid of the prefixes and started to build…BAM, could not found project file “DatabaseAdventureWorks”. Of course not, I changed it a minute ago.
My first idea was to rename the project again to “DatabaseAdventure”. Visual Studio asked me to change the database in localDB as well. I said yes hoping it would rollback everything. Not only did it change the database names with the database prefix but also the project settings. I’m fine with the project settings but not the database changes.
Changing the name of the database in SSOX (SQL Server Object Explorer) back to normal (who wants their database named DatabaseAdventureWorks anyway? We know it’s a database!); Visual Studio did not ask me to change the project settings.
I have the impression that settings between project settings, SSOX and Solution Explorer are not automatically updated. Also building the project does not help.
If anyone has some good advice or a workaround, shoot!
If you’re like me, you find blogging very hard because of the following reasons:
There is so much misinformation about SQL Server on the Internet and I don’t want to be part of that. Does this mean I suck? I don’t think so (I hope not) but I personally think if you’re going to write a blog post that the entire SQL Server community is going to might read, it might as well be good…damn good!
One of the possible topics I would like to write about is errors, scenarios or whatever you end up with at work. So sure, there’s lot to blog about but I don’t want to make screenshots of potential security wise issues regarding my professional setup. Yes, we can blur some things out but seriously, let’s take a screenshot of a Visual Studio solution for example, it will contain almost 100% data which should not be in the open.
I hate it to write about topics that has been written about dozens of times already.
I wish I could blog more often, I even invested in a dedicated hosting, but I see very rare occasions. When I blog, it will usually be about topics I know I will forget because my long-term memory fails on me and If I can share with you, why not? That’s a bonus! Right?
Whenever you are using a command line tool like bcp.exe in an execute process task, the command line window will pop-up and close very fast which makes it hard to debug.
A small trick is to put the executable in a batch file and throw in a pause and call the batch file from within the process task. Upon executing, the command line window appears and will continue after you press a key.
The batch file might look like this:
the %* accepts all the parameters passed from within SSIS to bcp.exe.
Whilst debugging an SSIS package and tracking the values of variables in the locals window, I noticed old variables which I deleted earlier in the project.
I did a rebuild, closed and open the solution. I even rebooted the machine! Every single time the old variables appeared although they were removed and then …it hit me! The checkpoint file! I deleted the existing checkpoint files and voila, the old variables no longer appeared…