> Creating database systems iteratively is NOT silly. It's only silly
> if you get to the point where you are, discover your mistake, and try
> to solve it by creating a Band-Aid (like writing a UDF to extract
> numeric meaning from the contents of an ad hoc string).

What if I knew this and my clients didn't?
What if there wasn't any chance of letting them accept that they cannot
extract information after they make a lossy translation?

The choice would than be: lose clients, using a cast-like operator if it, by
chance, existed, or writing a UDF.

The point is here that I'm not designing a DB, and implementing a general
tool to generate data-entry programs for dump people.

When IBExpert was designed, and particularly its filter features, an
assumption was made on the understanding of the SQL implict overloading of
the "<" operator.
"<" : char(n) x char(m) -> boolean
"<" : varchar(n) x varchar(m) -> boolean
"<" : integer x integer -> boolean
are all different functions to me, as we all remember from our days of
non-playing basketball.

I'm not too surprised of hearing about "1976" < "876" whereas 876 < 1976,
and I'm not assuming any of you is ignorant enough to be surprised either.

Unfortunately the users of my system are going to be History of Art
Academics (there you go... live in Italy and try and be a programmer!), who
might not understand this.
However they might fill in all that sort of heterogeneous data in a varchar,
and still accept a numerical comparing criterium to return sensible data
only for... numbers!

So I thought that giving them the chance to try this, given they're not
going to be interested in sorting alphabetically some fields...

In a better world, if someone asked for something that cannot be achieved,
the group could reply "no, you can't". And if that someone asked "why?",
then the whole group's keyboards could rejoyce and send out all the
sermons...

As for me, given I'm not into basketball at all and I've attended all my
lessons when I was in school and later faced the world of
non-computer-scientists, I kind of assumed it could not be done in a quick
way, because on a well-designed DB you don't need such crap, and obviously a
DBMS is only requested to give the tools to achieve general tasks. I just
thought I'd give it a try.

I've already bought Helen's book, and I think it's absolutely excellent.
But may I say, you're much better at writing books than sermons? ;)
Thanks anyway, next time I have to design a two tables DB I'll come and see
you first... Just kidding! ;)

Rony