Blog

Introduction After having worked as a database professional for years I decided it is time to look ahead and think what I would like to be doing in the future. Of course I still love databases but I have always been a little jealous of my programmer friends who are able to create beautifully designed and functional websites from scratch. So, it is time for me to start learning on this new track: and to make sure what I am learning also stays around in my head I am creating this next series of blog posts in which I will document my learnings. Of course, I will be needing some homework exercises. Or.. Cryptocurrency The past years I have been watching the Bitcoin/Altcoin market on and off, and I own…

  Last week I ran into an issue when creating a stored procedure in a SAP PowerDesigner Physical Data Model. After creating the stored procedure and viewing it in the preview window I noticed something was looking odd: the create procedure statement was showing a pair of empty brackets after the procedure name. Empty brackets in a create proc statement? After running the create statement in SSMS, SQL Server confirmed my suspicion by throwing a syntax error: SQL Says No Next, I investigated the stored procedure body in the editor and found that apparently, PowerDesigner's default SQL Server template for stored procedures features a pair of brackets around the stored procedure parameters. Procedure parameters parameter, enclosed by brackets.. Of course, I tried manually deleting them but this was no use…

I was just trying out the log4net framework when I came to a better and more usable alternative. https://nlog-project.org/ is easier to use and configure and has more options, like structured logging. I dabbled with it a bit, and you can find my little project on github: https://github.com/Josbourne2/TestNlog

While working on today's post I came across a picture I could not withold from you, namely, the legendary Dutch sport of Mattress Ball. While some sports can be very expensive in terms of equipment, this one certainly is not. All that is needed is/are: An old mattress A sizable length of duct tape, available at your nearest hardware store A friend who does not suffer from motion sickness A friend who loves to give a helping hand A slope. In our case, it was the side of a dyke Instructions: Fold the mattress across its length and tape the ends together with the duct tape, such that a fairly round shape is made Insert the friend into the cavity that now exists in the mattress. When you do not…

Back in the year 2004, when my face had no crowfeet and I had no real job yet (I was working a supermarket job with no real responsibilities except showing up on time) me and my friends were in a band and we won some studio time in a local band contest. We went to the studio, which was in the backyard of the studio owner's mother (please don't write any comments on this ;)) and we recorded some songs. The recording sounded pretty good and it landed us some gigs, but when we left the studio, I asked the technician if I could have all the raw tracks we recorded, so in the future, I could experiment a bit with these. So I went and experimented, but it did…

"We are not using User Defined Table Types anymore! They are bad for performance." This is what one of my coworkers told me last week. Whenever a person makes a statement like this, I first of all would like to know what made him/her say that. To me, a statement in the form of: "We do/don't do X, because it is bad/good" makes me think about religion. Religion is all about rules, and in IT, there are no rules. In IT, the credo is, and should be: "It depends". However, an issue at work has made me decide to move forward with this one. As most of you know, parameter sniffing can be one of the hardest problems to recognize. Most of the time, a parameter has a single value.…

Ok. So, today I came across a performance issue at work that might or might not have to do with the fact that we are using random Guids in a certain table. I decided to accelerate the post I was writing about this, so it could benefit me and my colleagues, and of course, you. In my days as a SQL Developer and DBA I have come across a lot of performance issues that were caused by these tiny little monsters. To explain, let's take a dive into the subject: SQL Server is a great database product with great performance. That is, when you know what (and why) you are doing. Of course, you all know a lot of that performance has to do with indexes, so you want your…

Waarom nou DV? Ik zie het voordeel niet want als het gaat om het bijhouden van historische informatie kun je toch net zo goed de tabellen uit je bronsysteem inladen en daar een fromdate en tilldate aan toevoegen? Natuurlijk sla je dan de (business) key dubbel op, maar je hebt een mooi platform waarop je zonder extra joins heel makkelijk ENT en PIT functies kunt bouwen, net zoals het doel is bij de DV methode. (Of is dit niet het doel?) Als een business key wijzigt… Er komt een extra kolom bij de BK. Wat dan? Bij DV kun je kiezen voor een nieuwe hub, maar beter lijkt me om de hub te wijzigen met de nieuwe BK. Maar als je dat doet, wat zeggen de SAT tuples dan nog…

Last day at work we were confronted with an error in our monthly production run. It turned out the Trustworthy property of the database had been set to "off", so I suspected one of the dba's to have performed a restore without knowing about this setting. It turned out our dba was helping us with disk space issues by moving database files around to new disks where there was more free space. My first thought was: "They should have used the detach/attach method when they were moving the database files!" I soon learned from another coworker that that was what they had probably done in the first place. Somehow I thought that when you use the detach/attach method, the database settings are kept in the sys.databases table, and are applied…

This post is about something I come across more times than I would want to, and not even the least of people are repeatedly triggering my nerves with a thing like this. Anyway, I expected you not to, when you are a database developer in a multinational software development company. Let's cut to the chase: this post is about triggers. Database triggers. Very handy database objects that can perform a lot of useful tasks for you whenever you modify data in a table. I'm kidding. Of course, triggers are handy, but they can cause issues for performance, deadlocking, concurrency, and can even bring a not-too-busy database to a grinding halt when they are used wrong. This post is not about that. A few weeks ago, I received a call from one…