In the good old days identifiers were always UPPER_CASE and I prefer to
retain that convention. Using lower case when writing scripts was
possible, but keeping to the UPPER_CASE version made everything
consistent, and as I remember dBase would use any valid UPPER_CASE
character set as long as you did not try and mix them.

People kept pestering for upper and lower case, and the "MiXeD" method
seemed a way to go, but I never saw any strong reason that it was
actually NECESSARY. It was pure aesthetics and of little practical value
as no one in their right mind would use "UPPER" and "Upper" as two
different fields (would they?). But mixing it up with allowing reserved
words to be used as well such as "DATE" further muddies the water.

My Tikipro Firebird Port is all "quoted" simply because of the reserved
word problem, but non-Firebird ports are now seeing that using reserved
words as field names causes other problems ;) The difficulty is that no
engine ACTUALLY follows the SQLxxx rules for reserved words so we can't
have a standard list we can all follow :(

Simply because something CAN be done is no reason that it should be
done, and some radical simplification of things would help, but living
in the real world we have to cope with those 'Experts' that know best
and simply love to make things so complex that their pay packet is secure :)

The starting point in all of this is WHICH character set do you use, and
a move to standardise on UTF-8 seems quite strong.
http://www.cl.cam.ac.uk/~mgk25/unicode.html provides a nice summary -
linux based, but most applies equally to Windows. It seems a little out
of date as it even highlights the UTF-8 6 byte sequences, but it does
seem to be a very useful reference doc. Given that Unicode provides a
defined UPPER_CASE conversion is also a good start - even given the
minor gray areas :)

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services