Roy,

Just to add - I still haven't decided *for sure* whether I'm going to do
this or not.  My response was to indicate to you that it doesn't look
promising, and that I have serious issues with possibly destabilizing the
code for something like this.

You have to understand that I don't exactly have people beating down the
door for this, while I *do* have people asking about CF support and other
improvements.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

Also, what about the issue of right-trimming the string column assignments ?
Do you want that behavior, also ?

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

While new to EDB I'd support leaving it "as is".

I have used NULL values for string/chars in the past (for "not
provided/refused to provide" situations) and while there maybe a bit more
code it's not really a a major problem IMHO. Keeping with the standard also
a positive as you don't have to think about this when switching between DBs.

A proper DB design can alleviate some of  these coding headaches - use
default values for string fields and add not null constraints where
appropriate.

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

Raul

Tim,

>You have to understand that I don't exactly have people beating down the
>door for this, while I *do* have people asking about CF support and other
>improvements.

I know it won't change anything, but here's another vote.

As someone who earns his money with DBISAM based applications, I'm interested in
compliance with the "DBISAM standard", not the SQL2003 standard. In fact, the whole
SQL2003-standard-dogma of ElevateDB is more than just an annoyance to me - it's the only
reason I never used EDB1 in any application, it's the reason I'm very reluctantly starting
to migrate now with EDB2 - I do so because the advantages are slowly overgrowing the
disadvantages. Null behaviour, string trim, into clause, date literals, non-editable
canned queries, ... , this things will cost me weeks of absolutely unnecessary work, with
absolutely no benefit. No, I don't like it.

The only benefit I see in SQL2003 standard compliance is, that some day, if you decide you
want to be a zen priest rather than a programmer, switching to another database will cause
a little bit less pain.

Tim


>Also, what about the issue of right-trimming the string column assignments ?
>Do you want that behavior, also ?

Luddite that I am I'd like it. However, you made it clear that it wasn't coming and I invested time and effort into modifying the databound edit controls (via subclassing naturally) to provide this behaviour. Seemed a better way than writing LOTS of triggers.

Roy Lambert

Eryk


>There isn't much cost if you accept the standard behaviour from the
>start and code accordingly.

That is precisely the cost I had in mind.

Roy Lambert

Heiko


Thank you for your support, and I think you've put it brilliantly  << I'm interested in compliance with the "DBISAM standard", not the SQL2003 standard>>

I can't help you with all of it but if you want to take the approach I have with right trimming I'd be happy to send you my component alterations as your "starter for 10".

My approach is a simple one, its probably not 100%, but its as near as I can manage. I subclassed the Delphi dbedit component so that when the mouse leaves it, or its exited the text is right trimmed. Its easier than building a trigger for every table or field.

Roy Lambert

Tim


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

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?

>In contrast, a compiler define would be immensely easier, but
>that's a non-starter for obvious reasons.

Oh god yes, please don't force me to see your source code.

Roy Lambert

Roy

>>I subclassed the Delphi dbedit component so that when the mouse leaves it, or its exited
the text is right trimmed

I thought about subclassing TEDBTable and TEDBQuery, overriding the Post method, and
trimming all string fields before Post.
And for insert/update queries not to use Params anymore, but a set of overloaded
functions, like

SQL.Text := 'insert into xyz (a,b,c) values
('+sv(aString)+','+sv(bFloat)+','+sv(cDatetime)+')';

and do the string trim in the sv() function.

Heiko


I thought about that as well but decided the edit control was the best place to attack.

Roy Lambert