Oracle Partner Technical Services: M SQL Server™ Service O

MICROSOFT® SQL SERVER™ SERVICE OFFERING:
QUESTIONNAIRE
Oracle Partner Technical Services
Author: Tom Laszewski

Creation Date: August 19, 1998
Last Updated: November 30, 2001
Control Number:
Version: 2.1
Approvals:
Raja Srinivasan
Document Control
Change Record
Date Author Version Change Reference
August 19,1998 Tom Laszewski 2.0 Original document put into Oracle format.
November 30, 2001 Frédéric Janski 2.1 Modifications to Oracle 9i format.
Reviewers
Name Position
Distribution
Copy Number _____
Oracle Partner Technical ServicesOracle Partner Technical Services Executive SummaryExecutive Summary ii
54842860.rtf 2.1 2.1 2.1

Copy Name Location
No.
Oracle Partner Technical ServicesOracle Partner Technical Services Executive SummaryExecutive Summary iii
54842860.rtf 2.1 2.1 2.1

Contents
Document Control.............................................................................................ii
Change Record.............................................................................................ii
Reviewers....................................................................................................ii
Distribution..................................................................................................ii
Executive Summary...........................................................................................1
Introduction........................................................................................................2
Purpose.........................................................................................................2
Background..................................................................................................2
Section I - General Information.........................................................................3

Client Information........................................................................................3
Section II - Questions.........................................................................................5
Architecture..................................................................................................5
Database.....................................................................................................10
Current use of stored procedures (if applicable)........................................18
Current use of Embedded SQL/C..............................................................20
Current use of DB-Library/C.....................................................................21
Current use of Visual Basic........................................................................22
Current use of Powerbuilder......................................................................23
Current use of other application development tools..................................26
Support.......................................................................................................27
Other special logic/subsystems to migrate.................................................28
Oracle Partner Technical ServicesOracle Partner Technical Services Executive SummaryExecutive Summary iv
54842860.rtf 2.1 2.1 2.1

Documentation...........................................................................................29
Section III - Migration Workbench Tool..........................................................30

Overview.....................................................................................................30
Product Description...................................................................................30
Section IV - INFORMATION/SOLUTIONS..................................................31
Microsoft® IIS/ASP....................................................................................31
Microsoft® SQL Server™ Database...........................................................31
Microsoft® SQL Server™ SQL..................................................................32
Microsoft® SQL Server™ Stored Procedures............................................32
Microsoft® Embedded SQL/C-C++ and COBOL......................................33
DB-Library/C-C++....................................................................................33
Visual Basic...............................................................................................33
Powerbuilder..............................................................................................33
Oracle Partner Technical ServicesOracle Partner Technical Services Executive SummaryExecutive Summary v
54842860.rtf 2.1 2.1 2.1

Executive Summary
This template is used by Oracle Consulting, and Partner Technical Services, to
migrate a customer from Microsoft® SQL Server™ to Oracle9i. Oracle has
developed this template based upon the common deliverables produced for customers
migrating from competitive database platforms to Oracle9i.
This is the first template used when an Oracle consultant is preparing scope and
project plan documents for a Microsoft® SQL Server™ to Oracle9i migration
project. The information in this document is then used to complete the Project Scope
template.
Oracle Partner Technical ServicesOracle Partner Technical Services Executive SummaryExecutive Summary 1
54842860.rtf 2.1 2.1 2.1

Introduction
Purpose
This documents contains questions that need to be answered for any Microsoft® SQL
Server™ to Oracle9i migration effort. The four main sections of the document are
as follows:
1? Section 1(General Information) - Asks general questions about the company and product.
2? Section 2(Questions) - Asks all the questions that are necessary to prepare a thorough scope
document.
3? Section 3(Migration Workbench) - Gives an overview of the tool, and its limitations.
4? Section 4(Information/Solutions) - Contains information about converting systems from Microsoft®

SQL Server™ to Oracle9i, as well as solutions to common problems.
The questions in Section II are asked of the client. The answers, along with the
project scope template and section IV of this document, are used to complete the
project scope document.
Background
Oracle has performed many Microsoft® SQL Server™ to Oracle9i migrations over
the past five years. Oracle consultants have asked many of the same questions in
order to perform these migration efforts. This document is a compilation of the
questions asked of Microsoft® SQL Server™ technical personnel in order to
successfully complete a Microsoft® SQL Server™ to Oracle9i project scope effort.
54842860.rtf 2.1 2.1 2.1

Section I - General Information
Client Information
Client name
Address
System/application
name
Contacts: Manager:
Technical Manager:
DBA:
Lead Developer:
54842860.rtf 2.1 2.1 2.1

Others:
E-mail address Manager:
Technical Manager:
DBA:
Lead Developer:
Others:
Phone/Fax/Pagers Manager:
54842860.rtf 2.1 2.1 2.1

Technical Manager:
DBA:
Lead Developer:
Others:
54842860.rtf 2.1 2.1 2.1

Section II - Questions
Architecture
 Describe the business use of the system:

Why: Need to understand how the system is used
54842860.rtf 2.1 2.1 2.1

 Describe the architecture of the system:
Why: This will answer many questions regarding the system, and will introduce Oracle
Consulting to the technical environment.
 Online:
 Batch:
54842860.rtf 2.1 2.1 2.1

 Ad hoc:
54842860.rtf 2.1 2.1 2.1


54842860.rtf 2.1 2.1 2.1

 Describe use of Microsoft® Transaction Server.
Why: This area may need special consideration; different alternatives exist in
Oracle9i.
The use of Microsoft® Transaction Server is mainly for giving COM objects
declarative transaction properties. If the COM object are staying as COM objects then
Microsoft® Transaction Server can be used unchanged. COM+/Microsoft
Transaction Server components can access Oracle9i database servers. However if the
COM objects are being migrated to say Java, an alternative approach such as Oracle
9iAS OC4J will need to be used.
 Describe use of Microsoft® Message Queuing Server (MSMQ).

Why: This area may need special consideration; Oracle9i offers an Advanced
Querying (AQ) option.
 Describe use of Internet Information Server (IIS) and Active Server Pages (ASP)
Why: This area may need special consideration; Oracle9i offers the Internet
Application Server (iAS). More on this can be found in section IV.
 Describe any special features such as: replication, parallel servers or distributed
processing.
54842860.rtf 2.1 2.1 2.1

Why: These areas may need special consideration; different alternatives exist in
Oracle9i.
54842860.rtf 2.1 2.1 2.1

Database
 Microsoft® SQL Server™ version number

Why: Oracle9i and third party migration tools exist for specific versions of
Microsoft® SQL Server™ and Oracle9i. In addition, different versions of
Microsoft® SQL Server™ have different features.
 Has the SQL Server been installed as case insensitive?

Why: Microsoft® SQL Server™ allows a SQL Server to be installed as case
insensitive. In Oracle9i, this is not allowed so and additional column with all
upper case needs to be created (In this case we duplicate the column data in an
other column using the UPPER () function via a insert/update trigger).
Oracle9i handles this problem by allowing indexes to be built using functions on the
column(s) being indexed (In this case we will put the UPPER () function directly
in the index: functional indexes.).
 Type of system (such as: OLTP, OLAP, data warehouse etc.)

Why: The type of system will affect the number and size of the redo logs and
rollback segments. The type of system and number of tables will also effect the disk
layout, and therefore the number and size of tablespaces.
54842860.rtf 2.1 2.1 2.1

 Total size of development (and/or production) database in MB
Why: Space needs to be made available for the corresponding Oracle9i database,
as well as the data files that will hold the data as it is being transferred between
Microsoft® SQL Server™ and Oracle9i. Also the size of the database will effect
table and/or tablespace setting such as: INITIAL, NEXT, PCTINCREASE,
MINEXTENTS and MAXEXTENTS.
 Number of tables
Why: The number of tables will impact the estimate for the schema migration. If
the Oracle Migration Workbench is used, the process should be for the most part
automatic. If the schema migration is done manually, an estimate needs to be made
for schema migration based upon the number of tables.
 Size and usage of tables

Why: The size and usage of tables will effect where tables will be placed (i.e.
tablespaces).
 Largest tables (number and size):
54842860.rtf 2.1 2.1 2.1

 Most active tables (number and size):
 Look up tables (number and size):
 Number of views
Why: Views can be converted automatically using the Migration Workbench tool. All
views need to be graded on level of complexity (simple, medium, complex and very
complex).
Complexity items: Items that cause a views to be more difficult to migrate include:
system tables and Microsoft® SQL Server™ specific functions. ANSI standard
joins: In some case we must also rewrite views containing specific joins types
because of the lack of support in the Migration Workbench.
Total Simple (integrity only):

Total Medium (1 complexity item):
Total Complex (2 complexity item):
Total Very Complex (3 complexity item:
 Number of indexes
Why: Indexes are automatically converted if the Migration Workbench is used. If
the schema migration is done manually, an estimate needs to be made for schema
migration based upon the number of indexes.
54842860.rtf 2.1 2.1 2.1

 Number of clustered indexes
Why: Indexes are automatically converted if the Oracle Migration Workbench.
However, the same concept of clustered indexes does not exist between Microsoft®
SQL Server™ and Oracle9i. Microsoft® SQL Server™ clustered indexes mean
the data is organized in the order of the clustered index. This order is allows
maintained.
Since Oracle does not have the same concept, detailed analysis of Microsoft® SQL
Server™ clustered indexes may need to be done. In Oracle9i, Index-Organized
Tables (IOTs) can be used to simulate a Microsoft® SQL Server™ clustered index.
Index-Organized Tables were introduced in Oracle9i to provide fast, key-based
access to table data for queries that involve exact match or range search access.
Data rows are stored in the index, grouped according to the primary key. IOTs
differ from regular table indexes in that they store both the primary key and non-
key columns. The structure of an index-organized table requires a primary key
index, but also allows secondary indexes built on non-primary key columns.
 Tables with two or more TEXT columns exceeding 4000 characters

Why: An Oracle9i CHAR can be a length of up to 2000 characters. An Oracle9i
VARCHAR can be a length of up to 4000 characters. A LONG data type can be up
to 2 gigabytes in size. However, only one LONG column can exist on a table.
Oracle9i has the LOB data type that can be up to 4 gigabytes in length and there
can be up to 1000 LOB columns on a table. It is 1000 since this is the maximum
number of columns on a table.
 Tables with index on TEXT columns that exceed 4000 characters

Why: Character columns greater than 4000 characters can only be LONG and
LOB. Using the Oracle9i context option CLOB, LONG and BFILE columns can be
indexed.
54842860.rtf 2.1 2.1 2.1

 Tables with Identity columns
Why: Microsoft® SQL Server™ identity data types columns are automatically
converted if the Oracle Migration Workbench is used. A NUMBER column with
an associated sequence and trigger is created in the destination Oracle database for
each IDENTITY column in the Microsoft® SQL Server™ database. Each time a
row is inserted, the trigger queries the sequence for the next value and inserts that
value into the IDENTITY column. Additionally, this value is inserted into the
omwb_emulation user you created as part of the @@IDENTITY global variable.
This allows the T/SQL @@IDENTITY global variable to be emulated within the
Oracle Model.
 Tables with DATETIME columns

Why: Oracle9i supports the following timestamp datatypes:
 TIMESTAMP (fractional_seconds_ precision) Year, month, and day
values of date, as well as hour, minute, and second values of time, where
fractional_seconds_precision optionally specifies the number of digits in
the fractional part of the SECOND datetime field and can be a number in
the range 0 to 9. The default is 6. For example, you specify TIMESTAMP
as a literal as follows:
TIMESTAMP'1997-01-31 09:26:50.124'
 TIMESTAMP (fractional_seconds_precision) WITH TIME ZONE All

values of TIMESTAMP as well as the time zone displacement value,
where fractional_seconds_precision optionally specifies the number of
digits in the fractional part of the SECOND datetime field and can be a
number in the range 0 to 9. The default is 6. For example, you specify
TIMESTAMP WITH TIME ZONE as a literal as follows:
54842860.rtf 2.1 2.1 2.1

TIMESTAMP '1999-04-15 8:00:00 -8:00'
This can also be specified as
TIMESTAMP '1999-04-15 8:00:00 US/Pacific'
 TIMESTAMP (fractional_seconds_precision) WITH LOCAL TIME ZONE

All values of TIMESTAMP, with the following exceptions:
 Data is normalized to the database time zone when it is stored
in the database.
 When the data is retrieved, users see the data in the session
time zone.
 Number of triggers
Why: Triggers are converted automatically using the Migration Workbench. All
triggers need to be graded on level of complexity (simple, medium, complex and
very complex).
Complexity items: Items that cause a trigger to be more difficult to migrate
include: temporary tables, DDL, transaction control logic, use of inserted/deleted
tables in selects or DML, system tables, and global variables.
Oracle9i was both before and after triggers at the row and statement levels.
Microsoft® SQL Server™ only has “statement after” triggers. Microsoft® SQL
Server™ uses the “inserted” and “deleted” tables to make comparisons of old
values to new values. If the “inserted” and “deleted” tables are used in a SQL
Server trigger the Oracle9i trigger needs to be a row level trigger.
In many cases triggers can be migrated to Oracle9i table check and referential
constraints. This is because Oracle9i enforces foreign key and cascade delete
constraints at the table level (automatically, when the constraint is defined).
Total Simple (integrity only):

Total Medium (1 complexity item):
Total Complex (2 complexity items):
Total Very Complex (3 complexity items):
54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

Current use of stored procedures (if applicable)
 Total number of stored procedures
Why: Stored procedures will be automatically migrated using the Migration
Workbench tool. However, some manual coding will needed to be done. All stored
procedures need to be graded on level of complexity (easy, average and complex).
NOTE: The Migration Workbench can reduce the time to migrate stored procedures
by 40 - 80 percent. If stored procedures do not return multiple result sets to a client
application, the migration effort is much easier. This is because multiple results sets
processing is much different between Microsoft® SQL Server™ and Oracle9i.
 Percentage of stored procedures using temporary tables

Why: Temporary tables are supported in Oracle9i. Each use of a temporary table
needs to be analyzed to see how it can be migrated. However, the creation of a
temporary table in Oracle9i automatically causes a "commit transaction" to occur.
 Percentage of stored procedures using “raiserror without return”

Why: "Raiserror without return" is supported in Oracle9i by having an exception
handler for each statement and having the exception handler go to the next block of
PL/SQL code.
54842860.rtf 2.1 2.1 2.1

 Percentage of stored procedures that are returning result sets.
(stored procedures that are returning result sets).
 Single
 Multiple
Why: May need special coding to migrate to Oracle9i.
Current use of Embedded SQL/C

 Number of modules with ESQL/C-C++ using only static SQL
? Why: Code needs to manually migrate to Oracle9i Pro*C or Oracle9i OCI. If ANSI
SQL/ODBC escape sequences are used it should work with Oracle butSQL Server
specifics will need re-coding More on this can be found in section IV.
 Number of modules with ESQL/C-C++ using dynamic SQL

Why: Code needs to manually migrate to Oracle9i Pro*C or Oracle9i OCI. With
Oracle9i, it may be preferred to use the Oracle9i Call Interface in stead of
Embedded SQL to implement this. This is because Microsoft® SQL Server™
dynamic SQL is different than Oracle9i s’ dynamic SQL.
54842860.rtf 2.1 2.1 2.1

Current use of DB-Library/C
 Number of modules with DB-Library using only static SQL
Why: Code needs to manually migrate to Oracle9i OCI. More on this can be
found in section IV.
 Number of modules with DB-Library using dynamic SQL

 Number of modules with DB-Library using stored procedures

Current use of Visual Basic

 Number of Visual Basic programs
Why: The number of Visual Basic programs will impact the estimate for
converting.
54842860.rtf 2.1 2.1 2.1

 Number of Visual Basic data control objects
Why: The number of Visual Basic data control objects will impact the estimate
for converting.
 Number of places Visual Basic calls stored procedures with multiple result
sets
Why: The number of places Visual Basic calls stored procedures with multiple
result sets will impact the estimate for converting. This is because the stored
procedure will need to be rewritten.
 Is OLE-DB being used as the database access API

Why: OLE-DB is yet another abstraction layer on top of ODBC API.
However, the first version of OLE-DB was dependant on the ODBC 3.0 specs
and the new version is dependant on the ODBC 3.5 specs. Therefore, the
ODBC drive being used must be ODBC 3.5 compliant.
Another option to OLE-DB is the use of Oracle9i Objects for OLE

(OO4O).
 Do you expect to manually redesign these using Oracle9i Developer ,

Jdeveloper or Oracle9i Designer?
Why: If the MS Visual Basic application is to be totally rewritten, more time will
be needed to perform the application migration.
54842860.rtf 2.1 2.1 2.1

Current use of Powerbuilder
 Number Powerbuilder programs
Why: The number of Powerbuilder programs will impact the estimate for
converting. Normally, the only “changes” required for Powerbuilder are
replacement of the Microsoft® SQL Server™ ODBC driver with an Oracle9i
ODBC driver or Powerbuilder/ Microsoft® SQL Server™native driver with a
Powerbuilder/ Oracle9i native driver, and changing the syntax of calls to stored
procedures.
 Number of Powerbuilder data windows

Why: The number of Powerbuilder data windows will impact the estimate for
converting.
 Number of places Powerscript sends SQL to the back end

Why: The number of places Powerscript sends SQL to the backend will impact
the estimate for converting.
 Number of places Powerscript calls stored procedures

Why: The number of places Powerscript calls stored procedures will impact the
estimate for converting.
54842860.rtf 2.1 2.1 2.1

 Number of places Powerscript calls stored procedures with multiple result sets.
Why: The number of places Powerscript calls stored procedures with multiple
result sets will impact the estimate for converting.
 Do you expect to use third party tools to migrate these

Why: A third party tool can decrease the conversion estimate. More on this can
be found in section IV.
 Do you expect to manually redesign these using Oracle9i Designer or

Oracle9i Developer
Why: If the Powerbuilder application is to be totally rewritten, more time will be
needed to perform the application migration.
Current use of other application development tools
 Do you use UNIFACE, Delphi, MS Access or some other application development

tool? Which one?
Why: Typically independent 3RD party application development tools are easier to
migrate than proprietary tools such as Embedded SQL/C or Microsoft® DB-Library.
Most tools support the major database vendors: Oracle9i, Sybase and Microsoft®
SQL Server™.
54842860.rtf 2.1 2.1 2.1

 How many windows does the system have? How many have database access?
Why: If the database access code contains Microsoft® SQL Server™ specific syntax
it may need to be manually modified.
 Is the SQL embedded in the tool or are stored procedures used?

Why: As a rule, it is easier to migrate applications that use embedded SQL then it is
to migrate applications that use stored procedures. This is because stored procedures
contain a proprietary database SQL programming language and return multiple
result sets to the client.
Support
 DBA Maintenance Scripts? (Examples: backup, recovery, database integrity, index

rebuilds)
Why: The scripts will contain database proprietary NT commands and SQL.
54842860.rtf 2.1 2.1 2.1

 DBA tools and scripts? (Examples: 3RD party backup tools, 3RD party DBA tools,
import/export scripts)
Why: These tools and scripts will have to migrated, or alternatives found.
 Other? (Examples: ad hoc scripts)

Why: These tools, utilities and/or scripts will have to migrated.
54842860.rtf 2.1 2.1 2.1

Other special logic/subsystems to migrate
 Any other special subsystems or special processing the system performs?

(Example: A security subsystem that implements security, by user,
horizontally/”by row”. )
Why: These special subsystems have to migrate, or alternatives found. Perhaps
Oracle9i has the same functionality built-in. Oracle9i has built-in functionality for
row level security.
54842860.rtf 2.1 2.1 2.1

Documentation
 System documentation (Examples: system flows, program functionality)

Why: System documentation will most likely change.
 User documentation
Why: User documentation will most likely change.
54842860.rtf 2.1 2.1 2.1

Section III - Migration Workbench Tool
Overview
Oracle Migration Workbench is a tool that simplifies the process of migrating data and applications from non-
Oracle databases to Oracle9i. The current migration approach is to run multiple scripts to unload and load the
data dictionary, and convert application files in a number of unrelated steps. Oracle Migration Workbench
allows you to quickly and easily migrate an entire Application System — the database schema, users, stored
procedures, and embedded SQL — in an integrated, visual environment.
Product Description
Oracle Migration Workbench allows you to define a migration project, detailing the various database and
application components of the Application System to be migrated. Once a migration project has been defined,
you can use various Workbench tools to migrate the Migrable Components of the Application System. Oracle
Migration Workbench provides an intuitive and informative user interface, and the migration process is
simplified by the use of wizards.
The User Interface makes Oracle Migration Workbench extremely easy to use. To migrate an Application
System, you invoke the New Project Wizard to create a Workbench project that describes the source and
destination databases. The New Project Wizard will, in turn, invoke the Migration Wizard to carry out the actual
migration.
54842860.rtf 2.1 2.1 2.1

Section IV - INFORMATION/SOLUTIONS
Microsoft® IIS/ASP
 Microsoft Architecture
In Microsoft, the five components used to access SQL Server data from the web are:
IIS, ASP, VB Script, ODBC and stored procedures(optional). The ASPs reside in IIS
and contain the HTML formatting logic; ASP logic is written using Vbscripts and
contains ODBC calls to SQL Server. The database logic maybe in the SQL Server in
the form of stored procedures.
 Oracle9i solution
The Oracle9iAS Migration Kit for ASP (Active Server Pages) enables customers
with Microsoft IIS/ASP applications, facing performance, scalability and reliability
problems; to migrate to the open, standards based Java 2 Platform, Enterprise
Edition (J2EE). Understanding that Microsoft customers have large investments in
existing technology and personnel, Oracle provides a phased approach to migration,
allowing customers to embrace, improve and finally replace the Microsoft
technology stack.
Oracle9iAS Migration Kit for ASP in conjunction with Oracle Migration
Workbench offer a complete solution to migrate IIS/ASP applications and
supporting databases to Oracle9i iAS and Oracle9i DB.
Microsoft® SQL Server™ Database
The Microsoft® SQL Server™ database migrates fairly easy to the Oracle9i
database. A few differences are worth noticing:
 Case insensitive database - Microsoft® SQL Server™ allows a SQL Server to be
installed as case insensitive. In Oracle9i, this is not allowed so and additional
column with all upper case needs to be created. In Oracle9i, this problem is
resolved because Oracle9i allows indexed to be created using functions on
columns.
 Identity datatype - This becomes a sequence number in Oracle9i
54842860.rtf 2.1 2.1 2.1

Microsoft® SQL Server™ SQL
Microsoft® SQL Server™ SQL and Oracle9i SQL are both based upon the same
underlying ANSI database language standards. However, RDBMS providers have
often added their own extensions to the standard language. This engine-specific SQL
is for the most part handled by the Migration Workbench tool.
 CASE Statements - The CASE statement is used to perform different actions in the
return columns based upon the value in a column.
Solution 1: Tool replaces CASE statements with the Oracle9i DECODE
statement.
Solution 2: You can use the Oracle9i CASE statement directly in PL/SQL.
 Other SQL differences - SQL difference were asked for in section II.
Solution: Solutions are given in the appendix of the scope document.
Microsoft® SQL Server™ Stored Procedures
Microsoft® SQL Server™ stored procedures can be migrated to Oracle9i with the
help Oracle Migration Workbench. However, there are a few features of Microsoft,
which do not map to features in Oracle9i, or only maps with modifications:
 Results set: Microsoft® SQL Server™ stored procedures can return data to the
calling environment by means of a SQL query inside the stored procedure. The
Stored Procedure Converter implements this using cursor variable, which implies
application modifications are necessary. The Oracle ODBC and OLEDB drivers
make this problem invisible to the application unless multiple result sets are
passed back.
Solution: Slight changes to the application when stored procedures are called.
 DDL: Microsoft® SQL Server™ stored procedures can contain DDL. In
Oracle9i DDL is allowed, however, an implicit commit occurs.
The Oracle Migration Workbench ignores most Microsoft SQL Server DDL
commands and writes a warning to the Log window.
Solution: Remove DDL from the stored procedure or use Dynamic PL/SQL to
solve some of these commands.
54842860.rtf 2.1 2.1 2.1

Microsoft® Embedded SQL/C-C++ and COBOL
The syntax used in Microsoft® Server™ for Embedded SQL from C/C++ and
COBOL programs is different from that used by Oracle.
Solution: The code needs to be converted manually.
DB-Library/C-C++
DB-Library code is similar to Oracle9i OCI.
Solution: Re-code the DB-Library calls to OCI calls. Oracle9i has write papers
and example code on how this is done.
Visual Basic
If stored procedures are not used, the only things to change are Oracle9i ODBC
driver, Oracle Net on client, and minor SQL statement changes. If stored procedures
are used but do not return multiple result sets, then the things to change are Oracle9i
ODBC driver and Oracle Net on client. If stored procedures are used that return
multiple result sets, then the things to change are Oracle9i ODBC driver that supports
reference cursors, Oracle Net on client, changes to the stored procedure calls, and
changes to handling results with multiple reference cursor.
Solution: The solution is dependent upon how the application is code: embedded
SQL or stored procedures. The paragraph above gives the options.
Powerbuilder
If stored procedures are not used, the only things to change are Oracle9i ODBC
driver or Powerbuilder native driver for Oracle9i, Oracle Net on client, and minor
SQL statement changes. If stored procedures are used but do not return multiple
result sets, then the things to change are Oracle9i ODBC driver or Powerbuilder
54842860.rtf 2.1 2.1 2.1

native driver, Oracle Net on client, and minor SQL statement changes in stored
procedure. If stored procedures are used that return multiple result sets, then the
things to change are Oracle9i ODBC driver that supports reference cursors or
Powerbuilder native driver, Oracle Network on client, and changes to the stored
procedure calls.
Solution: The solution is dependent upon how the application is code: embedded
SQL or stored procedures. The paragraph above gives the options.
54842860.rtf 2.1 2.1 2.1

Data-Access APIs
Microsoft® SQL Server™ owes its continued growth in part to its easy and efficient
data access for legacy applications and the latest object frameworks. The APIs I list
here are the gateways that let SQL Server function as a data source both for
traditional, 2-tiered client/server applications and as a data source for Web and n-
tiered applications.
ESQL/C (Embedded SQL for C)
One of the original Microsoft® SQL Server™ data-access technologies, ESQL/C

uses embedded SQL statements in C code to access SQL Server databases. A
preprocessor for C converts the SQL statements into DB-Library function calls that
are incorporated into the executable program.
DB-Library
The DB-Library is primarily a C implementation, but Microsoft® SQL Server™ also
provides a .bas file that lets you use this library with Visual Basic (VB). Although
legacy applications still use the DB-Library, it doesn't support the latest SQL Server
7.0 enhancements, and Microsoft won't enhance DB-Library in the future.
ODBC
ODBC provides a vendor-independent database-access API. The ODBC API has been
wildly successful as a database-access standard. Virtually all products that require
database access support it, and the most recent ODBC driver supports the Microsoft®
SQL Server™ 7.0 enhancements. You use a call-level interface (CLI) to implement
the ODBC API.
Data Access Object (DAO)

Microsoft developed DAO to provide access to the Microsoft JET database, which
Access uses. DAO is a COM-based object framework that Microsoft later expanded
to address ODBC connectivity. DAO is much easier to use than its CLI-based
predecessors, but its JET orientation made it less than optimal for connecting to
54842860.rtf 2.1 2.1 2.1

ODBC data sources such as SQL Server. About two years ago, Microsoft introduced
ODBC-Direct, a better ODBC-based extension to DAO. But by then, developers had
widely adopted Remote Data Objects (RDO).
54842860.rtf 2.1 2.1 2.1

RDO
The RDO object framework combines the best of DAO and ODBC. Like DAO, RDO
is COM-based. Unlike DAO, RDO was developed to work with ODBC. RDO is easy
to use and provides good Performance. However, although RDO is good at
relational database access, that task is all it does. You can't use it for no relational data
access. Microsoft phased out RDO in recent releases of Access and VB.
OLE DB
Positioned as the successor to ODBC, OLE DB provides access to relational and no
relational data sources. OLE DB is the cornerstone of Microsoft's Universal Data
Access strategy, and you can use OLE DB to access any data source that can be
represented by a row-and-column format. But despite OLE DB's COM foundation,
to directly use the OLE DB API, you need a language that supports pointers—in other
words, C++.
ADO
ADO's position as my number-one data-access API shouldn't surprise you. Like DAO
and RDO, ADO is a COM-based object framework. Unlike its predecessors, ADO is
an object framework over OLE DB. So, you can use ADO and OLE DB in
development tools such as VB, VBScript, Java, JScript, and ASP. If you develop new
database applications, say ADO to those old data-access technologies.
54842860.rtf 2.1 2.1 2.1

Oracle Partner Technical Services: M SQL Server™ Service O

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Oracle Partner Technical Services: M SQL Server™ Service O

Caricato da

Copyright:

Formati disponibili

MICROSOFT® SQL SERVER™ SERVICE OFFERING:

Author: Tom Laszewski

Date Author Version Change Reference

November 30, 2001 Frédéric Janski 2.1 Modifications to Oracle 9i format.

Copy Number _____

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

Section I - General Information.........................................................................3

Current use of stored procedures (if applicable)........................................18

Current use of Embedded SQL/C..............................................................20

Current use of DB-Library/C.....................................................................21

Current use of Visual Basic........................................................................22

Current use of Powerbuilder......................................................................23

Current use of other application development tools..................................26

Other special logic/subsystems to migrate.................................................28

54842860.rtf 2.1 2.1 2.1

Section III - Migration Workbench Tool..........................................................30

Microsoft® SQL Server™ Database...........................................................31

Microsoft® SQL Server™ SQL..................................................................32

Microsoft® SQL Server™ Stored Procedures............................................32

Microsoft® Embedded SQL/C-C++ and COBOL......................................33

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

4? Section 4(Information/Solutions) - Contains information about converting systems from Microsoft®

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

E-mail address Manager:

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

 Describe the business use of the system:

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

 Describe use of Microsoft® Message Queuing Server (MSMQ).

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

 Microsoft® SQL Server™ version number

 Has the SQL Server been installed as case insensitive?

 Type of system (such as: OLTP, OLAP, data warehouse etc.)

54842860.rtf 2.1 2.1 2.1

 Size and usage of tables

54842860.rtf 2.1 2.1 2.1

 Look up tables (number and size):

Total Simple (integrity only):

54842860.rtf 2.1 2.1 2.1

 Tables with two or more TEXT columns exceeding 4000 characters

 Tables with index on TEXT columns that exceed 4000 characters

54842860.rtf 2.1 2.1 2.1

 Tables with DATETIME columns

 TIMESTAMP (fractional_seconds_precision) WITH TIME ZONE All

54842860.rtf 2.1 2.1 2.1

This can also be specified as

TIMESTAMP '1999-04-15 8:00:00 US/Pacific'

 TIMESTAMP (fractional_seconds_precision) WITH LOCAL TIME ZONE

Total Simple (integrity only):

54842860.rtf 2.1 2.1 2.1

54842860.rtf 2.1 2.1 2.1

 Percentage of stored procedures using temporary tables

 Percentage of stored procedures using “raiserror without return”

54842860.rtf 2.1 2.1 2.1

Current use of Embedded SQL/C

 Number of modules with ESQL/C-C++ using dynamic SQL