Miscellaneous

Need an Answer? Actually, No ... You Need a Question

Jeff Smith — Tue, 13 May 2008 15:04:33 GMT

Welcome!

The reason you were directed here is because you need assistance, and I am here to help. I am not, however, here to provide you with any answers! You see, it looks like the assistance you need is not finding an answer; it is rather that you need assistance finding a question.

As you know, there are all kinds of questions. Questions that test memory recall. Questions that test logic skills. Brain-teasers and mathematical questions and so on. But there is one requirement that all good questions must have in common before they can be answered:

A proper question MUST provide ALL of the information necessary in order for an answer to be given.

In other words, if you omit important information from a question, it doesn't matter how simple or easy that question is: It suddenly becomes very difficult, or even impossible, to answer.

For example, consider the following question:

"Am I wearing a hat?"

Seems pretty easy, right? No logic, no memorization, no trivia, no knowledge of any specific topic is required.

So ... what's the answer? Take a few minutes, think about it, write it down on a piece of scrap paper. I can wait, take your time ...

What's that, you say? You can't answer that simple question!? Why not? I stated it very clearly, it requires a simple YES or NO response, there's nothing tricky there. So, why would anyone have any trouble giving an answer to something so basic and simple?

The reason, of course, is because you can't see me. You have no way of knowing what I am wearing because I did not provide you enough information! As simple as it is, it cannot be answered; therefore, it is not a proper question!

Suppose, instead, I provided a picture of myself and asked "In this picture, am I wearing a hat?" And, in the picture, my head is clearly visible and the fact that I am wearing a Boston Red Sox cap is very clear. Would you be able to answer the question in that scenario? Of course! Suddenly, what was an impossible question to answer became very simple!

How did that happen?

It happened, of course, because I provided you enough information to answer the question! And that is the often problem with many of the questions we see day to day in forums asking for help. You cannot expect an answer unless you provide a proper question with all the necessary information. The majority of the effort by those helping others in these forums is not spent answering questions, it is spent trying to figure out what the heck the question actually is! And that is the problem; people don't seem to realize that they can't just randomly cut and paste code or ask vague questions without any context and expect to receive help!

Yet, requesting more information and details doesn't always go over so well ... Those looking for help seem to often have trouble understanding why the helpers need more info, why are they are so "anal" and "demanding" about minor things like database schemas, or sample data, or code samples. "How is that important?" they wonder. "Just answer the question and provide me with some help, please! An expert would know the answer!"

My goal today is to hopefully help you to understand why information and context is so important for even simple, basic, questions, and how providing that information suddenly transforms a poor question into a very good one that can be quickly and accurately answered.

Let's try another example:

"How do I get from work to Fenway Park?"

So, what do you think? Is that a good question that provides all of the information? It seems simple, right? It is just asking for basic directions. Yet, where is "work"? Is it asking for driving directions, or walking directions, or maybe which subway lines to take? Who knows!!?

As stated, this question simply cannot be answered! Yet, if I just thought about it a little and made sure to provide all of the necessary information, this "impossible" question with no answer suddenly becomes a very simple one:

"How I do get from 125 High Street, Boston, MA to Fenway Park via the subway?"

See the difference? Instead of just assuming that everyone knows where I work and what mode of transportation I am looking for, if I make sure to simply tell them, there is no uncertainty, no confusion, no guesswork, and the question can be answered. This isn't rocket science, right? Yet, these common-sense basics seem to elude many, many, people!

Would you drop your car off at a mechanic with a note on it that says:

"Car doesn't work. Plz fix. It is urgent! Thx!!"

I sure hope not. You'd explain what's wrong, right? It has trouble starting, it has a flat tire, there's smoke coming from beneath the hood, the steering wheel fell off, and so on. It's basic common sense that you would do everything you can to be sure that the mechanic has the information he needs to fix your car correctly and promptly, right? Shouldn't that same logic also apply when asking for help in forums?

Finally, let's try a SQL Server question:

"What is wrong with teh codez? it does not work! Plz Help!

select SaleID, Customer, Qty, Price
from SalesNumbesr

Thnx!"

Take a look at that question. It is a very simple SQL statement, right? There's nothing there that a beginner could not understand. Can you "spot" the problem and fix it?

Hmmm ... maybe you can, maybe you can't. You can't really be sure, can you? At this point, we can all try to guess what the problem is. What does "it does not work" even mean? Is "SalesNumbesr" a typo? Should it be "SalesNumbers" ? Is it returning too much data? not enough data? Incorrect data? Is it generating an error? And so on.

We could spend all day trying to guess what the question is and provide answers to those guesses, but if the guesses are wrong, the answers won't be so helpful, will they? On the previous question, what if you guessed that I work in Cleveland and provided directions for me to Fenway Park from there? Would that be helpful to me? Probably not, right? Most likely, it just wasted everyone's time.

So, getting back to the code .... what is wrong with it? Well, in SQL terms, the answer is: NULL! It does not exist. Until we are provided with more information, the question cannot be answered. Thus, it is not a question at all, just an incomplete fragment. As simple as the question looks, as basic as the T-SQL is, this "question" will stump even the greatest "experts" out there because an answer to this question simply does not exist.

If more information is provided, like this:

"Hi -- I currently have the code below:

select SaleID, Customer, Qty, Price
from SalesNumbesr

I would also like to return the total Amount for each Sale, which is the Qty multiplied by the Price. However, I am not sure how to add this to my current code. Can anyone please help?"

Suddenly, the question now is very clear and the answer is very simple! They just want to know how to add an expression to the result set. Just by providing a little more information, and not assuming that everyone knows what is happening outside of the context of what was written, something that was impossible to answer has become very easy.

I sure hope this is making sense.

In fact, taking this whole article to its logical conclusion, I think we can safely say:

"The more accurate and detailed information a question provides, the more accurate and detailed the answers will be."

In other words, a vague, incomplete question can only get, at best, vague, incomplete answers. But a question that spells out the entire situation very clearly will get, at best, a very clear and specific answer that works in that situation.

So, please, think of this when you ask questions in a forum. Consider the fact that no one knows your specific environment, or code, or application, or database except for YOU. And, no one can help you unless you are providing enough information for them to do so.

Just like the mechanic. Or someone giving driving directions. Or a doctor when you are sick. You provide them with the necessary information so they can help you, right? Consider doing the same to those providing you with (free!) programming advice.

. . .

(Feel free to provide this link to those who seen to have trouble understanding that you cannot read their mind when assisting them with programming help on forums.)

You Know, There's a Much Easier Way...

Jeff Smith — Thu, 13 Mar 2008 18:51:11 GMT

Let's say you are struggling on a programming project. Your code is growing exponentially and becoming more convoluted by the day, and it is clearly out of control. You're getting run-time errors, compile-time errors, wrong output, no output, endless loops, your machine is overheating, and perhaps you are starting to feel like you might be a little over your head. Maybe this is the first time you are using a particular programming tool or language, or it's the first time you've worked with a particular database, or maybe it's your first complicated project overall in any technology and you're getting hopelessly lost.

So, it's come to this: it's time to swallow your pride, and ask for help.

Maybe you decide to visit a programming forum online, or maybe you have coworkers or colleagues or an old college professor that you can contact for help. Either way, it is time to get to the bottom of this. You have deadlines that you are getting dangerously close to missing. People are starting to doubt your abilities; heck, you are even starting to question them yourself.

However, you are not a "clueless newbee". You know how to break down the problem and explain the specifics in detail, so that makes it much easier for others to help you. You have specific questions that you need answered, not just general "how to write a query?" questions. Asking for help may not be ideal, but if you can get the right person to assist you, it should produce results and really get you back on track.

So, you post your question. You've explained it well, and two pieces of advice come back.

Advice #1:

"Ah, a challenge! Here's a pretty hacky idea that should work; cut and paste and try it. It's about 85 lines long and you'll need to create 4 auxiliary temp tables, and you'll have to manually handle a few other situations that I didn't account for but this should serve as a guideline that you can expand upon. It will probably be slow and inefficient and maybe a little buggy, but overall, it should fix the error you are getting and give you the result you need, at least in the short term."

Advice #2:

"You have a poor design that is really making what should be really simple nearly impossible. Just break out these two columns into a new table to normalize your design, use the correct data types, do the formatting at the presentation layer, and all you need is this one simple, single line of code which will do exactly what you want."

What would you do when presented with these options? How would you respond?

The Common Response

Let's look at the most common reaction to this scenario.

First, you consider advice #1. You've looked at his code and it is ingenious -- at first glance you can't understand a single line! It take about 2 hours to really process what he is doing, and a lot of it still is way over your head, but some of the hacks and tricks look pretty darn cool.   It isn't perfect, but it should do the trick. A little tweaking and maybe some cutting and pasting to handle a few other cases you didn't specify and you should be back in business in no time. As for efficiency, that is not a factor here -- you just need the darn thing to work! You can always optimize later.

As for advice #2 -- WTF? "Normalize?" What a bunch of crap -- theory is great, but you have a project to complete.   Who does this guy think he is preaching to you like that?   The first response was helpful and solved your problem -- this one is just a waste of time, someone trying to stroke his ego online and demonstrate how smart he is. And he is really trivializing your problem! To suggest that you have a "poor design" and that a single line of code that anyone could write will solve the issues you've been struggling with for weeks is an insult to you as a programmer. Thanks, but no thanks, jerk!

A "Radical" Alternative

Let's take a look at an alternate way to respond to the two pieces of advice offered.

Regarding advice #1: Yikes ... if that's what it takes to solve this issue, there must be a better way... This approach may work, I suppose, but now my already impossibly messy code will get even worse and this will be a nightmare to maintain. I must be doing something wrong if this is the best solution anyone can offer.

As for advice #2: Wait a minute -- there's an easier way to do this? This is the best news I've heard all week!   "Normalizing" -- I've heard of that, I should look that up to make sure I get it. And using the right data type instead of strings everywhere -- kind of new to me, I never thought of the importance of it, but if it helps and I can solve this thing in only one line of code, it is probably something I should learn about and try. It would be really sweet if I could simplify this whole system by simply making some changes to the design -- which I know is a mess. It might be a bit of work, but it should be much less work in the long run if I can learn a few things about database/application design, and eliminate most of this crappy code I've been working on for weeks and replace it all with boring, simple, easy to read and maintain code! I knew there had to be an easier way!

Which Approach Do You Take?

So, how do you respond when someone suggests that you learn a new technique? Do you listen and consider the advice, or do you immediately reject it? If someone recommends a "best practice" for you to follow, do you immediately assume that you are being preached to and spoken to condescendingly, or do you research the idea to see if it will help you? If someone comments that you've made poor design decisions and recommends an alternative, do you get defensive and refuse to even ponder the possibility?

If I personally am struggling with anything, and someone offers to teach me an "easier way" -- well, for some crazy reason, and unlike a lot of people -- I listen! And I listen with an open mind and really try to consider the approach described to me. It may not ultimately be any better than what I am doing now, and in fact it may be very poor advice, but I at least listen to it and consider it. The news that there is a "better way" to some people is an insult and upsetting; to me that's the best possible news I could hope to receive!

I think there's an odd mentality that programmers have when asking for help: "Even though I am asking you for help, I am still smarter than you!"   I find the opposite approach works better: Assume you have something to learn from everybody, whether it is programmers on an online forum or people you meet face to face at a cocktail party. You might be surprised at what you can learn if you have an open mind.

At my very first job years ago as a dishwasher, there was a sign hanging in the restaurant's kitchen that read: "Why is there never enough time to do a job right, but always enough time to do it over?" And it's true in programming much as it is in the food service industry. You might argue that altering a key design decision this late in the game is not possible. Well, in some cases, it may not be -- you've got to get it done and live with your decisions. However, it is always worth 5-10 minutes to at least consider a new approach to your problem, and maybe even give it a try. In fact, you might even learn a little something if you listen to advice that aims to improve your knowledge and skills as a programmer with a nice side effect of also simplifying your code, instead of complicating it.

In short, if you are struggling with your code, there usually is an easier way. The hardest part is often simply acknowledging it.

see also:

An INT primary key .... yet not an Identity?

Jeff Smith — Thu, 21 Feb 2008 17:08:46 GMT

Ah, this is not an anti-identity rant, don't worry!

Though, in a round-a-bout sort of way, it is yet another argument against always blindly using them -- but not in the way you might expect.

There is a simple rule I'd like to propose, let me know what you think:

"If your client code, SQL code, or configuration files reference the primary key column of a table to determine any application logic, that primary key column should not be an identity."

Now, I am not saying that primary key column can't be a meaningless integer. I am just saying it should not be an auto-generated meaningless integer.

Working with an inherited web application (in "classic" ASP .... yuck), there were lots of tables like this:

groupID, groupName
1, Administrator
2, User
3, Finance User
5, Account Manager
8, ReadOnly

and there was lots of code written like this:

if groupID = 1 then show delete button
if groupID =3 or groupID=5 and groupID != 8 then show the create new project button

... repeated everywhere, throughout the application and in the SQL code.   Yet, the groupID column was an identity.   I discussed a similar issue here, but this is a slightly different approach.   In this case, let us assume that we really want to -- or need to -- embed that "groupID" value everywhere in our code. And we want that table to have an integer primary key to keep things short and simple and precise in our database code. That's all fine, it happens, and it certainly is common.

But why does that groupID need to be an identity?

For static, non-changing system tables, why assign an identity primary key? Why not just make it an integer? And once a year or so when someone adds and entry to this table (usually manually, behind the scenes with an INSERT command or opening the table directly) what is so bad about having them manually "figure out" the next ID to use and manually insert it?

The database will always have that primary key constraint on the column -- we don't gain any integrity by using an identity. We just gain ... well, what exactly do we gain when the table is static?

The advantage of not using an identity is this: if we wish to confer meaning on these ID values, we have complete control over them. Moving from one system to the next means we can just copy them over and we don't need to worry about setting IDENTITY INSERT ON and things like that.   We don't have to worry about gaps in the sequence or re-seeding the tables. We can guarantee that we have complete control over these values, and they never will be created anywhere unless we explicitly create them.

If we do use an identity, that's great the next "ID" will pop up magically, but what good does that really do for us in this scenario? I understand that when an order is generated, or a customer is added, or for things like that, an IDENTITY is the way to go. But for static tables, I really honestly don't bother with an identity. Just put an INT primary key on there and you are good to go.

The reason I bring this up is as the result of a mini-debate with another developer. If a system table such as "Status" will only ever have 3 values, and we wish to assign each of those values an integer "ID" as a primary key, why bother with an identity? Why not just use a standard, non-auto-generating integer column as the primary key?

Do the pros of an identity in this situation outweigh the cons?

Then again, I am a bit of a control freak, I admit ... But I think that key values in your data tables that your applications and systems rely on are a pretty good thing to have control over.

(Another minor point oft-overlooked: Don't forget about considering the use of tinyint or smallint data types for these columns as well. )

Why use Google when a better, more accurate, and more powerful "search engine" exists?

Jeff Smith — Thu, 17 Jan 2008 19:56:37 GMT

Raise your hand if you've ever done this:

At a programming forum that you regularly visit, you see a post asking for help
The post describes a situation that you may not intimately familiar with, or that you know has been covered elsewhere many times, and it is clear a quick Google search will find a good answer.
So, you think of some good key words, perform a few quick searches, examine the results, and determine which of your findings is a good answer for the person asking for help. It doesn't take too long, only a few minutes or so.
You then post a response to the user with the URL of the page that provides their answer. There may even be a few different pages that have good info, so you might even provide a few good links for them.
Alternatively, you might even summarize the findings yourself and provide a solution that doesn't even require for the user to visit a web page. You may even incorporate some of your own thoughts and ideas on the topic based on your experience.

Anyone who ever tries to help or share knowledge in a programming forum probably finds the above familiar. I think we've all done this. As I wrote here, often the people who are "smart" and "intelligent" and who "know all the answers" are really just the people who aren't too lazy to read manuals or help files, or to do simple internet searches.

The other day, after once again going through this process, it got me thinking ... just what the heck is happening here? Who is really the intelligent person in this scenario?

I mean, think about it: Many of us have learned where and how to find answers, and we check reference books or help files or do web searches, and we read and interpret the materials and eventually find the answers we need. It is not always easy -- sometimes we need to read through different books, or try different search terms, or read lots of lots of text just to get that quick and often simple answer. We are quite proud of this and consider ourselves much better off for knowing where to find answers on our own.

However, consider the other side of the equation. Why bother with Google, or help files, or programming manuals, when you don't need to? Why not simply use the most intelligent search tool that exists? A search engine that flawlessly parses your (mostly) English sentences (and politely asks for clarification if it cannot!), knows how to pick out key search terms, checks all kinds of varied and sometimes obscure resources, and then actually reads and interprets those resources to provide perfect links to web pages for your needs -- often with extra information and instructions and logically derived guidance and advice!

Who wouldn't use that tool if it were available? Well, guess what -- it is!

This amazing search engine is: People like you and me!

Are the "newbies" really that clueless? Or are they using the best technology available to quickly get amazingly accurate and detailed results? Why bother with Google when someone else is willing to do it for you? Why go through dozens of search results when someone else will do it for you? Why ever learn how to find anything when you never need to?

Don't misunderstand me -- this does not apply to all forums and all people asking questions. Many, many questions really are appropriate for a forum, and the answers may be subjective or subtle or require some "back and forth" to determine the best course of action. Those questions make sense, are fun and interesting to read, answer and debate, and they provide good knowledge for all involved. It questions like "what does the SUBSTRING() function do?" and "how to check for null?" that I am referring to.

I often feel that these folks know perfectly well that Google is out there, and how it works, and how to access help files and documentation -- but they are much more practical, and much craftier and efficient than you or I! Why bother with a mechanical, stupid search engine that requires "lots of work" when there exists an amazingly intelligent and accurate resource that you can use instead?

Perhaps the real question is: how much good is it really doing when we blindly do the legwork for others? How does this affect/benefit the overall community that the forum of our choice serves? Are we really training and guiding those who are working hard to be a positive and contributing part of the community, or are we weakening it overall by enabling those that probably don't have what it takes to be members in the first place?

Maybe best response to some of these questions is really:

"You have two options: learn how to find the answer on your own, or find another line of work that does not involve programming computers in any way."

Wouldn't that be the most productive answer for all involved in the long run? Can someone who doesn't have the diligence or skill to find answers on their own ever really succeed in this line of work?

(Update: A follow-up has been posted here. It might be helpful to read that first before commenting ... )

The Mailbag: Referencing Assemblies in Reporting Services; some SQL help

Jeff Smith — Thu, 18 Oct 2007 16:19:54 GMT

As David Letterman would say, wake the kids, call the neighbors, it's time for The Mailbag! Just some quickies today.

Christopher writes:

Greetings Jeff,

First and foremost, great job with all of the blogs. I have a questions
that I cannot seem to get a straight answer for. I am working with SQL
Server Reporting Services (SSRS) and have the need to create VB
functions to customize the reports generated. For example, a setter/getter to
display information that would not be readily available from the
query. SSRS allows this type of custom Visual Basic code to reside in the
report itself, but since most of my code is across multiple reports, it
makes 0 sense to place the same code in each report. Do you know of a
way that I can create a "code library" so that there is one location for
all of the code and all of the reports can access it?

Thank you very much for your time and effort.

Sincerely,
Christopher McGraw

Chris, Here's all the information that you need: Using Custom Assemblies with Reports (from SQL Server 2005 Books On Line). I can't really add much to it -- it explains everything in detail.

Traner writes:

I have two tables, table1's primary key is table2's foreign key.
Table2 has multiple dates that relate to table1.

ie.

Table1 : Table2
JOE : 10/18/07
DAVE : 11/14/07
JOE : 11/27/08

I am trying to get highest date from table2 related to table1. Do you
know how this can be accomplished. Any assistance will be greatly
appreciated.

That really isn't the clearest way to convey your schema, but I think I know what you mean. Let's assume that Table1 has two columns, ID and Name, and that table2 has 3 columns, ID, Date and Value.

First, to get the highest date per ID, you simply use the MAX() aggregate function along with GROUP BY when selecting from Table2:

select ID, Max(Date) as MaxDate
from Table2
group by ID

Be sure to read up and practice with GROUP BY and aggregate functions if you are not familiar with them -- they are very powerful and very fundamental to SQL.

Now, you can select from Table1 and join to the above SQL statement in a derived table to return all rows from Table1 and the maximum date from table 2:

select Table1.ID, Table1.Name, t2.MaxDate
from Table1
inner join
( select ID, Max(Date) as MaxDate
from Table2
group by ID
) t2 on Table1.ID = Table2.ID

As you can see, we have enclosed our previous SQL statement in parenthesis, and assigned it an alias ("t2" in this case), and we can join to it and select from it just like any other table. So, we have simply selected from Table1 and joined to a summarized version of Table2 that only returns the maximum date per ID.

Finally, notice that all we are returning from Table2 is the date; if there are other columns from Table2 that we wish to return (for example, the "Value" column), we must add another join to Table2, that returns only the row with the maximum date per ID:

select Table1.ID, Table1.Name, t2.MaxDate, Table2.Value
from Table1
inner join
( select ID, Max(Date) as MaxDate
from Table2
group by ID
) t2 on Table1.ID = Table2.ID
inner join Table2 on t2.ID = Table2.ID and t2.MaxDate = t2.Date

Notice that the "on" clause indicates that we are joining on ID as you might expect, but also on MaxDate = Date, so that we only return the row in Table2 that has the maximum date per ID.

If you are using SQL Server 2005, this can be done a little easier, with only one join, using the new Rank() function:

select x.ID, x.Name, x.Date, x.Value
from
(
select Table1.ID, Table1.Name, Table2.Date, Table2.Value,
rank() over (partion by Table1.ID order by Table2.Date DESC) as Rank
from Table1
inner join Table2 on Table1.ID = Table2.ID
) x
where x.Rank = 1

More on Rank() and partitions here. Hope this helps you out.

Is it a String Literal or an Alias?

Jeff Smith — Thu, 30 Aug 2007 15:36:25 GMT

Every now and then I see T-SQL code written like this:

select somecolumn as 'columnname'
from sometable

Notice that 'columnname', despite its appearance, is not a string literal or a string expression, it is the alias that we are assigning to the column somecolumn. Putting the name of an alias in single quotes in T-SQL is completely valid syntax, and it will work fine, but I feel that it is a really bad practice. It makes the distinction between string literals and object names very blurry, and it can lead to confusion when examining and maintaining your code.

For example, to me this is difficult to quickly look at and digest:

select 'literal' as 'columnname'

columnname
----------
literal

(1 row(s) affected)

It just makes your code harder to read, especially if syntax highlighting is used, since we no longer know at a glance what is a string literal and what is not. Of course, it gets even more difficult when you are dealing with long, complicated SQL statements.

It gets even worse when you consider that using "as" is optional when assigning an alias. For example, this is perfectly legal as well:

select 'literal' 'columnname'

columnname
----------
literal

(1 row(s) affected)

I don't know about you, but I would hate to inherit a database full of code like that!

Allowing the string literal delimiter to be used also implies to beginners that variables or other expressions can be used in place of column aliases, since they look like string expressions. Perhaps that is why now and then we see code like this:

select 'literal' as 'columnname' + @variable

That would of course make the misguided "generate dynamic column names" people very happy, but thankfully is not allowed.

Interestingly, while you can write column name aliases with the single quotes, you cannot alias tables or derived tables that way:

select * from
(
select 'jeff' as colname
) as 'test'

Server: Msg 170, Level 15, State 1, Line 4
Line 4: Incorrect syntax near 'test'.

Which is certainly a good thing, but now perhaps a little inconsistent.

My advice? Don't delimit column aliases the same way you delimit string literals -- either do not delimit them at all, or use square brackets like [this]. This will help to distinguish your data from your code, and make things a little easier to maintain in the long run.

see also:

SELECT * FROM TABLE -- except for these columns

Jeff Smith — Thu, 26 Jul 2007 19:36:23 GMT

A occasional question seen in the forums, which was just recently asked today, is:

"I know I can use

SELECT *
FROM table

to get all of the columns from a table, but is there a way to write

SELECT * minus columnX
FROM Table

to get all of the columns except for certain ones?"

Now, my goal isn't to debate whether not "SELECT *" is bad or good or should be used or not. The fact of the matter is, people use it all the time because it is quicker and shorter than typing out all of the column names. People are lazy, right? (myself included.) And these lazy people often would like to return all of the columns from a table except for one or two without typing them all out. So, why isn't this concept allowed? Would it make any sense?

Here's my usual response:

First, the answer is no, SQL does not support that. You must specify what you want.

Second, if you ask me "why not? It would be great!", let me ask you this in return:

"If SQL did support that syntax, and you executed

SELECT * minus ColumnX
FROM Table

but columnX did not exist in that table, what should happen?"

I think it's kind of an interesting thing to think about. Should an error occur? Or should it just happily return the results, since we didn't want ColumnX anyway? Maybe it should issue a warning? I really don't know ... Would we all ever be able to agree on a definitive, logical way to handle this?

Here's another way to think about it: What if there were a command called "DontExec" that simply didn't execute the stored procedure specified. What should happen if you call DontExec on a stored procedure that doesn't exist?

That sounds kind of silly, I know, but it is the same basic thing to consider as if you had a "* minus Column" option in a SELECT statement. Shorter to type? Sure. Does it make any sense? Not really.

By the way -- the third part of my response is usually this: the easiest solution is to simply use SSMS, QA, or EM to assist you in building your column list by using the scripting features or the query builder if you don't want to type it all out.

(UPDATE: As Denis points out in the comments, it's actually even easier. Now you really have no excuse to use *. )

Becoming a Better Developer, plus a SQL Crime Drama!

Jeff Smith — Thu, 26 Jul 2007 14:36:37 GMT

Sorry for the delay, Denis; thinking of ways to improve our developer skills is a great idea, thank you for including me. Here are my thoughts on the next 6 months.

More design, less code. I'm going to try to focus a little more on user interfaces, graphics, layouts, and so on. I tend to write boring, plain vanilla corporate-style applications that frankly aren't much fun. Sure, they work great (usually!) and the layout is clean and easy to use (hopefully!), but my goodness -- it is boring. I plan on focusing a little more on the aesthetic design of my applications and web pages in the next 6 months; not so much that it detracts from the usability of my applications, or that it bloats them, but so that I can consciously improve upon this aspect of my work.

Learn Flash. This kind of goes hand in hand with my previous point. I do lots of web development, but so far I have stayed away from Flash. Now, I think it's time to at least learn it. I am not a fan of flash-heavy sites, but when used well I can see the benefits. Also, lots of websites and pages and components that I am incorporating into our environment developed by outside companies are using Flash. So, if I can, my plan is to at least get familiar with it. Also, I plan on investigating just what Silverlight is all about. Looks interesting.

Learn other non-Microsoft technologies. In college I didn't learn a thing about any Microsoft product. It was all UNIX and JAVA and things like that. Since graduating many years ago, I have not worked professionally with much else, other than javascript and things like that. I'd like to really spend a little more time developing in some other languages, just to see what is out there and to help keep things in perspective. I love the .NET and Visual Studio and SQL Server, but part of me wonders: Do I really have enough knowledge of other products out there to form an unbiased opinion?

Delve more into VS/SQL 2008. These new releases seem to come out so fast, it's hard to keep up. I'm barely getting used to .NET 2.0 and SQL 2005! As others have mentioned, it's never too early to get a head start on technologies that have recently been released or that are coming soon.

Brush up on Design Patterns. I've read about most of them online and used quite a few of them, but I still don't have a full grasp on all of them and where and when they can be useful.

Write more SQLTeam articles! (Graz forced me to put this in)

and finally:

Be more creative and help others. I plan to finish up my screenplay for the pilot of "Chip and Dip": A gritty crime drama about a tough cop that doesn't play by the rules (Arthur Diptowsky, or "Dip") and his super intelligent computer (with a powerful microchip. Get it? "Chip"!) who solve crimes using SQL. A classic "buddy" concept. Look for it coming this fall on NBC! Will this make me a better programmer? No ... but it will help educate the world on the power of SQL, and that will make everyone a better programmer in 6 months. Beat that, guys! Makes you all seem a little selfish just focusing on improving your own development skills, doesn't it?

A preview:

Dip: Chip, we have to find the serial killer! There must a pattern. Who else has been murdered in this city the last 6 months?
Chip: Syntax error on 'Who'.
Dip: Damn you, Chip! We don't have time for this!
Chip: Syntax error on 'Damn'
Dip: You are a pain in my ass, you know that!? UPDATE Chip SET Annoying=True !
Chip: That is not funny. And also there is not a table named 'Chip' in the catalog.
Dip: Argghh!! .... SELECT Name FROM Victims WHERE Type='Murder' AND City = ...

Entertaining and educational!

Distinguishing data from code

Jeff Smith — Tue, 24 Jul 2007 13:02:43 GMT

What is data, and what is code? How do we define the difference, and decide what goes where? It is great to say "keep data out of your code", but what if that data is integral to the application itself? Isn't it therefore code, and not data? read more...

But WHY Must That Column Be Contained in an Aggregate Function or the GROUP BY clause?

Jeff Smith — Fri, 20 Jul 2007 14:33:29 GMT

Column 'xyz' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

Arggh!! There it is, yet again .. that annoying error message. Why is SQL so picky about this? What's the deal!? read more...