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

Tim


As always my question is null=emptystring.

Any idea on timescales yet?

Roy Lambert

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

Tim,

> Frankly, I'm just not sure if it's worth all of the possible issues that it
> could cause.


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.

Eryk

Tim

><< As always my question is null=emptystring. >>
....
....
>Frankly, I'm just not sure if it's worth all of the possible issues that it
>could cause.

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.

You already know that in my opinion it is a worthwhile adaption fro ElevateDB, especially for those porting an app from DBISAM, but I would like to emphasise that, in my opinion, it is worthwhile for those continuing to develop in Delphi even for new apps.

Defaulting all string fields (possibly including CLOBs, but I need to think about that a bit more) to emptystring will in most cases (ie where users are allowed to delete data without something like your ctrl-N facility) be the best alternative and that means you're not allowed to use .IsNull or .Clear or IS NULL.

Not defaulting to emptystring also means wonderful sql constructs like

IF(Title IS NULL, '',Title)+' '+ IF(Forename IS NULL,'',Forename)+' '+IF(Surname IS NULL,'',Surname)

rather than

Title+' '+Forename+' '+Surname

to use one of the best quoted examples of the NULL <> emptystring worshipers

So to ask the question bluntly - Are you going to make the change or not. If the answer is yes what is the timescale.

I know other people will have other priorities but I personally would have happily waited for replication and the other enhancements you're posting.

Roy Lambet

Roy,

> IF(Title IS NULL, '',Title)+' '+ IF(Forename IS NULL,'',Forename)+' '+IF(Surname IS NULL,'',Surname)
>
> rather than
>
> Title+' '+Forename+' '+Surname
>

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.

Eryk

Roy,

I support your posting: for me the difference between a null-value and an
empty string is purly theoretical. In "real life" it does nothing but
produce lots of unnecessary code lines.

Frankly said: I am happy with EDB coming from DBISAM, but one of the points
that really annoys me sometimes is Null <> EmptyString.

On the other hand I understand you, Tim, very well. I know how hard the work
can be to investigate every place where a change might produce new issues.
Though I'd like you to check this once more, please.

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.

Regards Uli

Hi Uli,

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

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.

Best regards,
Fons

Eryk


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

Eryk

>> IF(Title IS NULL, '',Title)+' '+ IF(Forename IS NULL,'',Forename)+' '+IF(Surname IS NULL,'',Surname)
>>
>> rather than
>>
>> Title+' '+Forename+' '+Surname
>>
>
>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!

Roy Lambert