I'm sorry to say this, but this is not a very good example. I'll refrain from getting angry and hit the points one at a time:
a) It does not matter what kind of audience you are targeting, you should never put SQL code in any kind of page event handler. SQL code should be put in a Data Access Layer, REGARDLESS of how simple the sample is.
b) You should NEVER hard code connection strings into the forementioned Data Access Layer. Connection strings should be placed in a web.config file, and accessed through System.Configuration.ConfigurationSettings.AppSettings("ConnectionString"). In a sample, use those kind of references, make a comment to put a key in the web.config file, and give an example in comments of what the key should look like and where it should go.
c) When writing code that accesses a database, you should always ask yourself, "If I change a table or column name, whould I have to recompile my application?" If that answer is anything but an absolute "no", you're not finished separating your data access logic from your user interface. The code in the sample is not maintainable at all, because if a table name or a database location changed, you've have to propagate those changes all the way up the UI.
d) In the paragraph before your code, you talk about using the "Imports" directive to save you from having to write a bunch of code. My question is, why did you not then use it in your example? What was the point in saying it then, if you were just going to NOT use it?
e) Instead of using all that "Response.Write(
)" garbage, which does nothing more than make your REAL example code harder to see and understand, why did you not just use a DataGrid?Now, had you given your readers a complete sample of what the page would look like, with <% @Page %> directives and everything, then you could have thrown a DataGrid control on there and saved yourself about 17 lines of code. What you accomplished instead is the further confusion of your readers.
I'm trying to be as nice about this as I can, but the bottom line is, if you're going to take the time to write up something like this, you should at least make sure it is:
a) technically accurate
b) consistent with your article dialog
c) A ROCK SOLID EXAMPLE OF BEST PRACTICES
Otherwise don't bother. There are enough examples of bad code out there. I'd hate for you to ruin your own good coding name AND mislead others by writing bad code. Would you want to have to be the one in charge of maintaining that code? I sure know I wouldn't, that's for sure.
