Work… Work… Work…
It's been almost a year and I have been prone to not getting around to a blog post. Mostly because allot catches up with you while you are working things out.
Since I started this blog, I have been working on a backend "hobby" project for Minecraft (http://minecraft.net). I enjoy gaming and its why I got into IT System and indeed Programming, I find it an excellent way to move myself forward and learn new things. Thus far I have developed a project (appley named Minecraft.Server). All-beit it has actually progressed further than I expected when I started it.
Initially speaking it was stared due to a requirement as I host my own home server at lucky-frog and needed a management solution for it that was generic and didnt cost me any money. Well thats usually how any project gets started isnt it? You formulate some form of requirement, target audience and hey presto get going.
I have used a variety of different technologies to achive the first goal of getting the project working, I can throw out some of the buzzwords before we get started.
- Main host - Windows Service
- Backend - SQL Server 2012
- Data Model - Entity Framework 4.0 (5 wasnt out)
- Frontend UI - ASP.NET Web Forms
- Communication - WCF Self Hosted Service
Well, with all that in I want to get up some project info shortly.
Cheers,
Joey
First TSQL Post
I wanted to make my first TSQL post one that would be of interest and of something that I realised I did not fundamentally understand. Through my use of triggers which I use to detect events in SQL server that have not been handled yet by code, a plaster if you will just to deal with the here and now.
I have always believed that SQL Triggers should not be used, if it can be easily covered by a code update. However through development cycles, you can find that the period of time it takes is longer than applying a short term resolution yourself.
In this trigger I was trying to detect a value after Insert or Update. However instead of defining 2 different triggers (one for insert, one for update) for what essentially was the same code, one trigger seemed more appropriate.
However having the trigger fire after insert or update you might want to detect, at the worker level, what type of action you want.
For example
User 1 inserts record A
User 2 updates record B
Now both actions fire the trigger. But when its an update I need to know if it is the new value was same as the existing value.
I found that through the Inserted and Deleted tables you can detect the type of action you are performing, the example below detects that if the trigger is an insert or update.
-- defines if it’s an update row
IF EXISTS
(
SELECT * FROM deleted AS d
)
BEGIN
-- Do some work!
END
ELSE -- It's an insert
BEGIN
-- Do something else!
END
I found this a useful tool for detecting the type of trigger (insert or update) that is running.
Setting up the site.
Just thought I would get at least something on here that anyone can actually read.
Spending the evening setting up the website I hope to get some nice blogs coming out soon. My specialty is in Junior Programming with C#, TSQL and ASP.NET.
I hope to offer help to people who have helped me!