mutating UUIDs

Allen Matlick (3/21/14 9:58PM)
Joshua Fletcher (3/21/14 10:31PM)
Joshua Fletcher (3/21/14 10:36PM)
Allen Matlick (3/21/14 11:24PM)
Joshua Fletcher (3/21/14 11:59PM)
Joshua Fletcher (3/22/14 12:50AM)
Joshua Fletcher (3/22/14 1:24AM)
Tim Nevels (3/22/14 5:50PM)
Keisuke Miyako (3/22/14 10:39PM)
Richard Wright (3/25/14 12:10PM)
Joshua Fletcher (3/25/14 5:55PM)
Joshua Fletcher (3/25/14 6:13PM)
Joshua Fletcher (3/25/14 7:00PM)
Joshua Fletcher (3/27/14 1:49AM)
Richard Wright (3/27/14 11:40AM)
Richard Wright (3/27/14 1:25PM)
Peter Bozek (3/27/14 2:44PM)
Milan Adamov (3/27/14 2:57PM)
Milan Adamov (3/27/14 5:43PM)
Joshua Fletcher (3/27/14 7:06PM)
Keisuke Miyako (3/28/14 1:57AM)
Richard Wright (3/28/14 8:15AM)
agendo (3/28/14 2:21PM)
Richard Wright (3/28/14 3:23PM)


Allen Matlick (3/21/14 9:58 PM)

On Mar 21, 2014, at 2:31 PM, Joshua Fletcher wrote:

color><param>8826F,0000,8219/param>MMoral of the story for me:  even
though 4D displays normal-appearing
values in the UUID field, what you see may not be what you get.  When
adding the PKID/UUID field to a table, regardless of what appears in
the
data displays, you must go through and touch every pre-existing record
in
order to get functional (i.e. static) UUID values.
/color><color><param>00000,0000,DDEE/param>
Note that this is not limited to UUIDs.  If you add *any* field to a
table and display that field in a form you will see the "default"
value for that field type.  For example if you add a Longint you will
see "0" for every field.  But that is NOT the value of the field.  The
field is NULL until you save some data.
/color>

I understand what you're saying.  One thing that is different, I
believe is that with the other types viewing or programmatically
referencing a Null value would always display or return the same
value, e.g. 0 for a longint.  However, with the UUID you see or return
something different every time.

Seeing a table full of 0's in a particular field would be easy to
interpret as 'no data', particularly if you knew that you just added
that field.  However, seeing a table full of differing UUIDs it's easy
to interpret the display as saying that there are different UUIDs in
each record rather than indicating that they all, in fact, have the
same value which is Null.

Personally, it would make more sense to me if a Null UUID just
displayed as a blank.  Then it would be easy to see that something is
missing.  I'd even extend that logic to other types as well, though it
would break down with strings and text.

Just my opinion.

Allen

-------------------------
Allen Matlick
allen@...
805-893-5219

Joshua Fletcher (3/21/14 10:31 PM)

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>ttable displayed normal-looking
UUIDs.  All of the UUIDs were automatically
generated by 4D apparently as a result of me defining the field with
the
above parameters.
/color>
No, that's not the case.  What you're seeing is that when the record
is loaded (i.e. On Display Detail) 4D sees that the UUID field
contains NULL data, and since auto uuid is enabled it generates a new
UUID.  So every time On Display Detail fires, you get a new UUID.  As
you found, It's still your responsibility to *save* the change.

color><param>00000,0000,DDEE/param>TThe mutational behavior can be
stopped by touching every one of the
records that existed at the time the field was added.  Records added
after
the addition of the new field don't show the mutational behavior.
/color>
Yep, this is normal.

color><param>00000,0000,DDEE/param>MMoral of the story for me:  even
though 4D displays normal-appearing
values in the UUID field, what you see may not be what you get.  When
adding the PKID/UUID field to a table, regardless of what appears in
the
data displays, you must go through and touch every pre-existing record
in
order to get functional (i.e. static) UUID values.
/color>
Note that this is not limited to UUIDs.  If you add *any* field to a
table and display that field in a form you will see the "default"
value for that field type.  For example if you add a Longint you will
see "0" for every field.  But that is NOT the value of the field.  The
field is NULL until you save some data.

color><param>00000,0000,DDEE/param>II found nothing in the docs that
addresses this behavior (I may have
missed it).  When I saw normal-looking data in the displays I made the
assumption that everything was normal  -- a mistake this time.
/color>
To be honest I don't know where this behavior is documented but it's
so old that's not surprising.  4D has behaved this way at least since
I started using it.

Side note: if you're doing this in anticipation of adding a Primary
Key, not that the 4D Primary Key validator in v14 will automatically
replace NULL values for you after you when you convert (or even if you
wait and add the Primary Key within v14).

Kind regards,

Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

Joshua Fletcher (3/21/14 10:36 PM)

Sorry, this last paragraph had a lot of typos.  I'll say it
differently to be clear:

-Add new auto generated field in v13.
-Set that field to be a Primary Key in v13.
-Convert to v14.
-Open a v13 data file (i.e. a deployed data file).

4D will automatically replace any NULL values with real ones at
startup.

-Add new auto generated field in v14.
-Set that field to be a Primary Key in v14.
-Open a v14 data file (i.e. a deployed data file).

4D will automatically replace any NULL values with real ones at
startup.

If you want more details about this, we recently did a Webinar on it:

https://www.youtube.com/watch?v=cquRjXBl1xE&list=UUGInXMk9DNWgkB3mJO96
Wrw

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>SSide note: if you're doing this in
anticipation of adding a Primary Key,
not that the 4D Primary Key validator in v14 will automatically replace
NULL values for you after you when you convert (or even if you wait and
add the Primary Key within v14).
/color>

Allen Matlick (3/21/14 11:24 PM)

Josh,

Thanks for the tip.  Just as a heads up, for 12.5 and 13.3 the value
of Map NULL values to blank values has no effect on the display.  It
never shows blanks regardless of whether it's on or off.

The tip referred to below refers to 4D v14, so I presume it's
something that's been fixed in a later version of 4D than I'm using.

Allen

On Mar 21, 2014, at 3:59 PM, Joshua Fletcher wrote:

color><param>00000,0000,DDEE/param>TThis is critically important
though!  You are not allowed to generate a duplicate UUID. If you do
it's not a UUID! I get that UUID's are new and not everything has a
thorough understand of them so I get also that this isn't intuitive
unless you understand UUID's. I think 4D's behavior is a bit of a
learning opportunity here, rather than an annoyance.

/color><color><param>8826F,0000,8219/param>PPersonally, it would make
more sense to me if a Null UUID just displayed
as a blank.
/color><color><param>00000,0000,DDEE/param>
Turn off "Map NULL values to blank values" for that field and it will:

http://kb.4d.com/assetid=77009

Kind regards,
/color>

-------------------------
Allen Matlick
allen@...
805-893-5219

Joshua Fletcher (3/21/14 11:59 PM)

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>II understand what you're saying.
 One thing that is different, I believe
is that with the other types viewing or programmatically referencing a
Null value would always display or return the same value, e.g. 0 for a
longint.  However, with the UUID you see or return something different
every time.

Seeing a table full of 0's in a particular field would be easy to
interpret as 'no data', particularly if you knew that you just added
that
field.  However, seeing a table full of differing UUIDs it's easy to
interpret the display as saying that there are different UUIDs in each
record rather than indicating that they all, in fact, have the same
value
which is Null
/color>
This is critically important though!  You are not allowed to generate
a duplicate UUID. If you do it's not a UUID! I get that UUID's are new
and not everything has a thorough understand of them so I get also
that this isn't intuitive unless you understand UUID's. I think 4D's
behavior is a bit of a learning opportunity here, rather than an
annoyance.

color><param>00000,0000,DDEE/param>PPersonally, it would make more
sense to me if a Null UUID just displayed
as a blank.
/color>
Turn off "Map NULL values to blank values" for that field and it will:

http://kb.4d.com/assetid=77009

Kind regards,

Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

Joshua Fletcher (3/22/14 12:50 AM)

Sorry! You would also need to disable "auto UUID".  My bad, didn't
think of that. That's that setting that's causing the new values to be
created.

If you have "auto UUID" off, and "map null..." turned off, then NULL
UUID's will be blank.

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>TThanks for the tip.  Just as a
heads up, for 12.5 and 13.3 the value of
Map NULL values to blank values has no effect on the display.  It
never
shows blanks regardless of whether it's on or off.
/color>

Joshua Fletcher (3/22/14 1:24 AM)

Depends on the business rules though. Â=A0If you need the UUID while
you're creating a record, you have to do it before the trigger
(because the old "on create" trigger was removed in v11). Just
pointing out they're not necessarily equivalent.

For a surrogate key it'd definitely be fine either way I think?

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>FFor those that do not have
religious objections or allergic reactions to
triggers, you can skip 4D's automagical behavior and call Generate
UUID.

Pros and cons, acknowledged...just figured I'd toss in one
alternative...
/color>

Tim Nevels (3/22/14 5:50 PM)

On Mar 22, 2014, at 10:36 AM, Joshua Fletcher wrote:

color><param>00000,0000,DDEE/param>DDepends on the business rules
though. Â=A0If you need the UUID while you're creating a record, you
have
to do it before the trigger (because the old "on create" trigger was
removed in v11). Just pointing out they're not necessarily equivalent.
/color>

I don't remember there ever being an "On Create" trigger event. Maybe
you are thinking about the old "On Loading Record Event" that was in
4D 2004. But that event was not called for new records.

Tim

Keisuke Miyako (3/22/14 10:39 PM)

Hello,

I think that is a rather extreme view,
auto-generate UUID is as good as Generate UUID for primary keys or
relation (1) keys.

The only case where auto-generate UUID produces Ã=A2â=82¬=C5&igrave;mutat
ingÃ=A2â=82¬=C2&ugrave; UUIDs
is when
you set a field with existing NULLs (typically a field added where
records
already exist) to auto-generate UUID.

You can confirm the behaviour;

1. create a table.
2. add a field.
3. add records.
4. add another field; set it to auto-generate UUID.
5. in user-mode, resize the list form; for every pixel move the
records is
re-loaded, and you see a bespoke UUID.
6. as soon as you re-save the NULL record (automatic action, update by
formula, MSCÃ=A2â=82¬=C2¦) the problem goes away.

Again, this will only apply for fields with existing NULLs.
Normally, you donÃ=A2â=82¬=E2&Ntilde;¢t nominate an existing field
with NULLs as primary
key;
you either define the key before any data is added, or you only use an
exiting field which is known to not contain NULLs or duplicates.
v14 has a feature whereby if a primary key contains NULLs or
duplicates,
it is given a new value,
if and only if it has the auto-increment or auto-generate attribute is
set.
But this is only a security measure, it is better to have 100% valid
keys
before migrating to v14.

miyako

On 2014/03/22 23:31, "George Huhn" <Ghuhn@... wrote:

color><param>00000,0000,DDEE/param>""Generate UUID" works great for
generating UUIDs for use as primary keys.
I have never used the auto-UUID feature to generate UUIDs as primary
keys
for linking records, and judging from what I am reading here, I never
will.
/color>

Richard Wright (3/25/14 12:10 PM)

No, no deleted fields with old data here. We don't delete fields ever,
except if we accidentally create a field when we didn't mean to and
then we delete it immediately. We never delete fields after populating
them.

color><param>00000,0000,DDEE/param>DDate: Tue, 25 Mar 2014 17:31:17
+0100
From: Joshua Fletcher <JFletcher@...

You got a duplicate key error because you had existing data from an
existing (deleted) field in the data file. As I'm sure you're aware 4D
has
a very old behavior where deleting a field doesn't delete the
underlying
data.  Incidentally a new keyword was added to v14 ("TRAILING") for
force
4D to create the new field at the "end" of the table.

The behavior of the UUID value when the underlying field is NULL was
already explained in this thread, I don't think it's confusing at this
point. There's nothing ambiguous going on, 4D is behaving as it always
has. The unexpected part, perhaps, is that the value changes but as you
rightly pointed it out it *has* to change, otherwise it wouldn't be a
UUID.

Thanks.

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc.

On 3/24/14, 7:58 AM, "Richard Wright" <rwright@...
wrote:

/color><color><param>8826F,0000,8219/param>IIn v12.5, if I create a
new field in a table with existing records I get
a duplicate key error as soon as I try to turn on the Unique attribute;
however, 4D retains the attribute. I also get an duplicate key error t
if
I try to make this the Primary_Key and 4D rejects the attempt. So I'm
trying to figure out how you were able to set this as a Primary Key.

That said, I think this is a case of 4D trying to be too clever for
it's
own (and our) good by trying to automatically create UUIDs on-the-fly
for
existing data. I think it's really dangerous because a UUID is not only
supposed to be unique but it's also supposed to be an identifier. And
because it's universally unique there should never be a need to change
it. Maybe this is 4Ds foray into quantum computing with these IDs that
change every time you look at them. I wonder what happens when you
print
the data on a report or extract it via SQL.

And what about the overhead with testing and creating a UUID for every
record load or redisplay? 4D no longer gives us an On Loading Record
trigger but I guess they kept it for themselves.

I think what 4D should do is present a Confirm dialog telling the user
that 4D will now create the values.
/color><color><param>00000,0000,DDEE/param>
/color>

Joshua Fletcher (3/25/14 5:55 PM)

Hi Allen,

First of all thanks for your thorough explanation, I think it describes
perfectly what's happening and the first-time experience any developer
might have.

I'm not sure how long you've been using 4D but the ability to have NULL
values is something new (added in 4D v11 SQL) and it is NOT supported
by
the 4D language with the exception of the Is field value null command.
This is why, for example, there is no way to display "null" for null
values; the 4D language doesn't really support null at all.  The
implication of course is that adding support for null to the language
is a
non-trivial amount of work. Note that you can use SQL within 4D to gain
access to support for null.

I agree it is risky to display anything at all for null values and
this is
something to be careful of as a 4D developer.

I completely agree with you that the interface can be made more
user-friendly and, for my part, what I usually do is replace the field
on
the form with a variable.  In the On Display Detail event for that
variable, I use the Is field value null command to detect if it's null,
blank, or has a real value and display something as appropriate.

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc.

On 3/24/14, 9:13 AM, "Allen Matlick" <allen.matlick@... wrote:

color><param>00000,0000,DDEE/param>RRichard,

When I tried it, I did just as I described below.  The only thing I
can't
define exactly is the order in which I checked the field
characteristics.
The 'Unique' may have been the last thing I checked.  Perhaps that
makes
a difference.

If I'm understanding things correctly, 4D isn't actually trying to
create
UUIDs for the existing records.  The UUID in all of the existing
records
is NULL.  However, the unfortunate problem with the way that 4D
defaults
to display NULL UUIDs causes each record to display a different UUID
for
each of the affected records and we perceive that as actual creation of
UUIDs.

Displaying different information in each record implies that there
actually is different information in each record, but in this case
that's
not true.  It's a confusing exception.

I originally suggested that it would be more logical to me if NULL
UUIDs
simply displayed as blanks, and Josh described a way whereby the
default
field display settings could be changed to accomplish that.  After
further thought, if I had my choice all NULLs for all field types would
display in the same way, perhaps a special symbol or just the word
'NULL'.

The current situation where NULL data is displayed as the default value
for that data type, e.g. NULL Longint -> 0, is a bit confusing because
it
could easily be misinterpreted to mean that the actual value was zero.
With UUIDs, this is particularly confusing because there's no
consistent
(to the human eye) response.

I have no knowledge of the internal operations of 4D's display code,
but
if it were my program I'd look to see if there was a way to make the
human interface better in this area.  It might not actually be all
that
complicated.  4D must already be looking at the data to determine
whether
or not it's a NULL.  If it is a NULL it must be then getting the
default
value and displaying that value in the format appropriate for that data
type.  Why not see if it's a NULL, if it is then display the NULL
value
in the special NULL format, otherwise display the data in the
appropriate
data format?

Just my  thoughts.

Allen
/color>

Joshua Fletcher (3/25/14 6:13 PM)

Yes sorry Richard, your post reminded me of a similar scenario (same
error
message) but your issue was different. I posted another reply to
address
your problem, which you'll probably see before you see this :)

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc.

On 3/25/14, 10:10 AM, "Richard Wright"
<rwright@...
wrote:

color><param>00000,0000,DDEE/param>NNo, no deleted fields with old
data here. We don't delete fields ever,
except if we accidentally create a field when we didn't mean to and
then
we delete it immediately. We never delete fields after populating them.
/color>

Joshua Fletcher (3/25/14 7:00 PM)

Hi Allen,

Ugh sorry, poor choice of words.  I was not trying to separate "4D
language" from "4D program".  In fact I was trying to establish the
opposite: they are one and the same in this context.  This is a
fundamental part of 4D IMO, that the entire experience behaves
consistently from programming language to UI.  It would have been
better
for me to say, "except via SQL, 4D does not support null".

Aside from this discussion (which will be archived) I think it would
be a
good idea for us to add something in kb.4d.com to explain this
behavior as
well.

Thanks,

Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc.

On 3/25/14, 10:35 AM, "Allen Matlick" <allen.matlick@... wrote:

color><param>00000,0000,DDEE/param>JJosh,

Thanks for your responses.

I understand and agree that the 4D language doesn't support NULLs.
However, the 4D program itself does both recognize and display NULLs.
The issue is that the way 4D displays all NULL field values in forms is
ambiguous.  That ambiguity is just particularly bad with UUIDs.

My speculation/suggestion was that within 4D itself, the parts that we
can't touch as developers, the code that deals with the display of
fields
in forms might be a candidate for examination for possible changes to
reduce ambiguity in the displays.

I'm not really concerned about data display for end users.  That could
be
addressed using the form variable method you describe.  I'm just
saying
that as a developer, when I saw different data displayed in different
records I just assumed that it reflected the idea in that there
actually
was different data in different records.  That led to some confusion
on
my part about what 4D was actually doing.  As evidenced by this
thread, I
think that others have shared (and others will share) in that same
confusion.  Had I seen something like "NULL" or a simple blank in all
of
the displayed records after I added the new field then I would have
immediately understood what 4D had (or had not) done and would have
known
what to do next.

When I find that the users of the product I build find the displays
confusing I try to find ways to reduce that confusion.  It makes them
happier and it saves me time on the service calls I don't receive.  It
makes my product look better in the eyes of my customers.  I'm
presumptuously extending that process to include 4D itself and saying
as
a customer, 'Here's a difficulty I've had with your product and a way I
think it might be made better".

I think you've probably already understood my point, but I thought I'd
rephrase it just in case.

In any case, thanks for your attention and time on this discussion.

Allen
/color>

Joshua Fletcher (3/27/14 1:49 AM)

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>WWe really do need a standard
visual representation
of a null value. All nulls are the same -- null date, null time, null
longint, null real, null text, etc. We need one symbol to represent
this.
/color>
I couldn't agree more.  HOWEVER nothing will change if the farthest
this discussion goes is an email thread on the iNUG.  I know I'm doing
this:

http://awesomegifs.com/2012/07/beating-a-dead-horse/

But please file and vote for feature requests if you want something to
change:

http://forums.4d.fr/Forum/EN/1075213/0/0

Kind regards,

Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

Richard Wright (3/27/14 11:40 AM)

I thought UUIDs were associated with string fields, not numeric fields.

color><param>00000,0000,DDEE/param>DDate: Thu, 27 Mar 2014 14:57:22
+0100
From: Milan Adamov <madamov@...

On 27.03.2014., at 14.44, Peter Bozek <peter.bozek@... wrote:

/color><color><param>8826F,0000,8219/param>II would await UUIDs are
internally represented as 128-bit numbers, not 36
character strings.
/color><color><param>00000,0000,DDEE/param>
Yes, that is true.
/color>

Richard Wright (3/27/14 1:25 PM)

Are you saying that the UUIDs are not stored as strings in string
fields?

color><param>00000,0000,DDEE/param>DDate: Thu, 27 Mar 2014 17:43:54
+0100
From: Milan Adamov <madamov@...

On 27.03.2014., at 17.40, Richard Wright
<rwright@... wrote:

/color><color><param>8826F,0000,8219/param>II thought UUIDs were
associated with string fields, not numeric fields.
/color><color><param>00000,0000,DDEE/param>
They are 128-bit integers internally. The APIs that 4D use to generate
UUIDs are mentioned here:

http://kb.4d.com/assetid=76070
/color>

Peter Bozek (3/27/14 2:44 PM)

<CA+zevpksR8mPPkg=0POE=KwLft8husWCwvvS5oExZVLp-4hbRw@mail.gmail.com>

On Thu, Mar 27, 2014 at 2:42 PM, Richard Wright <<
rwright@... wrote:

color><param>00000,0000,DDEE/param>II'm hoping $tUUID is blank and
that at least 4D does not try to
auto-assign the value when loading the record via language commands.
But
even that would be a disparity between loading and saving a record in
language vs the user interface.

/color>
I would await UUIDs are internally represented as 128-bit numbers, not
36
character strings.

--

Peter Bozek

Milan Adamov (3/27/14 2:57 PM)

On 27.03.2014., at 14.44, Peter Bozek <peter.bozek@... wrote:

color><param>00000,0000,DDEE/param>II would await UUIDs are internally
represented as 128-bit numbers, not 36
character strings.
/color>
Yes, that is true.

Regards,

Milan

Milan Adamov (3/27/14 5:43 PM)

On 27.03.2014., at 17.40, Richard Wright
<rwright@... wrote:

color><param>00000,0000,DDEE/param>II thought UUIDs were associated
with string fields, not numeric fields.
/color>
They are 128-bit integers internally. The APIs that 4D use to generate
UUIDs are mentioned here:

http://kb.4d.com/assetid=76070

Regards,

Milan

Joshua Fletcher (3/27/14 7:06 PM)

color><param>00000,0000,DDEE/param>
/color>

-----Original Message-----
color><param>00000,0000,DDEE/param>EExcept that a NULL string is
identical to an empty string and UUIDs are
strings. This is not true of numbers or other data type but it is for
strings. An empty string really is the absence of a value (NULL)
whereas
zero is a legitimate numerical value.
/color>
Assuming by "empty string" and "null" you mean:

[MyTable]MyUUIDField:="" ` empty string
SET FIELD VALUE NULL([MyTable]MyUUIDField) ` null

The empty string and null are not equivalent in 4D.

color><param>00000,0000,DDEE/param>HHas anyone tried to grab the value
from an auto-assigning UUID field for a
record where it has not yet been assigned?

 =A0Load Record ([MyTable])
 =A0$tUUID := [MyTable]MyUUIDField

I'm hoping $tUUID is blank
/color>
The fact that $tUUID might contain the empty string as value (it won't
in the above example but bear with me) does not indicate the
equivalence of the empty string and null.  It indicates that the 4D
language doesn't support null as a primitive.  You can verify this,
for example:

Load Record ([MyTable])
[MyTable]MyUUIDField:=""
ALERT(String(Is field value Null([MyTable]MyUUIDField)))  // displays
"False".
SET FIELD VALUE NULL([MyTable]MyUUIDField)
ALERT(String(Is field value Null([MyTable]MyUUIDField)))  // displays
"True".

You can of course also validate this using the equivalence operator in
SQL (where null is supported as a primitive).

color><param>00000,0000,DDEE/param>aand that at least 4D does not try
to auto-
assign the value when loading the record via language commands.
/color>
If Auto UUID is enabled for [MyTable]MyUUIDField and the current
record from [MyTable] has the null value in [MyTable]MyUUIDField
(*not* the empty string) then, yes, 4D will assign a value (a new
UUID) in your example.

-Josh

--
Josh Fletcher
Technical Account Manager
4D, Inc

Keisuke Miyako (3/28/14 1:57 AM)

technically NULL is not a value, it is a state.

On 2014/03/28 5:20, "Richard Wright" <rwright@...
wrote:

color><param>00000,0000,DDEE/param>ffail to see the difference between
having no value and NULL.
/color>

Richard Wright (3/28/14 8:15 AM)

How do you fill in a field with nothing (and empty string)? How does a
user do this in an entry form? I'm not talking about 4D, but for any
program. I don't know how to type an empty string into a field.

color><param>00000,0000,DDEE/param>DDate: Fri, 28 Mar 2014 09:33:50
+1100
From: David Adams <dpadams@...

Without resorting to the underlying theory that makes nulls
important...here's a real-world reason people want them:

* Field never filled in: NULL
* Field filled in with an empty string: NOT NULL.

Different.
/color>

agendo (3/28/14 2:21 PM)

color><param>00000,0000,DDEE/param>II don't know how to type an empty
string into a field.
/color>
That's easy, type simply nothing or empty the input control. Filling
in a NULL value is harder and with the means of the 4D programming
language impossible. Please look for Josh's post regarding NULL values
and empty strings.
Only way I can think of getting NULL (beside using SQL) is creating a
new record without initializing the fields.

Regards
Lutz

Richard Wright (3/28/14 3:23 PM)

Does it really matter these days?

On Fri, Mar 28, 2014, at 3:04 PM, 4d_tech-request@... wrote:

color><param>00000,0000,DDEE/param>DDate: Fri, 28 Mar 2014 12:39:23
-0600
From: Dave Nasralla <dnasralla@...

Hi Richard,

Someone can correct me if I'm wrong, but if you store the UUID as a
plain
old alpha you will be doubling the storage requirements. UUID is 32 hex
characters which can be store as 16 bytes.

As an alpha it would take up 32 characters - that would be at least 32
bytes (I have no idea about unicode). I'm sure I butchered that enough
that
someone will chime in!

dave
/color>

Reply to this message

Summary created 3/29/14 at 2:20PM by Intellex Corporation

Comments welcome at: feedback@intellexcorp.com