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.