Date Considerations
This section provides an overview of different date considerations followed when using meta-SQL.
You can avoid confusion when using meta-SQL such as %Datein and %Dateout if you remember to use "in" functions in the Where subclause of a SQL query and to use "out" functions in the Select (main) clause of the query. For example:
select emplid, %dateout(effdt) from ps_car_alloc a where car_id = '" | ®ISTRATION_NO | "' and plan_type = '" | &PLAN_TYPE | "' and a.effdt = (select max (b.effdt) from ps_car_alloc b where a.emplid=b.emplid and b.effdt <= %currentdatein) and start_dt <= %currentdatein and (end_dt is null or end_dt >= %currentdatein)";
Use date or time wrappers (%Datein, %TimeOut, and so on) when selecting date or time columns into memory. Different database platforms use different internal formats for these data types. Those different formats range from 1900-01-01 to 01-JAN-1900. DateTime (timestamp) formats are even more complex.
In PeopleCode (SQLExecs and the like), use both an "out" wrapper when selecting a DateTime value into memory, as well as an "in" wrapper when referencing the value as a bind variable.
In an Application Engine program, when you populate a DateTime state field in a %Select, you still must use an "out" wrapper to get the value into the standard format. But when you reference this state field in a %Bind, Application Engine automatically provides the "in" wrapper around the substituted literal or bind marker (the latter if reuse is in effect).
Actually, if you use
the code %Bind(date)
in the select list of another %Select statement, to load the value
into another date field, Application Engine doesn't provide a wrapper
(since you are selecting a value that is already in the standard format,
you do not need to use a wrapper).
Dynamic views containing Date, Time, or DateTime fields must be wrapped with the appropriate meta-SQL. PeopleTools uses the SQL directly from the view definition (view text) and doesn't generate anything, so no meta-SQL wrapping is done.
SQL views should not contain meta-SQL that wraps Date, Time, or DateTime fields.
In SQR, if you are using {DateTimein-prefix}, and so on, you need to do the following:
For string or let statements when using dynamic SQL, you need to use the following:
{DYN-Date***in/out-prefix/suffix}
For SQL statements, you need to use the regular SQL, as follows:
{Date*** in/out-prefix/suffix}