(2) Continue using Sybase as Web backend DB and upgrade to MDAC 2.1.

 

(3) Convert all current Web apps to Oracle backend DB and upgrade to MDAC 2.1.

PRO:

- Fixes Y2K issue.

- Fixes security problem.

- Improves general operability of IIS. (Oracle works much better then Sybase with IIS.)

- Provides isolated environment for Web Databases (Oracle boxes).

- Improves operability of development tools (Visual InterDev provides tighter integration with Oracle DBs).

CON:

- Requires rewrite of all existing Sybase to Oracle.

- Requires new hardware and configuration. (Production and Development Oracle DB servers)

- Oracle learning curve among web developers.

- Lack of on-site Oracle knowledge in Stellarton.

 

Recommendations:

Option (1):

Option (1) obviously provides no solutions to the pressing problems, but if the Y2K ramifications are minimal, or can isolated, then the status quo could possibly be maintained in the short-term. RDS can be removed and code using it re-written or temporarily shut down. This affects primarily the "Atheneum" (document library) application, but also the"IP address look-up" application and to a small extent the "LAN Administrator" app.

 

 

Conclusion: The time spent chasing the Y2K and RDS issues in the large amounts of existing code would be time-consuming and difficult, especially with larger applications and applications written by developers no longer with the company.

 

 

Option (2):

Option (2) presents the greatest danger as the unpredictability of crashes and data loss is high. It does address the security and Y2K issues, but at the cost of reliability.

 

 

Conclusion: Instability and potential for data-loss render this option the least attractive.

 

 

Option (3): – Recommendation –

Option (3) would appear to present the most suitable solution long-term. Oracle’s over-all product line (and Oracle 8i, specifically) appears to be designed with Internet applications in mind, whereas Sybase is having difficulty developing ODBC drivers that function with Microsoft’s Internet Server software (which represents 28% of the overall Internet server market). Given Oracle’s near seamless integration with our current Web server (and development tools), it appears to be the most appropriate choice.

Further, converting our pre-existing Sybase tables to Oracle tables appears to be a relatively easy process (with the exception being the HR applications, which is more complex).

 

Conclusion: Given the deadline of January 1, 2000 (MDAC 1.5 is non-Y2K), the sooner we can obtain and configure the Oracle hardware and software the sooner we can begin to port the tables and update the Web-based code. This will require resources and expertise from Shared Services in addition to Web developers from Applications.

As for RDS, it can be removed and the apps that use it can either be temporarily shut down, or re-written to bypass RDS. The largest application currently using RDS is the Atheneum (document library) application on the Intranet, but it is also used very frequently in the IP application and the Network Manager application. A final option would be to ignore the RDS problem assuming the Oracle / MDAC issue can be implemented within a month or so. Given that we have survived to date without a security breach, this may be the most appealing option, thus making all our resources available to convert to the Oracle DB.

 

 

Appendix "A" — MDAC 1.5 Y2K Compliance Issue:

(Compiled by P. Renouf, July 20, 1999)

 

We are running MDAC version 1.5, the current version of MDAC is 2.1.2.4202.3 (GA).

 

The Known Year 2000 problems with MDAC 1.5 are:

(OLE DB compliance):

 

The known Year 2000 issues for OLE DB data coercion library are:

If you code to ADO,

- AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp.

- AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98)

- AND you specify a two-digit year less than 60,

- AND you do not specify a time as part of the date/time information

THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am).

 

 

If you code directly to OLE DB, the same case exists:

If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as:

DBTYPE_DATE

DBTYPE_DBDATE

DBTYPE_DBTIME

DBTYPE_FILETIME

DBTYPE_DBTIMESTAMP

- AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98)

- AND you specify a two-digit year less than 60,

- AND you do not specify a time as part of the date/time information

THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am).

- There are no known Year 2000 problems with MDAC 2.1.2.4202.3.

 

Appendix "B" — MDAC 1.5 RDS Security Issue:

(Documented by P. Renouf, July 20, 1999)

The recent RDS security hole is a rather large one. The implication is that through RDS (with MDAC 1.5 either running now, or installed previously and upgraded) an external user can access the Web Server as System. System is an access level even beyond Administrator, it has total unequivocal control over the server.

To make matters worse, through this hole the attacker can access any database devices the RDS has access to. The details of this attack have not yet been made public, but this is by far one of the worst security holes to date.

There are a two ways around this: