Oracle Objects for OLE (OO4O) Version 2.1.03.1 Production

Release Notes

May 1997

This file contains important information specific to the Production release of Oracle Objects for OLE version 2.1. The following topics are covered:

* System requirements

* Oracle Data Control Limitations

* Limitations

* Getting Started

* Redistributable Files

* New Features

* Summary of problems fixed by version and known issues

System Requirements

* Intel-based PC running Windows NT, Windows 95 and Windows 3.1

* Minimum 486-50Mhz processor (Pentium recommended).

* 8 Mb memory (16 Mb recommended).

* 4-10 Mb free disk storage for the OO4O program files.

* Enough additional disk storage to create a local cache the size of your largest dynaset.

We recommend about 10 Mb of free disk space in your swap partition.

* 16-bit application capable of OLE scripting (e.g. Visual Basic 4, Excel 5.0/7.0, etc.) or

supported C++ compiler (Microsoft Visual C++ 1.5 ).

* Access to an Oracle7 database, either a local connection or via a network using

SQL*Net. Oracle 7.x and Oracle 8 are all supported.

* Oracle Required Support Files 7.3 .

Oracle Data Control Limitations

Please note that the current VBX (data control) will only work with VB 3.

There will not be a 16-bit OCX data control.

The reasons we have chosen not to build the 16-bit OCX data control are

- The specification from Microsoft on the 16-bit version of OCX data control

is extremely ambiguous; in fact, it's not even complete.

- It is complex, costly, and nearly impossible to develop a 16-bit version of

the OCX data control that will behave exactly like the existing VBX data

control. If we did build one, the OCX data control will surely exhibit some

differences that will be unacceptable to customers.

- Our understanding is that the 16-bit OCXs are slower and buggier than their

VBX counterparts. If this is true, then the 16-bit OCX data control will

certainly be difficult to support and maintain, and we will not be able to

provide Oracle quality software to our customers.

Limitations.

This release is a 16-bit version of Oracle Objects for OLE and will work on Windows 3.1 and the 16 bit subsystem of Windows NT or Windows 95 and Win-OS\2.

Class libraries are provided for Microsoft Visual C++ version 1.5 only.

In this release we are discontinuing support for Borland's C++ compiler. This release does not include OO4O class libraries for Borland C++ and bound control libraries for OOWL.

What is included in this release.

16 bit In Process Server OIP for Windows 3.1, Windows NT and Windows 95.

16 bit Class Libraries for Microsoft C++ 1.5x (MFC 2.5).

16 bit VBX data control for Visual Basic 3.

Getting Started

Considerations when moving from Visual Basic/JET/ODBC to OO4O

1. Oracle Objects for OLE Version 2.1 currently does not have a Data Control for Visual Basic 4. VB 3 users should check your 3rd party data aware controls to see if they are compatible with the Oracle Data Control VBX.

2. Read the topic on Error Handling since Oracle Objects for OLE error handling is significantly different.

3. Read the topic on Coding Techniques to avoid unnecessary object references.

4. Read the topic on Tuning and Customization so you may tune the data cache to suit your needs.

5. Read the new Tour Guide in the VB sample directory.

6. Read the section PL/SQL Supports to take full advantage of PL/SQL stored procedure interfaces.

Basic Steps to convert from Visual Basic/JET/ODBC to OO4O

1. Replace the VB data control with the Oracle Data Control .

2. Correct the Connect/Database name properties.

3. Correct the options on OpenDatabase() and CreateDynaset().

4. Change variables from native types to type 'OBJECT'.

5. Check your use of FieldSize(), GetChunk() and AppendChunk().

Building the C++ Sample Applications

Since Microsoft Visual C++ 1.5 stores path information in the MSVC.INI file, we cannot supply the path information for local environment. In those cases you will probably need to modify the project to include the required paths. You should also read the compiler specific documentation 'Bound Controls for MFC ' for the compiler you are using.

Typical Installation Layout

As part of a Typical Installation the following directories will be created and will contain the corresponding files (the ORAHOME directory is typically ORANT for Windows NT, ORAWIN95 for Windows 95, or ORAWIN for Windows 3.1):

\ORAHOME\MSHELP - Oracle Objects online documentation.

\ORAHOME\OO4O21 - SQL scripts and constants file.

\ORAHOME\OO4O21\CPP - Libraries, includes, DLLs, and source for the class library.

\ORAHOME\OO4O21\CPP\MFC - Libraries, includes and source for the MFC Bound Class Library.

\ORAHOME\OO4O21\EXCEL\SAMPLES - Excel Samples.

\ORAHOME\OO4O21\VB\SAMPLES - Visual Basic 4.0 Samples.

\ORAHOME\OO4O21\VB\SAMPLES\QT - Visual Basic 4.0 Quick Tour guide.

Tuning and Customization Parameters

Fetch and Cache parameters for a dynaset can be set in the following ways

a. ORAOLE.INI section (affects all dynasets created with CreateDynaset), or

b. Dynasets created with the CreateCustomDynaset methods, or

c. Each of those parameters can be individually set for a particular Dynaset object/Data Control.

The following are the range of values for the Cache and Fetch parameters

SliceSize 64-32752

PerBlock 4-255

CacheBlocks 1-128

FetchLimit 1-1000(recommended)

FetchSize 1024-32752

Note: For more information on the parameters please check the Tuning and Customization section in the online help.

New Features

New features have been documented in the online help system. Care has been taken so that existing features of the previous version are supported. The following is a partial list of new features. Full documentation of these new features is provided in the online help.

* PL/SQL cursors from the stored procedures are available as read-only Dynaset objects.

This feature enables business rules to be encapsulated centrally in the Oracle Servers, and prevents the need for frequent client software updates. It supports stored procedures that have CURSOR as its out parameter.

Note: The PL/SQL examples in the online help use the package specified in EMPCUR.SQL.

* PL/SQL stored procedures can now be executed using the SQL Statement (OraSqlStmt) object. This has several advantages over the original ExecuteSql method. The main benefit is that parameters can be bound to the object which can be refreshed with new parameter values. Previously you needed to call ExecuteSql each time you wanted to run the stored procedure.

* PL/SQL tables (arrays) can now be returned using the Parameter Array (OraParamArray) object. Array update and insert operations can also be performed using the Parameter Array object.

* Dynaset's field data can be copied to the Windows Clipboard using CopyToClipboard method on dynaset object. This command will copy the result of a query, or a portion thereof, to the Windows clipboard, with any user-defined column and row delimiter. This method will be particularly helpful for pasting data in bulk into applications such as Excel and Word.

* Dynaset cache and fetch characteristics can be tuned using CreateCustomDynaset to create the dynaset with specified cache and fetch properties.

* Dynaset Movexxxx methods have been expanded to provide forward and backward movement through multiple records.

* The insert mode can be specified for a dynaset as well as the database object. Please note that the dynaset inherits the database insert mode and that if multiple options are specified, the highest mode in the list below (on either the database or dynaset object) will be used.

ODYNASET_ORAMODE (sometimes called partial insert). Fields containing no value (NULL) at time of insert are not added to the insert SQL statement. This allows the RDBMS to use default values from a default clause (used when creating a table) or via a trigger. The newly inserted row is immediately refetched to keep the local cache synchronized.

ODYNASET_NOREFETCH. As with ORAMODE, database defaulting is allowed but the data is not refetched. This will give enhanced performance but will result in error OIP 4119-Data has been modified if you subsequently try and edit the same row.

ODYNASET_DEFAULT (sometimes called VB mode). Explicit NULLS are inserted which prevent database defaulting and the row will not be refetched. Note that a database trigger could still cause some values to be modified on insert.

* Extra dynaset modes: NO_MOVEFIRST creates a dynaset without moving to the first record. DIRTY_WRITES allows updates to be forced even if the data has been changed by another user. This is contradictory to the way most Oracle applications work but is provided for compatibility with the VB/JET model.

* Supports non-blocking SQL calls using option DB_NONBLOCK on the Database object creation. Note that non-blocking calls are only supported by Oracle Server 7.2 (and higher) and SQL*Net 2.2 (and higher).

* RDBMS version string is available on the Database object.

* Field expressions can now be used in dynasets. Any such field expression is recognized before the dynaset is created and the field is marked 'non-updatable'. The dynaset itself will now be updatable but field expressions will not be included in update or insert statements. A field expression can be a SQL function call, a literal, or binary operation. For example, the following SQL statement now produces an updatable dynaset:

select ename, // regular updatable columns

empno,

nvl(comm,0), // SQL function call

sal + 500, // binary operator +

job || ' APE', // binary operator ||

deptno // regular updatable column

from emp;

However, only regular fields 'ename', 'empno', 'deptno' will be updatable.

Regular fields can also be marked as non-updatable using the OraField Updatable property. This is useful in cases where certain fields are non-updatable such as rowid, sysdate etc.

For example on can update the following dynaset

select empno, // regular updatable column

rowid, //Non-updatable field

deptno,

ename // regular updatable columns

from emp;

VB Code follows

Set OraDynaset = OraDatabase.DbCreateDynaset("select empno, rowid, deptno,

ename from emp_empty", 0&)

Set OraFields = OraDynaset.Fields

OraFields("rowid").Updatable = False //Set field to Non-updatable

OraDynaset.AddNew

OraFields("empno").Value = 9999

OraFields("ename").Value = "aaa"

OraFields("deptno").Value = 10

OraDynaset.Update

The corresponding C++ methods (for the ODynaset object) are as follows

oboolean IsFieldUpdatable(int index) const;

oboolean IsFieldUpdatable(const char *fieldname) const;

oresult SetFieldUpdatable(int index, oboolean update) const;

oresult SetFieldUpdatable(const char *fieldname, oboolean update) const;

* AppendChunk has been expanded to allow for RAW data. The previous version takes only a string for its argument. This means that RAW data containing embedded NULL characters may get truncated and converted to a multibyte string according to the language setting. This causes a total failure in (for example) Japanese and only partial functionality in English. A new method (AppendChunkByte) has been added to the ORAFIELD interface to correct this problem. Note that it take two arguments. The first argument must be an ARRAY of type BYTE and contain the raw data to be appended. The second argument is the size of the chunk in bytes. You can read chunks into a byte array using GetChunkByte, which returns an integer indicating the number of bytes actually read:

dim raw_data(32000) as byte

orafield.AppendChunkByte (raw_data(0), len)

numread = orafield.GetChunkByte (raw_data(0), offset, len)

Note that the byte array must allocate enough space in your program using the Dim statement and it must be passed by reference. To pass by reference, you can simply pass the first element of the array as shown above. Consult your Visual Basic documentation for more information on byte arrays.

* Find methods are now available in dynasets. This is implemented by a local parser which resides only on the client in most cases. Full Oracle functionality is provided including operators such as like, between, and in(), and the Boolean AND and OR logic. The first time a Find method is called, a parser object is created and the where clause is parsed and stored. A search for matches in the dynaset is then performed and the dynaset is positioned on the first matching row, else the NoMatch property is set TRUE. If a Find method is then called with the same or NULL where clause, it is not re-parsed; the stored version is used instead. Only one parser is stored per dynaset, so that specifying a new WHERE clause destroys the currently stored one.

The Find methods have the following effects on navigation:

FindFirst Move to the first record in the dynaset and search forwards for matches.

FindLast Move to the last record in the dynaset and search backwards for matches.

FindNext Search forward for matches from the current position in the dynaset.

FindPrevious Search backward for matches from the current position in the dynaset.

If no matching row is found by a Find method, the NoMatch property of the dynaset is set to TRUE and the dynaset will be on BOF or EOF depending on the search direction. For example, FindNext leaves you on EOF when there are no more matching rows.

Most SQL and Oracle functions are supported by the parser. In order to keep the parser as small as possible, where clauses containing function calls are submitted to the Oracle7 server. A query is generated for each row being matched and the function is executed by selecting from DUAL. DUAL is a table owned by the SYS user and is usually granted SELECT to ALL users. If you are experiencing problems such as always getting NoMatch set TRUE when using a SQL function, check for the existence of DUAL in the user's schema. If you cannot execute the following SQL statement in SQL*Plus (or using a dynaset!), you will need to create DUAL or a synonym for the public one.

select dummy from dual

Although it is preferable that you create a synonym and obtain the necessary grants, you can create DUAL in the user's schema using the following SQL statements:

create table dual (dummy varchar2(1));

insert into dummy values ('X');

Your database administrator will be able to provide more details.

* The C++ class libraries have been updated and new interfaces have been added to the OField object to support both string and raw data to AppendChunk() and GetChunk(). The first parameter to each of these function can now be of type void or char. No re-coding of C++ applications is required to use this new feature.

* The in-process server files as well as the data control files (oip21.dll, oip21.tlb, oradc.ocx) are now copied to the [ORACLE_HOME]/BIN directory. So please make sure that [ORACLE_HOME]/BIN is on the path before attempting to run OO4O.

Summary of problems and bug fixes.

The following are known issues with the new features:

PL/SQL cursor

Currently PL/SQL Packages that have functions that return cursors are not supported. This is the limitation of PL/SQL packages and not OO4O. Stored procedures that have more than one cursor variable in its out parameter are not supported since this requires the implementation of dynaset collection object.

Find Methods

* The like operator will not work in multibyte languages.

* Table or synonym 'DUAL' is required in user's schema.

* Date values are retrieved and compared in VB format (actually the format specified in the Control Panel). Therefore date comparisons will fail if any other format such as the default Oracle format 'DD-MON-YYYY' is used.

* SQL function TO_CHAR(date, fmt) cannot be used because the first argument must be a date in native Oracle format and OO4O only handles 'string dates'.

* SQL function TO_DATE will convert a string to a date, but the OIP will convert it back to a string in VB format as described above and the comparison may still fail.

* FindPrevious and FindLast in a NO_CACHE dynaset will not work; NoMatch will be set TRUE.

Non-blocking OCI calls and SQL*Net 2.2

We have encountered some problems using the non-blocking OCI calls. The problems seem to be with timing in the SQL*Net layer, and affects SQL statements that contain many bind variables and generate heavy network traffic. In particular, updating a table containing 250 columns or passing an array of 4000 dates to a stored procedure both produce errors. Local connections do not exhibit this problem.

A patch for SQL*Net was produced (version 2.2.2.1.3) which helps alleviate some of the problems but some still remain. The problem has been completely fixed in SQL*Net version 2.3.2.1.0.

If you are experiencing problems using the non-blocking option please try the following before reporting a bug:

* Connect to a local server (using 2:) if you can.

* Create the database object without using non-blocking mode.

* Upgrade to SQL*Net 2.3.

The following differences in behavior (from version 1) have been noted:

The default property "value" will have to be explicitly used for the OraField object. This means that

you cannot currently code something like:

OraField myfield = fields("empno")

OParameter myvalue = myfield ' Uses the default property

Instead, you will need to code the second line like this:

OParameter myvalue = myfield.value ' Explicitly use the value property

This behavior has also been seen with the VB Edit Control, but only when the control contains an empty string. For example:

OraField myfield=fields("ename")

myfield.value = Text1 ' Uses the default property

The second line should be

myfield.value = Text1.Text ' Must use explicit 'Text' property

This appears to be a problem in VB4 (16 and 32-bit) as the same code works in VB3 (16-bit). We cannot determine when the default property can be safely used and when it cannot. Therefore, we recommend you always use explicit properties for all objects when using Oracle Objects For OLE in Visual Basic 4.0.

Version 1 allowed 'dirty' delete where you could delete a row in the database that had been changed by another user. This is considered a bug and has been 'fixed' in Version 2. However, this might cause your application to encounter an error when it did not before. The error you will get is OIP 4119-Data has been modified (the same error as if you tried to update a row that had been changed). If you need 'dirty' deletes, you can turn off checking for both delete and update with the ORADYN_DIRTY_WRITE flag when you create the dynaset.

Some error codes have changed and applications that attempt to 'trap' certain errors by number will not work any more. This does not apply to error codes in the range 4096 to 4134 - they have not changed.

There appears to be a limit of 128 bytes when retrieving error messages from the server. The symptom is that a call to the Oracle7 server may fail shortly after a long message has been retrieved. It is random and behaves differently with different versions of SQL*Net and/or the RSF. We believe this is a problem in these intermediate layers or with Unicode conversion. Unicode is the 32-bit Windows representation of a string that allows for double byte character sets such as the Japanese language Kanji. This is not usually a problem as most server error messages are short. However, it is possible to create user-defined server errors of any length that may exhibit this behavior. Note that the OIP will truncate a very long message to 1024 bytes, but this is unrelated to the problem reported here.

Notes for users of Oracle version 7.3.2

There is a known problem with the Oracle RDBMS version 7.3.2.0 affecting LONG columns. If you intend to use LONG columns in dynasets and are using Oracle 7.3, please note the following. When inserting a new row into (or updating an existing row in) a table containing a LONG column, you will get error OIP 4119-Data has been modified if you subsequently try and edit the same row. This is because the database is returning NULL for the LONG column just inserted when we try to lock the row by using SELECT ... FOR UPDATE. The data really is in the database, but cannot be accessed using SELECT ... FOR UPDATE. There are three workarounds. The first is to avoid editing the same row more than once! The second is to create the dynaset using the 'DIRTY_WRITE' option. This will prevent the OIP from attempting to lock the row, but has the disadvantage of allowing your application to edit a row that really was changed by another user. The third option is to use the Refresh method of the dynaset after every Update. This maintains data integrity but will have a severe impact on performance. The fix for this problem is planned for a future release of Oracle7. Interested users may want to check if the version of Oracle7 they have is higher than 7.3.2.0 and contains the patch for bug# 348967.

Bugs or problems fixed in Version 2.1.03.1 Production

General

* GPF In NLS32WIN.DLL When Running/Closing Multiple 16-bit apps.

* Using bogus password with a second database connect (after a succesful first connection) now correctly returns an ORA-01017 error (Invalid username/password: logon denied).

* Oracle Data Control(OCX) does not respond to the "BeforeDelete" event for the MS Databound Grid.

* Run Time error 438 : Attempting to use early binding.

* Transaction is not auto-commited after executing CreateSQL method.

* Re-Displaying of Rows in Sheridan Grid control with Oracle OCX data control

* "Reposition" event is fired before the row is positioned in the dynaset.

Bugs or problems fixed in Version 2.1.02.1.0 Production

General

* SELECT C1||C2||C3||... causes GPF on CreateDynaset

* EMPEDT samples under C++ class library gives unhandled exceptions

* CreatePlsqlDynaset returns one less row

* Bind parameters do not return nulls where nulls are expected

* GPF when creating dynaset with function and parameter

* OraDynaset is non-updatable if its order by clause has multiple expressions

* RPAD() function in WHERE clause makes dynaset read-only

* Error OIP-4126 when retrieving null value from PL/SQL array

* Retrieving null value from PL/SQL array causes 'invalid use of null' error

* Invalid argument in OCI call when inserting with appendchunk method

* Error oip-4131 when selecting a long column

* Selecting filled-up varchar2 column causes PL/SQL error

* Create dynaset gives oip-4130 error (invalid data cache parameter)

* Inserting/updating or deleting a row in a dynaset causes GPF

* Orafields().OriginalName causes GPF

* Move methods generates an oip-4108 error

* Default row separator of CopyToClipboard method is newline only

* Copytoclipboard always copies 2 rows

* ExecuteSql call does not close cursor upon execution

* Getting find parser debugging messages while running application

* CopyToClipboard crashes Excel when column separator is a nonzero number

* Cannot use original field name to set value of last column

Bugs or problems fixed in Version 2.0.7.5.1 Production

General

* Cannot create more than six dynasets.

Bugs or problems fixed in Version 2.0.7.2 Production

General

* AppendChunk using RAW data can corrupt the data being stored (see New features).

Bugs or problems fixed in Version 2.0.7 Production

General

* When using NO_MOVEFIRST option; AddNewRecord, then Edit results in OIP-4098 (Invalid position).

* AddNewrecord on truncated table gives OIP-4108.

* AddNewrecord to empty table, fails on DuplicateRecord.

* AddNewrecord with number(4,10) column causes StartEdit to fail.

* NO_CACHE dynaset option breaks MoveLast when number of records is multiple of FetchLimit.

* Getting field value after adding new row to dynaset (with ORAMODE option) cause GPF.

* Reading or writing custom dynaset properties on closed dynaset causes unhandled exception.

* Change in field value triggered by the Server does not reflect immediately in dynaset.

* Updatable property for field objects does not work.

* Result set not ordered properly when SQL statement contains clause 'order by #'.

* No error message/number reported when OS file handles limit is reached.

* Not handling temp file creation problems gracefully.

* Submitting an incomplete find clause causes an unhandled exception.

* Using NoMatch property incorrectly resets the error state.

* NVL function in find clause raises error message OIP-4099: Field 'xxx' not found.

* Find methods sometimes fail to return correct row.

* Random failure in Find methods using SQL function calls.

* UPPER and LOWER functions do not work when used in Find methods.

* MinimumSize property for ParameterArray returns zero.

* GetValue on Parameter Array overwrites memory of previous array elements.

* Array inserts into NUMBER columns cause loss of precision.

* SQLStatement object RecordCount property does not work for Array inserts etc.

* Cannot pass string parameters back from stored procedure if initialized with less than 128 characters.

* Scalar Parameter object not truncating time portion of outputted date values.

* Passing variable into the second parameter of Parameters.Add causes OLE error.

* GPF in oraipsrv.dll when using VB 'for...each' for OraParameter Collection.

* Cannot connect to database if Japanese username is used.

* Cannot create a dynaset when using NLS code page.

* GetField function is not processed when Japanese field name is used.

* DuplicateRecord function returns error when Japanese column name is used.

* Update function returns error when Japanese column name is used.

* StartEdit function returns error when Japanese column name is used.

* Copyright/Trademark symbols in version info. is not showing in Japanese OS.

Oracle Data Control Specific

* Oracle Data Control causes OIP-4119 after giving it a decimal value of '#.0'.

* Grid and ORADC: hanging problem when using values '0.###'.

* DLL not found error when using debug version of oraclb.dll.

Oracle C++ Class Library Specific

* When adding or duplicating records using OBinder, navigation can become confused.

Bugs or problems fixed in Version Beta 2.0.3

General

* When using the NO_MOVEFIRST option on dynaset creation, EOF and BOF are not set to True.

* ERROR$ does not contain error text for all errors listed in Error Handling (VB).

* Session.Rollback when applied to Data Control appears to commit instead.

* EOF not returned correctly from dynaset when number of rows matches FetchLimit.

Enhancements added to Version 2.0.x

* Provide explicit Close methods for all objects for compatibility with VB.

* Provide Find methods and NoMatch property on dynaset.

* Provide tunable dynasets with extra cache/fetch parameter properties.

* Provide NO_MOVEFIRST option on dynaset.

* Provide additional Move methods e.g. MoveNextN.

* Provide ability to return PLSQL tables from stored procedures.

* Provide ability to reference field names that are expressions e.g. 'SUM(sal)', 'NVL(comm, 0)', 'sal+100'.

* Support Japanese Borland C++ version 4.52.

Bugs or problems fixed in Version 1.0.59, 1.0.6x

General

* OO4O creates a lot of network packets.

* Oracle data Control does not work when VB application is compiled (affects patch release 1.0.59 only).

* Overhead from two selects in readonly dynaset creation not justified.

* Using select on a LONG column returns OIP-4131 (with readonly dynaset).

* Recursive update on a dynaset containing a LONG gives OIP-4119 after 16 records.

* Explicit ROWID in SQL query is not found in Field Collection by column name.

Oracle Data Control Specific

* TrueGrid: Won't populate sum(x) columns

Bugs or problems fixed in Version 1.0.57.0

General

* Oracle data control subtracts 1 second from time when committed.

* Conversion from Excel date to Oracle date loses a second.

* Signalling event messages > 127 bytes cause ORA-6512.

* Cannot pass varchar2 back from PLSQL if size > 128.

* MinimumSize property of OraParameter not readable.

* Deallocating C++ objects results in memory leak.

* Apparent memory leak when recycling dynasets.

* Memory leak with dynaset operations.

* Memory leak when using the LastServerErrText property.

Oracle Data Control Specific

* ORADC: Memory leak when scroll through images.

* Truegrid: ORADC buttons get suck in down position on ORA-1407.

* WMF files cannot be displayed using a picture/image control and ORADC.

Oracle C++ Class Library Specific

* OMFC: Horizontal scroll bars do not work.

* In addition, several enhancements have been made to the way we communicate with the Oracle7 Server, giving enhanced performance and faster response for the initial query and subsequent updates. The normal fetching of data from the server is unaffected.

Enhancements added to Version 1.0.55.0

General

* Return the number of rows processed from ExecuteSQL/Add GetRowsProcessed to ODatabase.

Oracle Data Control Specific

* Added support for the VB Image and Picture controls.

Oracle C++ Class Library Specific

* Added IsFirst, IsLast methods to OBinder class.

The Type/Size Properties

* The Type property now returns meaningful values for columns of type NUMBER. Internally though, the data is stored in variant records as text to avoid errors due to precision and scale. Also, the Size property may return values based on the storage needed by Oracle rather than the number of bytes needed to store the value. Developers accessing Oracle Objects for OLE using their own OLE Automation interface should rely on the type (and the size implied by that type) of the variant records, not of the Type or Size properties. This behavior DOES NOT affect users of Visual Basic, Excel, Access or the C++ class libraries provided .with Oracle Objects for OLE.

Bugs or problems fixed in Version 1.0.55.0

General

* Large amounts of data stored in LONG RAW is not retrieved correctly.

* Connection object CommitTrans always raises an OLE Automation error.

* DbExecuteSQL is supposed to return number of records affected, but doesn't.

* Field.Type always returns TEXT for NUMBER columns.

* AppendChunk on an empty table doesn't correctly set the BOF/EOF flags.

* Setup: Banner says "Supports Borland 4.0" - should say "Supports Borland 4.0/4.5".

* Errors when using CHAR columns with the NoBlankStrip/OracleMode options of CreateDynaset.

* Edit/Update a date field, corrupts the field value in the database.

* Collection object enumerators do not function properly.

* CHAR columns cannot be edited twice.

* Next() method doesn't return the actual number of elements fetched.

* Excel: CreateDynaset("..", oradyn_nocache) causes GPF in ORAIPSRV.DLL.

* AppendChunk generates an OLE Automation Error on the second call.

* Program Aborted message from ORAIPSRV.DLL when updating columns to NULL.

* Shared Sessions/Connections do not work across applications. This feature did not properly work and has been removed from the product.

* Assigning a date field to an empty string causes an OLE Automation error on Update.

* Add/Edit/Delete not canceling an open Add/Edit.

* CreateDynaset not reporting Oracle errors when doing MoveFirst.

* GPF with a NULL password.

* Column names containing extended ASCII chars must be in upper case.

* SELECT .. FOR UPDATE NOWAIT on locked rows doesn't return an Oracle error.

* Longraw data truncated on OField.GetValue call for > 64k record.

Oracle Data Control Specific

* Farpoint Combo Box: Cannot use the dropdown list.

* Sheridan Data Widgets: Combo Box: Current record doesn't change when typing in control.

* Not reporting the length of columns of type DATA_VT_MEMO correctly to bound controls.

* Farpoint Spread: Delete row is not working.

* Farpoint Spread: Insert not being committed.

* Sheridan Data Widgets Grid: Delete row is not working.

* Sheridan Data Widgets Grid : Can't insert.

* Sheridan Data Widgets Grid: Update adds garbage to end of data.

* Data Control property Enabled does not cause the control to repaint at run time.

* Sheridan Data Widget combo box 1.0D does not work with the ODC.

Oracle C++ Class Library Specific

* References to unused OLE libs in the CPP samples.

* SetValue succeeds when it should fail due to no edit pending state.

* IsBOF/IsEOF not working in C++ on empty dynaset.

* OBinder IsOpen method has not been implemented.

* OBinder.UnbindObj (NULL,TRUE) causes GPF.

* BindtoBinder call reports success when field name passed is NULL pointer.

* BindtoBinder call GPF's if the OBinder address is NULL.

* GetFieldValue doesn't work on dates.

* GetErrorText returns inconsistent types.

* GetErrorText can return NULL, but should never.

* Sample code to implement OBoundval fails to set values.

* OParameter object should support creation with an OValue.

* OBinder class is not complete and requires better error handling.

* Bound widget library does not link with Borland C++ 4.5. Due to a change in the implementation of OWL, the library (oowl.lib) originally supplied will not link when using the version 4.5 compiler. A new library (oowl45.lib) has been supplied. Please read the file oowl.wri for further information on how to use the bound widget library with Borland C++ 4.5.

* OValue GPFs in Borland C++ when dealing with NULL pointers.

* OField.SetValue((const char *) 0 ) causes GPF in Borland, not MSVC.

* OBinder.IsChanged() returns true following a Refresh.

* ODynaset.DuplicateRecord() does not duplicate correctly.

* ParameterCollection.remove should trap NULL pointer, but doesn't.

* AppendFieldChunk method should return error for NULL source.

* Class methods are not type-checking for LONG types, and should.

* OValue::SetValue; on receiving NULL , should still allocate memory.

* GetValue, GetFieldValue cause GPF when (void *) 0 passed as argument .

* OParameter.Add with NULL column id causes GPF.

* OSession::GetNamedSession fails to return default session using NULL argument.