I'm happy with the explanation, but feeling confused due to BOL:

After declaration, all variables are initialized as NULL, unless a value is provided as part of the declaration.

My point of view, assume things is never good enough. What if Microsoft decides to change the factory settings?

In my oppinion declaration is the perfect way to choose.

It would be better to define the collation. If it's case sensitive, then 'Tea' will not match 'tea'. 😛

I hate DISTINCT *

😛

Nice question!

But i can't get the purpose of this.

How can an unpredictable option be useful?:-D

Hmmm.

According to BOL 'not.funny' should be treated as a failure:

[ @newname = ] 'new_name'

Is the new name for the specified object. new_name must be a one-part name and must follow...

Instead of that:

invoiceitems.invoicetype,

sum(CASE WHEN invoiceitems.invoicetype = 'SCRN' THEN ABS(invoiceitems.homenettvalue) *-1

ELSE invoiceitems.homenettvalue END) as SumPrice,

sum(CASE WHEN invoiceitems.invoicetype = 'SCRN' THEN ABS(invoiceitems.homenettvalue) *-1

ELSE 0.00 END) as SumCredit,

sum(CASE WHEN invoiceitems.invoicetype = 'SCRN' THEN...

An easy one. Thanks!

An easy task for 3 points! 🙂

We have learned to explicitly terminate each possible flow of the code.

SELECT

p.*

FROM

personnel p inner join

coordinators c on p.Office=c.Office_code

As you are seeking an employee of the coordinators table between all employees in the coordinators table, the second...

If i need a specific order i'll use ORDER BY. It's the clearest method to avoid future problems. 😎

A good back to basics question. Thanks!

Is it a useful knowledge?

Good question! Learned something. Parsing does not set initial values! 🙂

And why is BETWEEN checked regardless of the collation?

If lowercase characters sort ahead of uppercase ones, then 'B' is greater then 'd', and BETWEEN can't evaluate to TRUE! Like...