Comment On Sql.Config

It seems there is nothing more WTF than looking back at your own old code bits...
;)

Thank god we didn't see this

<add key="sp_hi" value="exec hi;"" />

Stored Procedures would be way too logical of a replacement for that code.

What is wrong with this?
I'm asking seriously.
Assuming that he is using a DB without Stored Procs?

I've used this in the past, although with a resource file and no a config one.

Is this the security implocations?

It's hard for me to articulate what seems wrong about this particular approach, but I do know that if I had to change an existing query for some reason, it would hurt my brain.

The worst part for me is I reimplemented database stored procedures and parameters with String.Replace and the web.config file with about 30 queries. Being in the web.config made it a snap to tweak without recompilation, however.

My question though: would it even have worked the way it's listed? I mean, when I put "select [p.col] as Column from mytable as p" in SQL Server it errors out because it things "p.col" exactly is the column-name, including the "p."... What DBMS was this running against?

There's a whole bunch of R0ng with this.

Presumably, there's a data reader on some dataset extracted that matches EXACTLY the column names so changing the SQL without recompile seems mostly doomed, unless the change is so trivial it could have been avoided..

Also, the use of config key value lines is kind of crude. If a sytem is to be configured via the config file, wouldn't it be more elegant to create an attributed collection (config group or custom config) to then GetUserBy([This|That|Other\], ParamCollection) or something?


This does beg a stored proc, but hey, MySQL doesn't have them..

And the filewatchers on web.config will restart your application if you change it, so changing it willy nilly will kick out everybody's session variables.

This seems vaguely familiar from a project I worked on involving Commerce Server. It was classic ASP so it was stored in the global.asa but generally the same idea.

Well,

sadly in one of my solutions I had to provide such a mechanism, as two requirements were: Support both sql server and oracle, AND no stored procedures. Ended up with a custom configuration file with automatic attribute annotation etc. Nice API, useless but nice.

U got to love your managers decisions sometimes.