 |
» |
|
|
|
|  | |
ALLBASE/SQL, version G2 contains several major enhancements
providing significant benefits in the following areas: If you are updating from an earlier release of ALLBASE/SQL,
refer to the migration information in the "Installation
Procedures" section appearing in the chapter "Compatibility
and Installation Requirements." To order this product,
contact your HP Representative. A list of ALLBASE/SQL reference manuals for HP-UX is provided
in chapter 4. Security | |
Two new authorities have been added to the G2 release of ALLBASE/SQL:
MONITOR and INSTALL. These new authorities can be granted to users
using the GRANT command, or can be revoked from users using the
REVOKE command. MONITOR authority gives a user the ability to run SQLMON,
an online diagnostic tool that monitors the activity of an ALLBASE/SQL
DBEnvironment. Before this new authority, SQLMON can only be run
by the creator of the DBEnvironment (also known as the DBECreator),
someone who knows the maintenance word (maint word), or someone
who has superuser capability. INSTALL authority gives a user the ability to use the SQL
preprocessors to create an SQL module owned by someone other than
themselves, or to use ISQL to install a module owned by someone
other than themselves. This is an important capability for those
needing to move modules from a development DBEnvironment to a production
DBEnvironment. Before this new authority, only a DBA had this ability. Year 2000 Compatibility | |
As the end of the century quickly approaches there has been
much concern about dates being handled correctly in the twenty-first
century. This is particularly an issue for systems and applications
that are using a two digit year to express dates. ALLBASE/SQL has
always stored dates in a four digit year format which largely eliminates
the year 2000 compatibility problem. ALLBASE/SQL applications can
be coded using four digit year dates, thus avoiding any ambiguity.
However, for existing applications that may allow dates to be entered
using a two digit year format, there is still an issue as to how
these dates get converted to the ALLBASE/SQL internal format using
the TO_DATE function or TO_DATETIME. For example, what date value
would the following functions return? TO_DATE('12/31/35','MM/DD/YY')
TO_DATETIME('351231235959','YYMMDDHHMISS') |
Would these functions evaluate the year as 1935 or 2035? When YY is specified in the format specification of either
TO_DATE or TO_DATETIME, and if its value of the year specified is
less than 50, then the century part of the DATE or DATETIME defaults
to 20, otherwise it is set to 19. This behavior can be overridden
by setting the environment variable HPSQLsplitcentury
to a value between 0 and 100. If the year specified is less than
the value of the environment variable HPSQLsplitcentury
then the century part is set to 20, otherwise it is set to 19. For the above example, Case 1: HPSQLsplitcentury is not set TO_DATE('12/31/35','MM/DD/YY') = 2035-12-31
TO_DATETIME('351231235959','YYMMDDHHMISS') = 2035-12-31 23:59:59 |
Case 2: HPSQLsplitcentury is set to 0 TO_DATE('12/31/35','MM/DD/YY') = 1935-12-31
TO_DATETIME('351231235959','YYMMDDHHMISS') = 1935-12-31 23:59:59 |
Case 3: HPSQLsplitcentury is set to 70 TO_DATE('12/31/35','MM/DD/YY') = 2035-12-31
TO_DATETIME('351231235959','YYMMDDHHMISS') = 2035-12-31 23:59:59 |
|
