Heiko,

<< Don't get me wrong, I didn't want to say that ElevateDB has no benefit
over DBISAM, it has nice new features that even with my little experience I
already like very much, it is way more powerful. >>

No problem - I didn't take it as a sleight to EDB.

<< What I see "absolutely no benefit" in is strict SQL2003 compliance, which
is causing me lots of work and after that my app will (hopefully) do exactly
the same as it does now. >>

The issue is that some of these things are not just issues with SQL2003
compliance, they're SQL92 and SQL99 compliance issues also.  IOW, DBISAM's
been going against the standard in favor of BDE/Paradox compatibility since
it was first written.

<< I can guess that for the majority of your customers SQL2003 compliance is
a must have. >>

No, not really - it's more the general SQL compliance mentioned above.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Just to explain a bit more one of the reasons I feel more than a fraction
disappointed about this - I have been asking at intervals about this
particular feature since you said it would probably make it into V2 - that's
somewhere between 4 and 6 months by my count and from your posts I STILL
DON'T KNOW. >>

A word of advice:  if you're going to proceed to take the fact that I'm
trying to be accomodating to you and throw it back at me, then I'm probably
not going to be very receptive to your needs.  I didn't plan on making such
a change, so it's a major change to the *design of the product*.  This isn't
a simple matter of adding a property.  This is something that should have
been decided initially, and it wasn't.

I just got 2.0 released *last week*, and it was already over 1 1/2 months
late.  Give me some time to deal with more pressing issues, and I'll see
what I can do.  I'm juggling a lot right now, and on the scale of things,
this NULL issue is *way* down the list.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>A word of advice: if you're going to proceed to take the fact that I'm
>trying to be accomodating to you and throw it back at me, then I'm probably
>not going to be very receptive to your needs.

Remember I don't know what's going on in your head. I can only make judgements based on the interaction we have on this newsgroup, and via emails. If you review the various posts then your interpretation may be accommodating, mine was stalling. If you say you're trying to be accommodating then on your past performance I believe you.

>I didn't plan on making such
>a change,

Now there's a statement that's wonderfully open to misinterpretation

>so it's a major change to the *design of the product*. This isn't
>a simple matter of adding a property.

I appreciate that which is why I asked at intervals if it was going to happen and when rather than posting every couple of days demanding it.

>This is something that should have
>been decided initially, and it wasn't.

I thoroughly agree, it should have been decided initially to have NULL = emptystring


>I just got 2.0 released *last week*, and it was already over 1 1/2 months
>late. Give me some time to deal with more pressing issues, and I'll see
>what I can do. I'm juggling a lot right now, and on the scale of things,
>this NULL issue is *way* down the list.

Tim, I wasn't asking you to do it now, or even tomorrow.

What I was asking for, and didn't get was a categorical answer if it would be done, and some idea of timescales ("*way* down the list" is probably a bit long to wait).

Anyway I've decided I'm going to take the hit of about an extra weeks work to sort my app out without this feature.

I feel that from a viewpoint of people transitioning from DBISAM its still worthwhile looking at, and even if you don't go the whole way what about

In SQL Server that is dealt with via 'SET CONCAT_NULL_YIELDS_NULL' which
only impacts on the CONCAT function and resolves this issue in a
compartmentalised way without subverting SQL logic entirely.

and a flag for table and querys that would alter emptystring to NULL on post (please don't suggest setting up triggers for each field).

Roy Lambert

Roy,

> Also think of explaining to end users who frequently don't give a
rat's arse if its unknown....

Easy. Widgets cost £10 each, ergo:

1 x Widget = £10
0 x Widgets = £0
NULL x Widgets = 'How the hell should I know?'

....I have yet to encounter a user incapable of grasping the difference
between "unknown" and a known value that happens to be semantically
"zero" in context (be it FALSE, BaseDate, EmptyStr, Midnight or whatever).

If you don't like the CONCAT idea (and frankly I don't ...I hate 'SET'
commands like that) then how about a different operator? It seems like
there is only one case that bothers you and that could be solved by
defining something like '&'[1] as an alternative to '+' which
automatically coerces NULL arguments into base values.

Eryk

[1] I can't remember if the '&' operator is already reserved, but this
isn't important to the overall point.

Eryk

>Easy. Widgets cost £10 each, ergo:
>
>1 x Widget = £10
>0 x Widgets = £0
>NULL x Widgets = 'How the hell should I know?'

Are you sure? I thought it was how some electricity companies worked out their bills (eg the latest £90m in Cambridge)

>...I have yet to encounter a user incapable of grasping the difference
>between "unknown" and a known value that happens to be semantically
>"zero" in context (be it FALSE, BaseDate, EmptyStr, Midnight or whatever).

Ignoring for a moment that I was referring to explaining having to type COALESCE(surname, '') rather than surname, and bearing in mind how long it took to get the very idea of zero into the public consciousness you've been very lucky.

>If you don't like the CONCAT idea (and frankly I don't ...I hate 'SET'
>commands like that) then how about a different operator? It seems like
>there is only one case that bothers you and that could be solved by
>defining something like '&'[1] as an alternative to '+' which
>automatically coerces NULL arguments into base values.

It is a good idea. This is the specific issue that sticks in my craw. I also hate, loath and detest the fact that there are two languages in a single app which treat the data in different ways, and that rowwise and columnwise operations are different. Add to that presentational difficulties and it makes me wonder about the sanity of the standards setting body.

>Eryk
>
>[1] I can't remember if the '&' operator is already reserved, but this
>isn't important to the overall point.

Roy,

> Ignoring for a moment that I was referring to explaining having to type COALESCE(surname, '')
>ather than surname, and bearing in mind how long it took to get the
very idea of zero into the public
> consciousness you've been very lucky.

Well, having to explain that to users presupposes that you have a 'SQL
injection attack' feature in your applications. You may block DROP
DATABASE via security settings but that won't stop the work experience
trainee firing off a nice big cartesian product query to trash the
server

As for zero as a concept, most people seem to grasp "0% pay increase"
and "0 days off" pretty easily ...and they also know it isn't the same
as "Unknown pay increase" (because it hasn't been announced yet).

> It is a good idea. This is the specific issue that sticks in my craw. I also hate,
> loath and detest the fact that there are two languages in a single app which treat the data in
> different ways, and that rowwise and columnwise operations are different. Add to that presentational
> difficulties and it makes me wonder about the sanity of the standards setting body.

Well, that is a much bigger topic and it starts with the fact that NULL
as a concept is a kludge invented to deal with the fact that database
engine vendors are incapable of creating engines that can perform
adequately with completely normalised data models (see
Date/Darwen/Pascal (Fabian)/Third Manifesto etc).

Eryk

Tim,

<< I'm juggling a lot right now, and on the scale of things, this NULL issue
is *way* down the list. >>

To my knowledge there's no NULL issue in EDB. I can hardly believe that
you've put such a nonsense request in your list at all

Ole Willy Tuv

Eryk


>As for zero as a concept, most people seem to grasp "0% pay increase"
>and "0 days off" pretty easily ...and they also know it isn't the same
>as "Unknown pay increase" (because it hasn't been announced yet).

That's brilliant, but now try explaining to the same worker that their pay increase is NULL

Maybe we wouldn't be having this discussion if they'd named it UNKNOWN not NULL

>Well, that is a much bigger topic and it starts with the fact that NULL
>as a concept is a kludge invented to deal with the fact that database
>engine vendors are incapable of creating engines that can perform
>adequately with completely normalised data models (see
>Date/Darwen/Pascal (Fabian)/Third Manifesto etc).

Please don't post things like this:

1. the children might see
2. it stops me working whilst I read

and more importantly

3. it stops me working until my head stops hurting.

Roy Lambert

> The other reason its a big deal is its not just me, it will also
> apply to a lot of people currently using DBISAM which I accept is not
> such a big problem now that Tim's going to keep it going.

The way I see it, DBISAM is more closely associated with the likes of
"desktop" databases like Paradox and Access (it was originally a BDE
replacement, right?), and EDB is aiming more towards the "small SQL
Server" crowd.  So there are going to be some major paradigm shifts.
But I think Tim has done an excellent job of bridging the gap.

> > This is exactly what would've happened in several projects I worked
> > on a few years ago. I was on a team writing lots of small survey
> > programs that asked questions of a sensitve nature. Every question
> > had to be answered, even if the answer was "I'm not going to give
> > you an answer".  We had to know if the question had been addressed
> > or if the person being asked needed to take a break and come back
> > later to finish it.  If we didn't have NULLs available, we would've
> > had to have an IsAnswered field for every single question--that
> > would've been a major pain. By simply checking to see if the
> > question had any kind of answer (not NULL), we could tell if the
> > question had been answered. Yes, some of those questions (fields)
> > had empty strings which were distinctly different than NULLs.
>
> Yeah. When I raised this issue way back you were the only person to
> provide a real life example. Mind you I'd prefer the additional
> column (BOOLEAN) option myself that way its easy to show to anyone
> reading a screen or a printout that the question was answered or not.

I thought I had explained this some time ago, but didn't remember when
or where or who.  Well, I guess you've got the story twice now!

> I don't know if your app had that sort of presentational requirement
> but if it did I bet that showing a checkbox beside each question
> would have been easier to code, and IMBHO better for the user.

But to address your ease of reading statement, I should point out that
we simply used colors to indicate whether a question had been answered
or not.  I think yellow background was unanswered, and the regular
clBtnFace was answered, so it was very obvious where the person
was--and they didn't have to go to the extra work of checking of a box
after answering a question--the program just knew.  These surveys
typically had 6-10 pages of questions with possibly 10-20 questions on
each page.  Having to click a checkbox for each question would've been
much more tedious than it already was.

And it was also actually simpler to code than to have even more fields
to deal with.  We did think of using the checkbox idea, but shuddered
at the thought and were very glad we could simply check .IsNull.

--
David Cornelius
CorneliusConcepts.com

>>Its not worth it because its wrong. NULL is a state and EmptyStr is a
>>typed value. NULL+'Fred' <> 'Fred', ergo EmptyStr IS NULL = False.
>
> Wrong is an interesting state in itself. I believe you mean it isn't in
> accord with the standard. I wonder if they did a cost-benefit analysis on
> that particular piece of the standard?

Roy, why not just create yourself a custom function, NONULL(Text) that
handles the case for you? Or Tim could add one?