Raul,

<< My priorities with the v2 were definitely on the replication side (Thanks
Tim!) and and even looking forward to what the the Enterprise Server is all
about (if it's still in the TODO list for end of 2008). >>

I should have all of the new 2.0 features and platforms done by August or
September, and then I should be able to get the Enterprise Server done by
the end of the year, but it will be close.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Being a predominantly fileserver developer you have to forgive me for not
thinking about this, but isn't it the same issue as with large file support
ie its up to the developer to get/keep them in sync? >>

No, remote sessions don't care about large file support since that is all
defined on the server.   This wouldn't be the case for remote sessions and
NULLs.

--
Tim Young
Elevate Software
www.elevatesoft.com

Heiko,

<< As someone who earns his money with DBISAM based applications, I'm
interested in compliance with the "DBISAM standard", not the SQL2003
standard. >>

I understand, but we do have to balance the past with the future, and some
of the things that you're used to in DBISAM seem really bizarre to people
coming from other database engines.  IOW, they were probably a mistake to
do, even if they are nice to have and useful.

<< with absolutely no benefit. >>

Please give it some time.  I'll think you'll eventually find that ElevateDB
has a lot of cool features that DBISAM doesn't.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>>>>with absolutely no benefit.

>>Please give it some time.  I'll think you'll eventually find that ElevateDB
>>has a lot of cool features that DBISAM doesn't.

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

I can guess that for the majority of your customers SQL2003 compliance is a must have. But
I also guess they wouldn't have minded some DBISAM artifacts, as long as they don't have
any disadvantages from them.

Tim


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.

From a post dated 18/3/2008
-------------------------------------------------------------------------------------------------------------------
<< If it looks as though its not going to make it, or be substantially
delayed please post an announcement so I can a) get the voodoo doll out and
b) start making changes. >>

I sure will.
-------------------------------------------------------------------------------------------------------------------

So essentially it looks as though you are going to achieve your objective I have to make some sort of decision and I have no choice other than to go with NULL <> emptystring and put yet more effort into converting my app to ElevateDB on top of the amount its already taken.

Roy Lambert

David

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

What is physically used to indicate the existence of NULL? If as you say its a complete absence of anything surely the hard drive its stored on would implode a bit like a blank hole, or the head would keep falling through to the next platter.

Or to put it another way - there is something there that acts as a marker which sql looks at and scratches it little pointy head and gives up and says "I don't know what this is or what to do with it"

Roy Lambert

> What is physically used to indicate the existence of NULL? If as you
> say its a complete absence of anything surely the hard drive its
> stored on would implode a bit like a blank hole, or the head would
> keep falling through to the next platter.
>
> Or to put it another way - there is something there that acts as a
> marker which sql looks at and scratches it little pointy head and
> gives up and says "I don't know what this is or what to do with it"

Roy,

You're trying to make it difficult now, aren't you?  Here's something I
just thought of...

This may be akin to Delphi objects: if an object variable is not yet
assigned, then it has a nil pointer--in other words, any type of object
could be pointed at by the pointer variable.  But once an object is
created and assigned to the variable, even if the data is not yet
filled, at least the pointer variable knows what type of data to expect
and how much space is allocated.

In other words, the Delphi function "Assigned()" has a very different
use than " = EmptyStr".  It doesn't make any sense to me to combine
them or use them interchangeably, especially since Assigned(), just
like the SQL NULL, can refer to any type of data, whereas EmptyStr (or
'') is specifically a string with zero characters.

Now, for concatenting strings with NULLs like you're wanting to and
putting that into the Delphi objects analogy above, that would be like
adding a nil pointer variable to a string-pointer variable (i.e.
PChar).  What would happen in Delphi?  Access violation (if indeed the
+ operator was allowed to work in this context).  Of course you
wouldn't do this in Delphi because you've learned to check to make sure
the pointer variables have something in them first.

We will probably have to agree to disagree, but I also think this may
be part of the evolution of database technology.  I see EDB as a step
towards more mature standards and letting NULL = EmptyStr is, IMHO, a
step backwards.  Plus, like Tim is concerned about, it may introduce
holes that may not be realized for quite some time.  That's my biggest
fear.

--
David Cornelius
CorneliusConcepts.com

David

>You're trying to make it difficult now, aren't you? Here's something I
>just thought of...

Of course <vbg>

>This may be akin to Delphi objects: if an object variable is not yet
>assigned, then it has a nil pointer--in other words, any type of object
>could be pointed at by the pointer variable. But once an object is
>created and assigned to the variable, even if the data is not yet
>filled, at least the pointer variable knows what type of data to expect
>and how much space is allocated.

Unfortunately this analogy breaks down right here. The table already knows what type of data should be there, or are you saying that the existence of null overrides the column definition?

>In other words, the Delphi function "Assigned()" has a very different
>use than " = EmptyStr". It doesn't make any sense to me to combine
>them or use them interchangeably, especially since Assigned(), just
>like the SQL NULL, can refer to any type of data, whereas EmptyStr (or
>'') is specifically a string with zero characters.

Are you a politician? They're very good at changing the question? (sorry for the insult). A pointer and a string of any type are different animals

>Now, for concatenting strings with NULLs like you're wanting to and
>putting that into the Delphi objects analogy above, that would be like
>adding a nil pointer variable to a string-pointer variable (i.e.
>PChar). What would happen in Delphi? Access violation (if indeed the
>+ operator was allowed to work in this context). Of course you
>wouldn't do this in Delphi because you've learned to check to make sure
>the pointer variables have something in them first.

Since an object pointer is simply a pointer into an area of memory. The is no reason to add anything to it. And it achieves damm all, unless you know the offset to a specific function maybe or want to alter a piece of text?

Adding forename to surname is something I want to do frequently and it should be allowed without having to wave a magic wand.

>We will probably have to agree to disagree,

Yeah but its good fun arguing the point.

>but I also think this may
>be part of the evolution of database technology.

Unfortunately. I wonder what peoples reaction to the standard would have been if they'd been more honest and written something like:

"To save space and cos people would stone us if we suggested every table should have an extra hidden column for every column that the database engine has to check before it does anything with the data in the column we'll have a property called NULL"

>I see EDB as a step
>towards more mature standards

Once somethings mature the only way is downhill

>and letting NULL = EmptyStr is, IMHO, a
>step backwards.

Guess my opinion.

>Plus, like Tim is concerned about, it may introduce
>holes that may not be realized for quite some time. That's my biggest
>fear.

That I'm doubtful about, but the c/s remote vs local session getting out of step could be a valid issue. Its not one I understand well so I'll take Tim's word for it.

Roy Lambert

> > This may be akin to Delphi objects: if an object variable is not yet
> > assigned, then it has a nil pointer--in other words, any type of
> > object could be pointed at by the pointer variable. But once an
> > object is created and assigned to the variable, even if the data is
> > not yet filled, at least the pointer variable knows what type of
> > data to expect and how much space is allocated.
>
> Unfortunately this analogy breaks down right here. The table already
> knows what type of data should be there, or are you saying that the
> existence of null overrides the column definition?

Well, I was basing this (albeit rather loosely) on the following
statement taken from Wikipedia's discussion of SQL NULL:

"Since Null is not a member of any data domain, it is not considered a
'value', but rather a marker (or placeholder) indicating the absence of
value."

So it sort-of sounded like a pointer to me--or maybe "variant" would be
a better fit.  Yeah, I know the TABLE knows what should be there, but
since there isn't actually a value there yet, it can be treated the
same as the absence of a value in any other column.

> > In other words, the Delphi function "Assigned()" has a very
> > different use than " = EmptyStr". It doesn't make any sense to me
> > to combine them or use them interchangeably, especially since
> > Assigned(), just like the SQL NULL, can refer to any type of data,
> > whereas EmptyStr (or '') is specifically a string with zero
> > characters.
>
> Are you a politician? They're very good at changing the question?
> (sorry for the insult). A pointer and a string of any type are
> different animals

Haha!  But that's exactly my point: a pointer and a string are
different animals, just like NULL and VARCHAR are different animals.

> Adding forename to surname is something I want to do frequently and
> it should be allowed without having to wave a magic wand.

So "COALESCE(forename, '') + ' ' + COALESCE(surname, '')" is just too
much trouble?  Or setting a default of an empty string for these two
fields doesn't work?  Seriously, I'm surprised it's this big of a deal
to you.

> Unfortunately. I wonder what peoples reaction to the standard would
> have been if they'd been more honest and written something like:
>
> "To save space and cos people would stone us if we suggested every
> table should have an extra hidden column for every column that the
> database engine has to check before it does anything with the data in
> the column we'll have a property called NULL"

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.

> > I see EDB as a step
> > towards more mature standards
>
> Once somethings mature the only way is downhill

LOL!

> ... but the c/s remote vs local session getting
> out of step could be a valid issue. Its not one I understand well so
> I'll take Tim's word for it.

That was one of my first concerns.  Because the project I'm working on
right now is in 3 remote offices and will be using replication to
synchronize to a 4th instance of the database.  Which NULL option
applies?


--
David Cornelius
CorneliusConcepts.com

David

>Well, I was basing this (albeit rather loosely) on the following
>statement taken from Wikipedia's discussion of SQL NULL:

Ahh - the measure of true desperation - try googling ORACLE NULL EMPTY - there's some lovely threads

>So "COALESCE(forename, '') + ' ' + COALESCE(surname, '')" is just too
>much trouble? Or setting a default of an empty string for these two
>fields doesn't work? Seriously, I'm surprised it's this big of a deal
>to you.

Its not just those two fields, but that's the example the zealots usually quote. Its all string fields, and writing ALL queries like that is a big deal. Also think of explaining to end users who frequently don't give a rat's arse if its unknown, unknowable, just blank or the tea lady ran off with it.

I will have to go down the set a default of emptystring route, but that has consequences of its own - a prodigious amount of work for me because I can no longer use .IsNull or .Clear or IS NULL which in turn means all the query's have to be checked and altered plus altering my query generator to use = '' and <> '' rather than IS NULL and IS NOT NULL only for string fields.

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.

>> Unfortunately. I wonder what peoples reaction to the standard would
>> have been if they'd been more honest and written something like:
>>
>> "To save space and cos people would stone us if we suggested every
>> table should have an extra hidden column for every column that the
>> database engine has to check before it does anything with the data in
>> the column we'll have a property called NULL"
>
>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 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.

Roy Lambert