Hi Team,
   When I initially create a VARCHAR firld it is NULL.  No problem.
   If I then add some text to the field save it, and then delete the text it seems to remain as an empty text field
rather than reverting to NULL.
   Is this correct?  If so, is there some switch to have it return to NULL when empty?

Regards & TIA,
Ian

Yes the fields are set as Nullable.

Ian


Welcome to the wonderful world of NULL where an empty string is different to null.

My subclassed table essentially RTRIMs the field and converts empty string to null. With SQL you're on your own. Its in the extensions ng

Roy Lambert

Roy Lambert wrote:
>
> My subclassed table essentially RTRIMs the field and converts empty string to null. With SQL you're on your own. Its
> in the extensions ng
>
Hi Roy,
   Put you component into place.  Will what hapens.
   Is what's in extensions the latest?
Regards,
Ian

On 7/17/2018 6:47 PM, Ian Branch wrote:
>    If I then add some text to the field save it, and then delete the text it seems to remain as an empty text field
> rather than reverting to NULL.
>    Is this correct?  If so, is there some switch to have it return to NULL when empty?

If you're setting it to empty then it's empty. If you were to set it to
null it would be null.

It's a design issue IMHO - if you don't want NULLs in general for this
then set default value for column to be empty string so it' always
starts out as empty.

You can write an insert/update trigger that nulls empty string fields
but that needs to be maintained so it lot more work IMHO

Raul

Ian


>    Put you component into place. Will what hapens.

What?

>    Is what's in extensions the latest?

Probably not Its written using D2006 so may or may not compile at your end. I'll upload whatever's on my disk tomorrow, but what's there now should be good.

Roy

Roy Lambert wrote:

> Ian
>
>
> >    Put you component into place. Will what hapens.
>
> What?
>
> >    Is what's in extensions the latest?
>
> Probably not Its written using D2006 so may or may not compile at your end. I'll upload whatever's on my disk
> tomorrow, but what's there now should be good.
>
> Roy

HI Roy,
   A couple of small changes, we lready discussed them in an earlier exchange.
   Appreciate the latest.
Regards,
Ian

Raul


>It's a design issue IMHO - if you don't want NULLs in general for this
>then set default value for column to be empty string so it' always
>starts out as empty.

I agree but I think its the standard that's designed wrong

Roy

On 7/19/2018 7:37 AM, Roy Lambert wrote:
>
> I agree but I think its the standard that's designed wrong
>

Sure but then are people like Cher and Madonna - in their case the last
name field in DB should be NULL (not defined) vs empty string

Raul

Raul


You really shouldn't feed the trolls but since you have

<<
Sure but then are people like Cher and Madonna - in their case the last
name field in DB should be NULL (not defined) vs empty string
>>

1. those are both stage names (or nicknames or aliases) not real names, even if they've dropped their real name
2. Print both on an envelope and unless you have special software to print "NULL" rather than empty space I sincerely doubt that any human can differentiate
3. Try writing to Cher NULL or Madonna NULL

As an added extra I thought I'd see if her real name was on the web. The side entry had

Parents:Georgia Holt,John Paul Sarkisian,Gilbert Hartmann LaPiere - I didn't think genetic engineering had started yet

But good ol wikipedia

Cher was born Cherilyn Sarkisian in El Centro

so database design

Forename
Middle Name(s).Initial(s)
Nickname
....
....
....


I have yet, in all the years I've been arguing about it, to be given a genuine use case for null <> emptystring. Those I have been given would generally be better satisfied with an additional boolean to indicate wether or not data had been entered. Its also indicative of the "rightness" of my view that so many people default string fields to emptystring ie they dodge the issue.


Roy Lambert