When working with Lansa VL Web Pages, and need to log a date & time stamp, is it preferred to use the *DATETIME field, or use two separate fields for *DATE and *TIME? I am new to VL Web Pages, and in the past (working with WAMs) have always had these as two fields in our data tables (legacy iSeries fields), but I am really trying to learn to make use of the newer field types / etc where and when appropriate.
My assumption is that it makes it easier to log and store just a single field, and that I can extract the date or time individually for on screen display or report use?
Is there a "best practice" guide from the forum members on this fields use?
Thanks in advance for input.
*DATETIME vs *DATE & *TIME
*DATETIME vs *DATE & *TIME
Arlyn Dale
Servias LLC
Servias LLC
Re: *DATETIME vs *DATE & *TIME
I like *DateTime. It saves time and like you say you can extract whatever you need.
I'm pretty sure in IBM i SQL you can define how many digits you want for the microseconds. Not sure if LANSA allows that.
Art
I'm pretty sure in IBM i SQL you can define how many digits you want for the microseconds. Not sure if LANSA allows that.
Art
Art Tostaine
Re: *DATETIME vs *DATE & *TIME
As the applications go global and they are not just running in one zone time, for logging, to have just datetime stored in only one field, with a value of #DATETIMEX.Now , I think it makes sense. A few reasons for having the date separated would be that is easier for Logical Files in the IBM or simple SQL inquires.
Note that for example, if I do this:
#DATETIMEX := #DATETIMEX.Now
Right now is 4/22 2:55pm . if you show the #DATETIMEX field in the web page, it will show correctly in my time zone, but stored in the table, is 4/22 6:55pm because is stored in UTC 0 time, England.
No other action is needed... but if you try to use an sql in the sql management studio (or SELECT_SQL), well, you need to show bring those dates first to your time zone in your SQL where.. etc.
Note that for example, if I do this:
#DATETIMEX := #DATETIMEX.Now
Right now is 4/22 2:55pm . if you show the #DATETIMEX field in the web page, it will show correctly in my time zone, but stored in the table, is 4/22 6:55pm because is stored in UTC 0 time, England.
No other action is needed... but if you try to use an sql in the sql management studio (or SELECT_SQL), well, you need to show bring those dates first to your time zone in your SQL where.. etc.
Re: *DATETIME vs *DATE & *TIME
An update to my original post, an seeking some new input.
My efforts to use the *DATETIME field in Lansa has been bumpy at best. I first had to figure out the partition field definitions of DUTC and SUTC for the Z DATETIME field, and their implications. I am still working with support to understand why the data stored in my iSeries for a *DATETIME field is not getting calculated correctly (but that is different issue).
I was initially hoping to use the single *DATETIME field in one of our activity log files, and to be able to sort and view log records by this field. I now have found out that use of the *DATETIME field as an index key is not recommended by Lansa. And if you try to use it as a key field, Lansa wizard generated Views seem to simply ignore the field.
I am thinking it best to go back to using the two separate fields for DATE and TIME logging, but would like to hear if anyone else has other (better) ideas before I start making the changes to the files?
My efforts to use the *DATETIME field in Lansa has been bumpy at best. I first had to figure out the partition field definitions of DUTC and SUTC for the Z DATETIME field, and their implications. I am still working with support to understand why the data stored in my iSeries for a *DATETIME field is not getting calculated correctly (but that is different issue).
I was initially hoping to use the single *DATETIME field in one of our activity log files, and to be able to sort and view log records by this field. I now have found out that use of the *DATETIME field as an index key is not recommended by Lansa. And if you try to use it as a key field, Lansa wizard generated Views seem to simply ignore the field.
I am thinking it best to go back to using the two separate fields for DATE and TIME logging, but would like to hear if anyone else has other (better) ideas before I start making the changes to the files?
Arlyn Dale
Servias LLC
Servias LLC
Re: *DATETIME vs *DATE & *TIME
You could still use a datetime field, and have an ID in the file, a correlative numeric key.
I know, is an extra field, but for some reason people like to have those unique one field key ID today nowadays versus having it indexed by the fields that make unique a record.
I know, is an extra field, but for some reason people like to have those unique one field key ID today nowadays versus having it indexed by the fields that make unique a record.