Beginning a journey to “data scientist”

For a long time I’ve been interested in data. My first development job was building a production tracking and reporting application in Microsoft Access (version 2.0 if you’re asking) and I’ve been in love with the idea and practice of storing data ever since. Many of my subsequent jobs were building applications to collect and show data, after my experience with Access (which was then, and still is, an incredible piece of software) I worked with VB4 through to VB6 and the transition to Windows Forms and C# and eventually to HTML and the web. ┬áBut all that time, it was the *data* that interested and excited me. I did a few assignments building business intelligence solutions using the SQL Server BI stack and that was really good fun and challenging but I always seemed to end up back as a C# coder.

Having finished a recent contract building web apps in C# and Angular and all that webby stuff I found myself thinking that I’d change my focus and go back to the data. I had heard about the Microsoft Professional Program for Data Science, so I’ve enrolled in that with the aim of transitioning away from being a pure code monkey to something more deeply attached to the data.

I’ve finished a couple of the modules already, but I plan to blog a bit about my experience in making this change. At the end of the journey I hope to be able to call myself a Data Scientist, and more importantly get paid to be one.

 

Conversation id’s are not carried between service broker instances

Digging around today I have found something that, at first seemed odd, but probably isn’t. When a message gets transmitted between service broker instances, it has an associated conversation ID. One might expect that the ID would travel with the message(s) to the destination instance. After all, it’s the conversation ID that ties together all the messages that need to be treated as one dialogue.

At the destination, however, the conversation ID that the messages have is different to the one they are associated with at the sending end.

This seems odd.

All the messages in a conversation at the receiving end have the same conversation ID, it’s just a different GUID to the one that they have in the source database.

Apply a bit of brain juice and I surmise that what is going on here is either (or both) of (a) the system just not trusting the sender GUID, so causing a new one to be used, (b) an incrementing GUID is being used for the conversation ID, so that the destination has to assign a fresh value so as to maintain the sequence order of the ID.

I need to do a bit of testing to see if (b) is in fact what’s going on here.

 

P.S. I shall be presenting a talk on Service Broker of the SQL Server User Group in Manchester in June.