Adam wrote:

>Mitch,
>
>LOL, that is a neat little trick. I would personally advise against
>doing formatting on the database server. It is best done at the UI
>level where users region settings can be easily obeyed. By putting it
>at the database level, you force non Americans to use that strange
>m/d/y syntax, or confuse them with d/m/y syntax :)
>
>

Hi Adam,

You are absolutely correct within this context (dates).

I think the case statement would probably quicker, certainly more readable.

But either method would violate your personal rule mentioned above,
would it not?

I used this trick in a retail application to force leading zeroes in
front of product numbers (which are PK ID) fields in the DB, yet there
are those who have trouble discerning between '0012' and 12, or I should
say, seeing the equivalence of... that they are both, in substance,
valid and identical means of referring to the same thing.

Contrary to your philosophy, I hope to, as much as possible, centralize
logic such as this within stored procs and views in an effort to keep
the UI as lean and simple as possible and still maintain a somewhat
common interface to both the user and the developer among the several
client apps that will access the DB.

Depends on the implementation, I suppose, but I see nothing at all wrong
with formatting certain attributes at the server. in fact, I try to do
it every time that I can, when it is appropriate.