Roy,

> Wrong is an interesting state in itself.  
> believe you mean it isn't in accord with the standard.

Precisely so. 'Wrong' as in 'breaks the rules'.

> I wonder if they did a cost-benefit analysis on that particular piece of the standard?

There isn't much cost if you accept the standard behaviour from the
start and code accordingly. What *does* get expensive is maintaining
code that depends on global switches that alter fundamental logic ...the
horror that was SET EXACT ON/OFF in xBase comes to mind.

Eryk

Roy,

>> 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.
>
> IE they recognise either the standard is wrong, or that many people want
> to ignore the standard!

I didn't claim there was no 'use' for such functionality, just that it
should be implemented via functions like COALESCE or CONCAT, rather than
by redefining the basic logic of SQL.

Eryk

Hi Fons,

> Null is not equal to empty string - even when I did not uses database I
> knew this and used it in some of my own code (which had nothing to do with
> databases at all). So I am fine at how EDB currently is and given Tim's
> reply on the number of places code will need to change, I do hope it will
> remain how it is now.

Thanks for posting your opinion.
Roy and I posted some of the disadvantages caused by the current behaviour
of null-handling in or opinion.

On the other hand I am reading only theoretical arguments in favour of the
current behaviour. Please tell me which benefits you see in EmptyString <>
Null. I cannot see any.

Best regards Uli

I really think this is something best left untouched, unless there is a
large demand from developers not wanting the ability to detect when a field
is empty/not initialized or when a field is simply blank (I.E.  2nd Address
Line, which  mostly is blank).

NULL is in the standard and I think most of the enterprise level DB's use
NULL as well.

I think the approach has been great so far in being strict with the standard
as best you can. Rolling in some EDB specific expansions is great too,
though.  On one hand, by sticking to standard, you can migrate to (or if
need be from) EDB and have little ramp up or conversion.  You get too loose,
then you can start to create more work in trying to migrate to and from.

Lance



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:A8A212C9-4518-435A-9FF4-1C3AAA0D2517@news.elevatesoft.com...
> Roy,
>
> << As always my question is null=emptystring. >>
>
> Actually, I looked at this issue the other day, and forgot to post
> something.  It looks like it might fall in the "tear the whole thing up to
> provide a compatibility property" category.  The problem is that the NULL
> handling is in the generic "value" class that we use for *everything*  in
> EDB, and has no knowledge of engines, sessions, etc.  I would have to
> basically track down every single place where I create one of these values
> (columns, keys, parameters, variables, single-value result sets), and make
> sure that I set a flag to indicate that it should handle the NULL values
> like DBISAM.  On top of that, one also has to make sure that all
> applications involved in accessing the database also have the same
> engine-wide property set the same, or else you'll get wonky results (based
> upon the idea of setting the NULL flag once during an update based upon
> the length and forgetting about it).
>
> Frankly, I'm just not sure if it's worth all of the possible issues that
> it could cause.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Uli,

If I expand the schema, then its possible to detect using null states, which
records need special attention at any point.

Lets say I change login procedures like many sites are doing now, where if
you loose your password, you have picked a question and entered an answer.
When I expand the schema to add the Q and A, I can just leave them Null.
On next login, if value = NULL, then I go through the motion of forcing them
to set up a Q and A.   If the value is blank, then it could be that the
question is blank, but the answer may be to the blank question (I know...
odd thinking there).

I can also, just by using null, look to see in a personal profile, which
questions were ever answered, vs which ones maybee had something, then
cleared it out.

Granted, when you expand a schema, you may run through a routine that will
go back and put empty strings in the prior records.  But what if that fails?
Especially if there is a specific logic that either puts empty strings or
actual values in those columns?   By checking for NULL, I know that column
for that record has not been "initialized" and can take appropriate action,
if thats what is called for, to make it an empty string or propogate it with
something.

Lance


"Uli Becker" <test@test.com> wrote in message
news:177F2610-EDD3-47E3-B849-D8D2B8271D32@news.elevatesoft.com...
> Hi Fons,
>
>> Null is not equal to empty string - even when I did not uses database I
>> knew this and used it in some of my own code (which had nothing to do
>> with databases at all). So I am fine at how EDB currently is and given
>> Tim's reply on the number of places code will need to change, I do hope
>> it will remain how it is now.
>
> Thanks for posting your opinion.
> Roy and I posted some of the disadvantages caused by the current behaviour
> of null-handling in or opinion.
>
> On the other hand I am reading only theoretical arguments in favour of the
> current behaviour. Please tell me which benefits you see in EmptyString <>
> Null. I cannot see any.
>
> Best regards Uli
>

Tim,

Don't forget a Mac version of EDB.   Then for every purchase, you get a free
beatnik hat, gotee comb and vans shoes(or Birkenstocks).

Lance


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:5DE92697-A8A6-448F-AC88-F609AE4B6CD0@news.elevatesoft.com...
>I just wanted to take a moment and let everyone know what's going to be
>coming for ElevateDB 2.0 in the next month:
>
> 1) We will be issuing a new ElevateDB 2.00 Build 2 shortly that will fix a
> couple of bugs in the original 2.00 build.
>
> 2) I will be posting a new technical article this evening that will detail
> how to use the new facilities in ElevateDB 2.0 to build a bi-directional
> replication system.
>
> 3) After that, we will be working on finishing up ElevateDB 2.01, which
> will concentrate primarily on improvements to the ElevateDB Manager and
> the remaining top 4 features for the 2.0 series:
>
>    a) A general messaging layer for ElevateDB.  As part of this, we will
> most likely also split out the ElevateDB Server UI from the server itself,
> and leverage the messaging layer to allow for remote monitoring.
>
>    b) Procedures and functions at the session level for use with all
> databases.
>
>    c) A script debugger for the ElevateDB Manager.  This was actually
> almost done, but just didn't make the initial 2.00 cut.
>
>    d) The ability to optimize conditions using multi-column indexes, so
> that compound expressions can take advantage of one index instead of
> having to use several.
>
> 4) After 2.01 is out, we will be concentrating on platform expansion, most
> notably CF support, Mono support, and FreePascal (Linux only initially)
> support.
>
> If you have any questions at all, please let me know.  And, as always, get
> the word out about ElevateDB and all of the cool things we've got planned.
>
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

> Furthermore it would be interesting to know more opinions of EDB-users.
> Maybe many of them are thinking the same way, but don't post it here.

From Wikipedia:  "Null is a special marker used in Structured Query Language
(SQL) to indicate that a data value does not exist in the database."   It is
hardly an "opinion" that the complete absence of anything is the same as a
place for a string that happens to have a zero length.

I strongly oppose the notion of NULL = EmptyString and I hope it is not
implemented.  Sure it's a little extra work to use NULLIF or IFNULL, but
that's a small price to pay for emphasizing the fact that the concept of a
field being NULL is very different from having a blank string.  Also, if a
programmer coming in to EDB from some other SQL database that adheres to the
globally accepted standard and does not expect this option, it might cause
hours of troubleshooting until s/he realizes that EDB does not conform to
the SQL-2003 standard as stated in the Product Information page of the web
site.  Of course, if there is an option to turn this on or off and is off by
default (meaning NULL <> EmptyStr), it could still be considered to be
"compliant" I am sure and would not bother me--except that I would still
disagree with it in principle!

I just hope that if it IS implemented, it's not a property of the database,
but of the library so that the calling program doesn't have to provide work
arounds depending on which it finds.  But in the case of stored procedures,
I don't know how that can be avoided.

References:
http://en.wikipedia.org/wiki/SQL
http://en.wikipedia.org/wiki/Null_%28SQL%29

--
David Cornelius
CorneliusConcepts.com

Roy,

<< I am cynical enough to say I'm not surprised, but I am bitterly
disappointed. I have difficulty in thinking you were not aware that <<The
problem is that the NULL handling is in the generic "value" class that we
use for *everything* in EDB>> on the numerous occasions I have asked about
it this year since you indicated you would try to build a level of
compatibility support into V2. >>

Yes, I was aware of how EDB was built because I wrote it.  However, I wasn't
entirely sure how difficult it would be to work in a virtual method to
determine how the NULL flag should behave.  After going through it, it is
extremely difficult to do without potentially missing something now or in
the future due to the issue that I described - I have to set the flag
*everywhere* that such a value is created, and they are used everywhere.
And the remote session issue is a pickle also - which NULL behavior property
does the remote session use - the property in the TEDBEngine for the remote
application, or the property in the ElevateDB Server ?  What if the two are
different ?  In contrast, a compiler define would be immensely easier, but
that's a non-starter for obvious reasons.

--
Tim Young
Elevate Software
www.elevatesoft.com

David,

<< Also, if a programmer coming in to EDB from some other SQL database that
adheres to the globally accepted standard and does not expect this option,
it might cause hours of troubleshooting until s/he realizes that EDB does
not conform to the SQL-2003 standard as stated in the Product Information
page of the web site.  Of course, if there is an option to turn this on or
off and is off by default (meaning NULL <> EmptyStr), it could still be
considered to be  "compliant" I am sure and would not bother me--except that
I would still disagree with it in principle! >>

The general idea was that it would be turned off by default, and only turned
on if you needed it to be.

--
Tim Young
Elevate Software
www.elevatesoft.com

Lance,

<< Don't forget a Mac version of EDB.   Then for every purchase, you get a
free beatnik hat, gotee comb and vans shoes(or Birkenstocks). >>

Yeahhhhhhh, mann !!!!

--
Tim Young
Elevate Software
www.elevatesoft.com