|
| Date Field which are nul (or 0) |
 |
Thu, 04 Oct 2007 10:23:53 -040 |
Error Retrieving Value problem.
Basically, it doesn't seem like you can have an empty date field on a form.
While this happens in the desktop, I don't think this is Desktop
specific at least in the running because when I "load a file" with the
attached. I get the same problem. But I can't even figure out the error
number or how it is thrown.
So I thought to look at the actual .sxf file.
This line struck
<controlsource>
<fieldname>DateHired</fieldname>
<tablename>Employee</tablename>
</controlsource>
<displayformat>yyyy.0m.0d</displayformat>
</sdf1edittext>
etc.
What does this <displayformat> entry mean and do.
If I load the form in "Desktop", and have some date in the field the
date DISPLAY format is "dd/MMM/YYYY". Even though the generated
.sxf has this >displayformat> line suggesting a different form.
But I load the same form via my dataformsJDK.sma
and what gets displayed is "yyyy.0m.0d"
So then I look at the code generated by save as dataform1 program:
csrc =@ f.getfieldandtable("DateHired", "Employee")
if csrc !@= .nul
field =@ csrc.field
table =@ csrc.table
end if
if table !@= .nul and field !@= .nul and table.table =@=
field.table
fc =@ f.addcontrol(dataform1edittext, 274, 211, 202,
19, editstyle="", alignment="left", name="edit27",
page=page,
field=field, table=table, displayformat="yyyy.0m.0d", error=e)
else
fc =@ f.addcontrol(dataform1edittext, 274, 211, 202,
19, editstyle="", alignment="left", name="edit27",
page=page, error=e)
end if
fc.setbackgroundrgb(0xc8d0d4)
fc.settextrgb(0x0)
fc.setfont(font1)
fc =@ f.addcontrol(dataform1text, 174, 211, 96, 19,
text="DateHired", alignment="right",
name="text28"", page=page, error=e)
fc.setbackgroundrgb(0xc8d0d4)
fc.settextrgb(0x0)
fc.setfont(font1)
And I look at the code generated by save as wxform program:
fc =@ f.addcontrol(wxformtext, 174, 211, 96, 19, "DateHired",
name="text28", alignment="right")
fc.setbackgroundrgb(red=0xd4, green=0xd0, blue=0xc8)
fc.settextrgb(red=0x0, green=0x0, blue=0x0)
fc.setfont(font1)
fc =@ f.addcontrol(wxformedittext, 274, 232, 202, 19,
name="edit29",
alignment="left")
fc.setbackgroundrgb(red=0xd4, green=0xd0, blue=0xc8)
fc.settextrgb(red=0x0, green=0x0, blue=0x0)
fc.setfont(font1)
Now I go back to the Desktop. And load the form and the dates are
displaying "yyyy.0m.0d" format in FORM view, (why, I don't know) but
as "dd/MMM/yyyy" in RECORD view.
And if you look at the Table in Modify Table grid, the format column
says "m/d/yyyy" which apparently doesn't control anything.
And all of this poking around has gotten me no closer to figuring out
why Error Retrieving Value is thrown if I click in a date field which
is nul.
Except in the sense that I think whole method of handling dates is
fundamentally discombulated.
1. A date field has to be able to hold .nul or its equivalent. It
probably doesn't except that displaying records and/or data on forms has
gotten messed up somewhere. I could check but it's to much trouble.
2. A date field has to have a "display" format parameter, because it
just doesn't make any sense otherwise.
I supposed that there really are three formats:
a. Stored format - Julian number or .nul (maybe .nul is really 0 as in
? DAYS ("") because there is no day 0.
b. Record/Table format - e.g. "yyyy.0m.0d", or Julian number,
or "MMM dd, YYYY". I.e, how it looks in a Record or Table View.
Previously, in SB this was part of the stored value. Right?
c. Form/Reports or Display format -- how it looks on a Form and I guess
in a "display "but that has been limited to the output of the IDE
until
we get a Report generator. Previously, I think, that this was set
specific to a field on a form or report and barring any "specific"
setting there was a global or default setting achieved by NUMBASE, correct?
Nobody, even the programmer, should ever SEE a Julian, unless he or she
has specifically asked to see a Julian date. That it is actually stored
as a SuperLongUNsignedInterger and can be manipulated as such is magic
that I don't want to know about.
JDK
|
| Post Reply
|
 |
| Re: Date Field which are nul (or 0) |
 |
Fri, 05 Oct 2007 10:43:19 +010 |
Kromkowski wrote:
> Error Retrieving Value problem.
>
> Basically, it doesn't seem like you can have an empty date field on a
form.
OK, I will look at this one as soon as I can schedule a day of chasing
these problems.
> While this happens in the desktop, I don't think this is Desktop
> specific at least in the running because when I "load a file"
with the
> attached. I get the same problem. But I can't even figure out the error
> number or how it is thrown.
>
> So I thought to look at the actual .sxf file.
>
> This line struck
> <controlsource>
> <fieldname>DateHired</fieldname>
> <tablename>Employee</tablename>
> </controlsource>
> <displayformat>yyyy.0m.0d</displayformat>
> </sdf1edittext>
> etc.
>
> What does this <displayformat> entry mean and do.
I will check on these. They may not yet all be properly hooked up in a
meaningful way. Essentially, the displayformat for a control that has a
control source is meant to establish how the data is displayed and
interpreted. This is intended to cope with the fact that database fields
in SIMPOL's core database engine (sbme1) do not provide a display format
capability. Later, after this was added to the dataform1 design, the
decision was made to add metadata to the sbme1 format, both to guide a
generic PPSR server (multiuser sbme1 server providing PPCS) and also to
allow programs to retrieve metadata from sbme1 tables. This is not yet
in practical use, but the groundwork has been laid.
>
> If I load the form in "Desktop", and have some date in the field
the
> date DISPLAY format is "dd/MMM/YYYY". Even though the generated
> ..sxf has this >displayformat> line suggesting a different form.
Is this in Record View?
> But I load the same form via my dataformsJDK.sma
> and what gets displayed is "yyyy.0m.0d"
So at least dataform1 is paying attention to the format string.
> So then I look at the code generated by save as dataform1 program:
>
> csrc =@ f.getfieldandtable("DateHired", "Employee")
> if csrc !@= .nul
> field =@ csrc.field
> table =@ csrc.table
> end if
> if table !@= .nul and field !@= .nul and table.table =@=
> field.table
> fc =@ f.addcontrol(dataform1edittext, 274, 211, 202, 19,
> editstyle="", alignment="left",
name="edit27", page=page, field=field,
> table=table, displayformat="yyyy.0m.0d", error=e)
> else
> fc =@ f.addcontrol(dataform1edittext, 274, 211, 202, 19,
> editstyle="", alignment="left",
name="edit27", page=page, error=e)
> end if
> fc.setbackgroundrgb(0xc8d0d4)
> fc.settextrgb(0x0)
> fc.setfont(font1)
>
> fc =@ f.addcontrol(dataform1text, 174, 211, 96, 19,
> text="DateHired", alignment="right",
name="text28"", page=page, error=e)
> fc.setbackgroundrgb(0xc8d0d4)
> fc.settextrgb(0x0)
> fc.setfont(font1)
>
The dataform1 code has to cope with the potential failure to acquire the
data source.
> And I look at the code generated by save as wxform program:
>
> fc =@ f.addcontrol(wxformtext, 174, 211, 96, 19, "DateHired",
> name="text28", alignment="right")
> fc.setbackgroundrgb(red=0xd4, green=0xd0, blue=0xc8)
> fc.settextrgb(red=0x0, green=0x0, blue=0x0)
> fc.setfont(font1)
> fc =@ f.addcontrol(wxformedittext, 274, 232, 202, 19,
name="edit29",
> alignment="left")
> fc.setbackgroundrgb(red=0xd4, green=0xd0, blue=0xc8)
> fc.settextrgb(red=0x0, green=0x0, blue=0x0)
> fc.setfont(font1)
The wxform code doesn't do data sources, so there is no need to worry
about displayformats.
> Now I go back to the Desktop. And load the form and the dates are
> displaying "yyyy.0m.0d" format in FORM view, (why, I don't know)
but
> as "dd/MMM/yyyy" in RECORD view.
Ahh. Interesting. I will have to check this. In part, this is because
the form control has a display format associated with it, but Record
View is probably using some default that is set up for the whole
program. This should be resolved once the metadata is in use across the
board.
> And if you look at the Table in Modify Table grid, the format column
> says "m/d/yyyy" which apparently doesn't control anything.
That is correct. That is the metadata that is not in use yet.
> And all of this poking around has gotten me no closer to figuring out
> why Error Retrieving Value is thrown if I click in a date field which
> is nul.
That is probably just my bug. The question is where. Does this only
happen in record view, or does it also happen in form view?
> Except in the sense that I think whole method of handling dates is
> fundamentally discombulated.
See above.
> 1. A date field has to be able to hold .nul or its equivalent. It
> probably doesn't except that displaying records and/or data on forms has
> gotten messed up somewhere. I could check but it's to much trouble.
All fields in SIMPOL can contain the value .nul.
> 2. A date field has to have a "display" format parameter, because
it
> just doesn't make any sense otherwise.
To a human, yes. To a computer, no. The problem is picking the right
one. Especially when dealing with dates, how they are interpreted is a
very significant problem and is locale-specific.
> I supposed that there really are three formats:
>
> a. Stored format - Julian number or .nul (maybe .nul is really 0 as in
> ? DAYS ("") because there is no day 0.
>
> b. Record/Table format - e.g. "yyyy.0m.0d", or Julian number,
> or "MMM dd, YYYY". I.e, how it looks in a Record or Table View.
> Previously, in SB this was part of the stored value. Right?
Except it doesn't work for countries that use a different calendar.
Believe it or not, there are plenty of different ways to cope with the
calendar. That is why it is a locale problem and has been deferred
rather than just being wrong all the time in different places.
> c. Form/Reports or Display format -- how it looks on a Form and I guess
> in a "display "but that has been limited to the output of the IDE
until
> we get a Report generator. Previously, I think, that this was set
> specific to a field on a form or report and barring any
"specific"
> setting there was a global or default setting achieved by NUMBASE,
correct?
DATEBASE actually, but that only coped with a specific version of the
calendar (Western European and American).
> Nobody, even the programmer, should ever SEE a Julian, unless he or she
> has specifically asked to see a Julian date. That it is actually stored
> as a SuperLongUNsignedInterger and can be manipulated as such is magic
> that I don't want to know about.
Actually, you can assign a SIMPOL Julian value to a date or datetime
object and it will be broken into its component parts in the object for
retrieval. The formatting that you currently see anywhere is based on
some date conversion code that is meant to be SBL compatible, but is not
the right choice for the whole world. You may only need current dates in
the Gregorian calendar, but I have customers who may need to track dates
in Germany for historical records databases and who may need to manage
different calendars in terms of things like when the Gregorian Reform
occurred (it took about 200 years and differed from place to place as to
when it was done). I have other customers who typically need to display
the date in terms of the reign of a specific emperor (Japanese dates are
typically some year in the name of some emperor's reign).
To make all of that easily possible, dates in SIMPOL are stored as
integers and everything else is a display function that is or may be
locale-specific.
|
| Post Reply
|
| Re: Date Field which are nul (or 0) |
 |
Fri, 05 Oct 2007 12:32:06 -040 |
>> If I load the form in "Desktop", and have some date in the
field the
>> date DISPLAY format is "dd/MMM/YYYY". Even though the
generated
>> .sxf has this >displayformat> line suggesting a different form.
>
> Is this in Record View?
Both Record and Form View. Except for the odd situation when you
"run"
a form from the IDE which seems to be able to set some kind of global
date display setting.
>> Now I go back to the Desktop. And load the form and the dates are
>> displaying "yyyy.0m.0d" format in FORM view, (why, I don't
know) but
>> as "dd/MMM/yyyy" in RECORD view.
>
> Ahh. Interesting. I will have to check this. In part, this is because
> the form control has a display format associated with it, but Record
> View is probably using some default that is set up for the whole
> program. This should be resolved once the metadata is in use across the
> board.
OK.
>> And if you look at the Table in Modify Table grid, the format column
>> says "m/d/yyyy" which apparently doesn't control anything.
>
> That is correct. That is the metadata that is not in use yet.
>
>> And all of this poking around has gotten me no closer to figuring out
>> why Error Retrieving Value is thrown if I click in a date field which
>> is nul.
>
> That is probably just my bug. The question is where. Does this only
> happen in record view, or does it also happen in form view?
In the Desktop, in both Record and Form View, when you leave a date
field blank, which you have go into, you get the Error Retrieving Value.
AND you can never get out of it.
Note if you stay out of the field. You don't get the problem. So upon
reflection, this means that the error get thrown onlostfocus.
When I open "the form" (the .sxf file) via
f =@ opendataform1(filename, error=e, errortext=errtext)
from the IDE
I still get the Error Retriving Value (if I go into a date field and
leave it with a blank) but it doesn't cause an endless loop.
>> Except in the sense that I think whole method of handling dates is
>> fundamentally discombulated.
>
> See above.
>
>> 1. A date field has to be able to hold .nul or its equivalent. It
>> probably doesn't except that displaying records and/or data on forms
has
>> gotten messed up somewhere. I could check but it's to much trouble.
>
> All fields in SIMPOL can contain the value .nul.
I meant to write It probably DOES except that displaying records and/or
data on forms has gotten messed up somewhere.
>> 2. A date field has to have a "display" format parameter,
because it
>> just doesn't make any sense otherwise.
>
> To a human, yes. To a computer, no.
Well, when a computer is the end-user fine. Binary makes sense to a
computer but if someone invented a database program where all data was
displayed in binary then that would be you know what.
> The problem is picking the right
> one. Especially when dealing with dates, how they are interpreted is a
> very significant problem and is locale-specific.
>
> DATEBASE actually, but that only coped with a specific version of the
> calendar (Western European and American).
Sorry to be so Western and Catholic but I really don't give a hoot about
adjusting to some other calendar.
>> Nobody, even the programmer, should ever SEE a Julian, unless he or
she
>> has specifically asked to see a Julian date. That it is actually
stored
>> as a SuperLongUNsignedInterger and can be manipulated as such is magic
>> that I don't want to know about.
>
> Actually, you can assign a SIMPOL Julian value to a date or datetime
> object and it will be broken into its component parts in the object for
> retrieval. The formatting that you currently see anywhere is based on
> some date conversion code that is meant to be SBL compatible, but is not
> the right choice for the whole world. You may only need current dates in
> the Gregorian calendar, but I have customers who may need to track dates
> in Germany for historical records databases and who may need to manage
> different calendars in terms of things like when the Gregorian Reform
> occurred (it took about 200 years and differed from place to place as to
> when it was done). I have other customers who typically need to display
> the date in terms of the reign of a specific emperor (Japanese dates are
> typically some year in the name of some emperor's reign).
80/20 rule. Get the Western European and American version working first
and then worry about some special calendar nonsense.
> To make all of that easily possible, dates in SIMPOL are stored as
> integers and everything else is a display function that is or may be
> locale-specific.
But that was how it works in SB. The key point being "works"!
Date and Times can (and should) be "stored" as integers. But they are
not integers because they MUST have an attribute that we can generically
call DISPLAY format. If they don't have a display format then why even
bother having them as a separate type.
The Display format has to have a default (which can be changed/control)
and it can have a field/form specific override.
I am chomping at the bit to start raising heck about lack of detail
blocks and other issues. But it is hard to complain about that when the
dates aren't working.
|
| Post Reply
|
| Re: Date Field which are nul (or 0) |
 |
Fri, 05 Oct 2007 12:40:54 -040 |
One minor point which might be helpful.
Time fields don't suffer from the problem of Error Retrieving Value.
But the handling of displays is as confusing. And there are saving
issues both in record and form view that so vexing that they are
complicated to explain other than "wrong".
|
| Post Reply
|
| Re: Date Field which are nul (or 0) |
 |
Mon, 08 Oct 2007 12:50:47 -040 |
> NR: Can't, since this is an underlying architecture issue. Still, the
> DATESTR() and related functions work correctly. It is just an issue of
> how they work in relation to the database and SIMPOL Desktop that is at
> issue here.
>
>
> Dates work fine. They just have an issue in the SIMPOL application known
> as SIMPOL Desktop. Getting them working won't take that long, all the
> proper groundwork has been done.
I am going to disagree with you a bit.
There are two problems:
1. handling a .nul date field.
It is not just a SimpolDesktop issue. Because when I load a form via
"my dataformsjdk loader" program, It has doesn't seem to be able to
handle .nul dates. Because Error Retrieving Value is also thrown.
2. There is also the general display issue. This is a question, in the
first degree of HOW. Because, I may not be doing things correctly.
If I use:
f =@ opendataform1(filename, error=e, errortext=errtext)
I.e., when it "reads" this part of the .sxf
<controlsource>
<fieldname>DateHired</fieldname>
<tablename>Employee</tablename>
</controlsource>
<displayformat>0m.0d.YYYY</displayformat>
It should display the date date for this field in "0m.0d.YYYY" format
but it doesn't. It still displays it as "YYYY.0m.0d"
The last place for me to check is whether this:
fc =@ f.addcontrol(dataform1edittext, 274, 211, 202, 19, editstyle="",
alignment="left", name="edit27", page=page, field=field,
table=table,
displayformat="yyyy.0m.0d", error=e)
actually will do something different than
fc =@ f.addcontrol(dataform1edittext, 274, 211, 202, 19, editstyle="",
alignment="left", name="edit27", page=page, field=field,
table=table,
displayformat="0m/Od/YYYY", error=e)
JDK
|
| Post Reply
|
|
|