Hi Mitch,

> 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?

Yes it would. I was not pointing out that your method was somehow
worse than the cast method, in fact I was impressed by the creativity
there when I took a look at how it worked. I was rather pointing out
that server side formatting (as a philosophy) has real issues with
different date formats. I am very used to American date format
because the string literal I often use in Firebird is m/d/yyyy.

If I talk about what happenned on 8/4/2005, half the list would be
thinking back to the other week and the other half wondering about
April.

>
> 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.

Then comes the tricky part, currency, do you put a $ or a E (my
keyboard doesn't have a euro thing), or a pound sign (missing that
too). Do you comma separate the thousands and display the cents, or
do they think that a comma is what separates the cents from the
number. Do you preceed the number with a '-' if it is less than zero
or do you place a bracket around it.

When it is returned to the client application and you want to make a
total row at the bottom, do you then have to cast it back to a double
or something (the operation may be a bit more complex if they use a
different regional settings setup)

It certainly does depend on the implementation, and I am personally
talking from a Delphi background here. I have a common unit with
FormatTimestamp and FormatCost routines to define a standard (in fact
Delphi has built in DateTimeToStr functions). Even so, we have a
custom edit box for currencies that accepts a double and formats it
according to your region settings, so we tend to just pass around the
raw datatypes.

Just some thoughts
Adam