Wednesday, August 14, 2013

SQL Updates - One shot

Let's be honest, we've all made that mistake in SQL where we accidentally
forgot to put the right parameters into a where clause, and had to
run down to the dba and beg for a recent backup!

Writing SQL update statements really isn't that difficult,
but sometimes it can be daunting executing them,
depending on how many records you're looking at.

There are a few ways you can make things a little less intimidating.

1 - Work up your where clause in a select statement first, to see how many records would be affected.

For a simple example, let's say Ronald McDonald is in our database as "Ron",
and we want to update to use his full name.

select First, Last, Middle
from dbo.tblEmployees
where Last = 'McDonald'
It should came back with 1 row.
update dbo.tblEmployees
set First = 'Ronald',
    Modify_Date = GETDATE()
where Last = 'McDonald'
Now when you run this, it had better come back with only 1 row affected!

2 - Write your where clause so that if you ran it a second time it would affect 0 rows.

Taking the same example, it's good practice to make sure that
if you run your stored procedure twice, it will not do any updates the second time.

update dbo.tblEmployees
set First = 'Ronald'
    Modify_Date = GETDATE()
where Last = 'McDonald'
    and First = 'Ron'
Now when you run this the first time you'll see 1 row affected.
If you run it a second time, it will show 0 rows affected.
Note that it won't overwrite the Modify date, so you'll preserve the date of the original update.

I call this method a one-shot. It can be very useful if you need to track the history of updates,
and especially useful if you have things like update triggers on your table.

Wednesday, July 17, 2013

Interviews - Be Ready to Code!

Finding a good programmer can often be like trying to find a needle in a haystack.

Sometimes the best ones have no degrees, no certifications and very little varied job experience,
and some of the worst interview candidates have glowing shining resumes that make them look like the next Bill Gates.

The best and most reliable way to filter out the people who actually know what they're doing
versus the people who know how to craft a pretty resume is to throw down some code in the interview.

It might seem taboo to some people, but it can save you massive headaches in the future!

It doesn't even have to be rocket science, just something like:
"Write the code to query table X in database Y, and display the data in a grid."

And for the interviewees?
Show up with a pen and a brain ready to show what you know.
Study ahead of time if you have to!

Saying "Yeah I really don't remember how to do it, I usually just copy past from old code" probably isn't going to cut it.
Your memory doesn't have to be perfect, but if you're as good as your resume shows you should be able to at least get close to the mark.

Sunday, June 9, 2013

You down with OPC? (Other People's Code)

One of the laws of programmers and programming that I believe to be universal is:
Nobody likes anybody else's code

It could just be the leading or trailing spaces, too few comments, too much whitespace or any number of things.
In the end it simply boils down to the fact that it's not YOUR code, but you have to touch it.

As a programmer, there are virtually only two ways to avoid having to work with other people's code:
1 - Quit programming
2 - Die

Even looking back on code you wrote years ago can be like looking at a foreign language as styles and talents grow through the years.

So the only advice I can give here is to try and code NOW with other coders in mind.
Think of it as making a work of art that someone else will unveil some day.

A nicely wrapped present that they will open and get a wonderful surprise and not a box of poop!

Tuesday, May 7, 2013


When you're coding error messages, emails, notices and every other kind of text interface for a user, try to think about how it's going to look 10 years down the road.

If someone forgets to fill in a field, which one looks the best?

Required field: First name
This form requires that you fill in all fields before submitting. Please check the form and review all required fields to make sure they are completed. Required fields are highlighted in RED with an asterisk next to the field.
Cheerio, jolly good day outside isn't it? By the by I noticed that you may have forgotten to fill in one teensy weensy field. Would you mind lending a hand by filling that field out if it's not too much of a bother? Thanks in advance.

As comical as these may seem, I've seen some code that was pretty close to some of those examples.

When in doubt: Keep it simple, and avoid SHOUTING !! with caps lock or exclamation points.

Tuesday, April 24, 2012

& versus +

I've pretty much switched over to C# programming, and while I do like some aspects of it, there are some that I think are just silly.

Type conversion is SOOOO easy in VB versus C#.

Dim x As Integer
Dim s As String

s = "7"

x = s 'Since x is an Integer, it automatically converts s to an Integer

x = 5

s = x 'Since s is a String, it automatically converts x to a String

In C# you have to EXPLICITLY cast everything.Kind of a pain.

int x;
string s;

s = "7";

x = Convert.ToInt32(s); //Explicitly converts s to an int

x = 5;

s = Convert.ToString(x); //Explicitly converts x to a string

I understand that VB allows for some "sloppy" programming by making the compiler assume the type conversions, but as programmers shouldn't we be able to depend on the programming language to be smart enough to perform the default type conversion based on the type of the variable on the left?

It just makes things kind of silly sometimes, and I was thinking that maybe the root of it all is that C# doesn't have a separate operator for string concatenation.

In VB you use + for arithmetic, and & for string concatenation.In C#, + is for both. (& is for bitwise operations)

Dim x, y, z As Integer
Dim s As String

s = "Results: " & x & ", " & y & ", " & z

int x, y, z;string s;

s = "Results: " + Convert.ToString(x) + ", " + Convert.ToString(y) + ", " + Convert.ToString(z);

Wouldn't it be sweet if C# defined a string concatenation operator?

And if your response is "Don't be a lazy VB programmer, C# rules!"I say bite me, and if less typing makes you lazy then why are you all so excited about lambda expressions? :P

I really despise the religious war between VB and C# programmers. I've programmed in so many different languages that I think it's just silly because really VB and C# are more similar to each other than to they are to so many other languages.

Tuesday, March 20, 2012

How to save VB and piss off the rest of the world

Visual Basic is a dying language.

People are mostly switching to C#, either due to their familiarity with Java, C++ or just because every sample on the planet is in C#, including the ones provided by Microsoft.

The way things are going, some day VB will go the way of Pascal and COBOL. Languages that are still around to some extent, but people don't really use unless they're supporting an old system.

How could they save VB?

Here's my idea:

***** Make VB recognize similar syntax from other languages *****

If the VB compiler accepted this:

If ((x = 1) And Not(y < 0)) Then
    sTmp = "Test"
End If

AND this:

if ((x == 1) && !(y < 0))
    sTmp = "Test";

Then all of the C# syntax in the world could just be copied & pasted into VB apps, PROBLEM SOLVED.

Here are some of the main things that would need to be allowed:
1 - Semicolon to end a line
2 - Curly braces to open & close constructs (if, while, for)
3 - &&, ||, ! % in place of And, Or, Not, Mod
4 - Brackets for arrays, [] instead of ()
5 - Declarations with type first versus last (string sTmp; vs. Dim sTmp As String)
6 - // and /* */ for comments

Some things that would cause problems:
1 - C# ONLY ends a line of code with a semicolon.

So you can have a statement that spans multiple lines and is only ended when the compiler hits the ;
In VB to extend your program to another line you have to use the _ symbol.

Sample C#:

x = y
+ 7;

Sample VB:

x = y _
+ 7

2 - C# string syntax uses \ escape sequences instead of "" for quotes.

Sample C#:

sTmp = "Fail \\, what\" hey";

Sample VB:

sTmp = "Fail \, what"" hey"

Honestly though I think if there was like a compiler setting like "Allow compatible C# syntax" then you would basically be doing it at your own risk and have to take the risky things into account, but the benefits would WAAAY outweigh the drawbacks!

Monday, February 20, 2012

Switch Hitting

Since the middle of last year I've made the switch from VB to C#.

Mostly because every where I look for samples, training, webcasts, etc. all the code is in C#. Even Microsoft employees doing webcasts or seminars have all been using C#, without exception.

I've done my share of programming in several languages throughout school and work. (BASIC, QuickBasic, pascal, FORTRAN, C, C++, SPARC Assembly, Intel Assembly, java, VB, VB.Net, C#, SQL, HTML, JavaScript, VBScript, batch files, PLC, vhdl, plus a handful of others I dabbled in) So switching languages was no big deal to me, but now that I have switched I've found if I go back to do some things in older projects that are still in VB I code a little differently just in case I decide to convert the code to C# later.

For example, in the old days when you had a string that you wanted to get rid of leading and trailing spaces on, in VB you would go:

sTxt = Trim(sTxt)

But in C# there aren't really a lot of standalone built in functions like Trim, Split, Left, Right, etc. they are all tied directly to the datatypes and accessible as member functions and properties of the variables.
So in C# if I wrote that same line it would be:

sTxt = sTxt.Trim();

Now since C# and VB are both in the .Net world, they share the same data types and member functions, meaning in VB I can do the same code as above (without the semicolon).
So previously in VB I would write something like this:

Dim sSplit() As String
Dim nVal As Integer
Dim sTxt As String

If (InStr(SomeInput, ",", > 0) Then
    sSplit = Split(SomeInput, ",")
    If (IsNumeric(sSplit(0))) Then
        nVal = CLng(sSplit(0))
        nVal = -1
    End If
    sTxt = Trim(sSplit(1))
End If

Now I write it something like this:

If (SomeInput.indexOf(",") >= 0) Then
    sSplit = SomeInput.Split(New String() {","}, _
    If (Not(Integer.TryParse(sSplit(0), nVal))) Then
        nVal = -1
    End If
    sTxt = sSplit(1).Trim()
End If

So that to convert it to C# I really only have to change the built in keywords like If, Then, Not, etc. and add a bunch of semicolons:

if (SomeInput.IndexOf(",") >= 0)
    sSplit = SomeInput.Split(new string[] {","},
    if (!(int.TryParse(sSplit[0], nVal)))
        nVal = -1;
    sTxt = sSplit[1].Trim();

A little bit of a change in style for me after several years of coding in VB, but not difficult by any means, and it can save me tons of time later if I decide to convert an old project to C#. Since the middle of last year I've made the switch from VB to C#.