Visual LANSA Forum

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.

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

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.

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?

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.