Spatial Data Manager and the Year 2000
Welcome to the Year 2000
This document discusses the ways in which the Spatial Data Manager (SDM) product handles dates at the Year 2000 and beyond, with the aim of enabling customers to determine what impact, if any, the turn of the millennium will have on their SDM-enabled systems.
Summary
SDM relies on the date format and processing facilities provided by the host RDBMS. SDM will therefore take full advantage of future updates and Year 2000 support offered by these systems. This also means that internationally, customers may use the date format standard accepted within their respective countries.
Currently, SDM accepts, recognises and processes dates as described elsewhere in this document. If you aim to include SDM as part of your corporate Y2K testing programme , please carefully read the Technical Information portion of this document, as it describes the technical aspects of SDM's interpretation of dates.
We also strongly recommend that customers carefully audit their information systems to ensure that such systems will have a smooth transition into the next century. For example, not all mainframe programs may function properly at the Year 2000. If a computer with SDM software is used to access such information, Year 2000 issues may arise. Some PCs also have a problem that resets the system date to 1980 when the computer reaches the year 2000. In addition, software developers and customers that create solutions based on SDM software to collect, store and manipulate dates may have problems if they have not properly accounted for the Year 2000. Customers must also take responsibility for the accuracy of the data that has been entered during their daily operations.
It is important for customers to be aware of, and take appropriate measures to address, these and other related issues. You should therefore examine the Year 2000 compliance statements made by the relevant RDBMS and Operating System Vendors.
Technical Information
Summary
No version of SDM has ever assumed that a two-digit year refers to merely the current century.
Spatial Data Manager (SDM) does not interpret dates, but uses RDBMS to compare dates.
SDM 4.1, 4.2 and newer versions handle Temporal (Historical) data by constructing SQL queries that perform selections based on user-specified dates and sending these queries to the RDBMS for processing.
In the case of the Oracle RDBMS, SDM enables the entry and manipulation of dates in a format determined by means of the Oracle configuration parameter NLS_DATE_FORMAT. Consequently, SDM 4.2 and older versions do not allow a user to enter a date that is incompatible with the Oracle RDBMS system. As an example, a user may enter a value such as "5/01/02", intending the year 2002. SDM 4.2 and previous versions would pass the date to the RDBMS, the latter will return either an error condition due to date format incompatibility, or correctly interpret the date field as January 5, 2002.
Processing
SDM processes dates in the following manner:
- SDM does not provide a 'date' data type but uses the underlying RDBMS' date types.
- Data manipulation operations done on any columns declared to be of type date are passed to the RDBMS for processing and are interpreted according to native RDBMS rules for date parsing.
- Dates are passed to and from the RDBMS as character strings.
- SDM uses underlying RDBMS' date type for Historical Records Management and for Job Management. In doing this, SDM does not interpret dates but constructs SQL queries to perform selections based on user-specified dates and sends these to the RDBMS for processing.
- SDM uses system date and time for managing long transaction locks. It uses a 4 digit year in the time stamp in this context.
SDM API
The following API functions involve date data type.
SQLSetConnectOption() with SQL_CONNECT_OPT_HRM_DATE option.
- This function specifies the date in HRM when view option is set to 'view at a date'. The function requires the date be specified in 'DD-MON-YYYY HH24:MI:SS' format.
SQLDescribeCol()
- This function requests the type of columns and the buffer length required to extract data from columns. For a date column, the type is character string and the required buffer size is 32.
SQLBindCol(), SQLBindParameter() and SQLGetData().
- These functions are used to input and output data, including dates. Dates are treated the same way as character strings by these functions.
RDBMS and Operating System Vendors
SDM currently uses the following Oracle products which are fully Year 2000 compliant:
- Oracle Server 7.x or 8.x
- Oracle Programmer 2000 Pro*C
- Oracle SQL*Plus
- Oracle SQL*Net
For current information about year 2000 issues associated with the RDBMS and supported Operating Systems, SPATIALinfo recommends that you contact:
|
