A68803-01
Library |
| Oracle8i
Enterprise Edition Release Notes
A68803-01 |
|
If this software/documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and the following legend is applicable:
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data and Computer Software (October 1988).
If this software/documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with "Restricted Rights," as defined in FAR 52.227-14, Rights in Data - General, including Alternate III (June 1987).
Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.
The information in this document is subject to change without notice. If you find any problems in the documentation, please report them to us in writing. Oracle Corporation does not warrant that this document is error free.
Oracle, CASE*Dictionary, Pro*COBOL, SQL*Connect, SQL*Forms, SQL*Loader, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation. CASE*Designer, CASE*Method, Net8, Oracle7, Oracle8, Oracle8i, Oracle Call Interface, Oracle Parallel Server, Oracle Recovery Manager, PL/SQL, Pro*C/C++, SQL*Module, Oracle Server Manager and Trusted Oracle are trademarks of Oracle Corporation.
All trade names referenced are the service mark, trademark, or registered
trademark of the respective manufacturer.
This file contains important information specific to Oracle Objects for OLE release 8.1.5.3.3. The following topics are covered:
Oracle Objects for OLE 8.1.5.3.3
Class libraries are provided for Microsoft Visual C++ versions 2.x, 4.x, 5.x, and 6.x. Refer to the "Oracle Class Libraries" section in this document for information on the C++ class libraries provided in this release.
What is included in this release:
Enhancements introduced in version 2.3 were connection pooling, thread safety (supporting "Both" COM Threading Models), and performance enhancements. Full documentation of these new features is provided in the online help.
Please note that to use oo4o in a free threaded environment in Windows
95 the following string value would be added to the InProcServer32 key:
ThreadingModel = "Both". This is added by default in the NT environment.
Following are the new samples in \ORACLE_HOME\OO4O\VB\SAMPLES directory:
Long/Long Raw Migration to BLOB, CLOB or BFILE Recommended
Oracle8i introduces the following new types -- BLOB, CLOB, and BFILE. The design of these types allow Oracle Objects for OLE to access them much faster than Long or Long Raw. For this reason you are urged to convert pre-existing Long Raw based applications to BLOB, CLOB and BFILE. New applications should use BLOB, CLOB and BFILEs rather than Long Raw.
Such migration should be relatively simple with little code changes required. This is because the methods previously used for Long and Long Raw manipulation have been enhanced to allow them to be used against BLOB, CLOB, and BFILE as well. These methods are AppendChunk, AppendChunkByte, GetChunk, GetChunkByte, GetChunkByteEx, and ReadChunk. The primary code changes will involve the requirement that NULL BLOB and CLOB be updated with "Empty" before being used. Note: For maximum flexibility, new applications should use the normal BLOB/CLOB/BFILE Read and Write methods instead of these Chunk methods.
Migrating to BLOB gives the added benefit of Data Control writes. Refer
to the "Oracle Data Control" section in this document.
From Visual Basic 6, you can load the oo4o Type Library by going to the menu and choosing Project-->References. The name of the library is OIP8.TLB. After doing this you can browse the oo4o objects by going to the menu and choosing View-->Object Browser. The Data Control can be added by going to the menu and choosing Project-->Components. The name of the data control is ORADC.OCX.
ASP users can try out the sample located in the ORACLE_HOME\oo4o\Iis\Samples\ASP\ConnPool
directory.
Please see the online help (Redistributable Files) for more information about which files are involved.
When not installed by the Oracle installer, the Oracle Data Control (ORADC.OCX) will have to be registered for it to function. The OCX may be registered by running regsvr32.exe oradc.ocx from a DOS prompt.
NCHAR and NVARCHAR2 datatypes are not supported in this release. The error "character set mismatch" is likely if operations are attempted on these types.
Type Library changes
An incompatibility with the type library was introduced in OO4O versions 2.3.x (up to and including 2.3.2) and OO4O 8.1.3.3.0. This has been corrected in the current release. Applications using early binding with OO4O versions 2.3.x (up to and including 2.3.2 and 8.1.3.3) need to be re-compiled.
LOB columns with Dynaset with ORADYN_ORAMODE
Adding LOB columns in a dynaset created with ORADYN_ORAMODE option does not work with this release.
Lob, Objects, REF, Collections Dirty Writes
With all other column types, when you attempt to do an update, and the value of the field has been changed by another user, you receive an OIP-4119 "Data Has been Changed" error. This error will not occur with BLOB and CLOB, Object ,REF and collection types and the data will be updated regardless.
Error with Visual Basic 6 -- Runtime Error '5': Invalid Procedure Call or Argument
Microsoft has changed the way that operators (<, >, =, &) evaluate objects in VB 6.0.
The following code will generate an error with Visual Basic 6.0 but will work with Visual Basic 5.0:
MsgBox "Ename:" & OraDynaset.Fields!ENAME
MsgBox "Ename:" & OraDynaset.Fields("ENAME")
If OraDynaset.Fields!EMPNO
= 7222 Then Msgbox "Hello World"
If OraDynaset.Fields("EMPNO")
= 7222 Then Msgbox "Hello World"
The workaround is to explicitly use the .Value property, and to avoid using the "!" (default property) operator.
This change in design seems to affect only the operators (<, >, =, &) when used in clauses. The Msgbox method, and operators not used in clauses are still able to figure out the correct value.
For example, the following still works in both VB5 and VB6:
MsgBox OraDynaset.Fields!ENAME
MsgBox OraDynaset.Fields("ENAME")
int_var = OraDynaset.Fields("EMPNO")
Msgbox "Empno:" & int_var
For more information on this design change please see the MS knowledge
base article:
Q194368: Operators Do Not Recursively Call Object Default Properties
This is available at http://support.microsoft.com/support/
ORADB_NOWAIT Option of OpenDatabase
The effect of this option differs significantly from it's behavior in version 2.3. It now only applies to OraDynaset. It no longer has any effect on OraSqlStmt objects or ExecuteSQL calls. Also, it now only gives an error in the case of a locked row (in 2.3 it gave an error when there was *any* database resource contention no matter how brief, which was generally disruptive)
ChunkSize for for LONG LONG RAW columns
The ChunkSize can be less than or equal to 65280 bytes and not 64K as mentioned in the online documentation. This is true for all the chunking methods GetChunk, GetChunkByte, GetChunkByte , GetChunkByteEx and ReadChunk.
Behavior of MoveTo, MoveRel, Movexxxxn
MoveTo:
The behavior of this method is correct but the documentation does not make clear how this method behaves: Row numbers are static between refreshes. They are very much like a row id. Row numbers are not dynamically reassigned after deletions. Therefore if you do a MoveFirst followed by a MoveTo 4, you will end up at the same row, whether or not rows 2 and 3 have been deleted. So, you should not do arithmetic based on values of row numbers unless you can guarantee no row has been deleted (such as immediately after a refresh). That is, you can not be sure how far apart row 1 and row 4 are in terms of valid (non-deleted) rows. The row number simply serves as a label or id and it's actual value is meaningless in terms of relative position whenever rows have been deleted.
MoveRel, Movexxxxn
These methods do not work correctly when rows have been deleted. They incorrectly add the offset you provide to the value of the row number and move there (or to the next available valid row in the case the resulting row has been deleted). Unless you can guarantee that no row has been deleted (such as immediately after a refresh) these methods should probably not be used. Instead, use a loop of MoveNext or MovePrev to achieve the same results.
Find Methods
ORAPARM_INPUT, OUTPUT and BOTH IOTYPE with ADD and ADDTABLE Methods
Care should be taken to be sure that this value is correct. For example,
with a stored procedure, ORAPARM_INPUT should be used only with IN parameters,
ORAPARM_OUT with OUT and ORAPARM_BOTH only with IN OUT. Setting an incorrect
option, such as ORAPARAM_BOTH for a stored procedure parameter type IN
can result in errors in certain circumstances. You should create a separate
parameter if it's usage will be different. In other words ORAPARAM_BOTH
means "for IN OUT parameters only". It does not mean that you should use
the parameter against one stored procedure that has an IN parameter and
then use it in another that has an OUT parameter. In that case you should
make two parameters. The errors this can cause are rare, but if you find
parameter related errors you should check this.
The Oracle Data Control now can be used against BLOB and BFILE columns. And when used against BLOB columns, it now allows the writing of data. One interesting way to take advantage of this is to bind the ORADC to the MS OLE Container Control and store the state of the OLE object in an Oracle BLOB column.
The MS OLE container always writes out the state of the object if a user activates it and then navigates to a new row. For backward compatibility, and because the developer may want to allow read only access, a BLOBReadOnly property has been added to the Data Control. When this property is set to true, any write requests from data aware controls to Oracle BLOB columns will be ignored and no error message will be generated.
It is not possible to write to BFILE or Long Raw columns using the Data Control. You might consider migrating your Long Raw columns over to BLOB columns for this reason as well as to gain the performance improvements that BLOBs offer (BLOBs and BFILEs and significantly faster than Long Raws with Oracle Objects for OLE).
It is not possible to read CLOB data using the Oracle Data Control.
Custom controls support
Oracle Data Control is a fully functional Visual Basic 5.0 Custom Control (OCX). It is compatible with any data-aware bound control (OCX) that uses the Microsoft VB data binding specifications.
The following data aware controls have been tested with the Oracle Data Control and here are some comments. Other controls not listed here will work with the Oracle Data Control as long as they follow the Microsoft VB data binding specifications.
Tested Versions: VB 4.0, 5.0 and 6.0
Edit control
Works fine with Oracle data control.
Static text control
Works fine with Oracle data control.
Picture box and Image control
The MS Picture box and MS Image Control work with the Oracle Data Control in both Visual Basic 4.0 and Visual Basic 5.0.
Long Raw data displayed through the Oracle Data Control is read only. To do adds or updates to Long Raw requires use of code. See the AppendChunk method example code in the online help for more information. We recommend you migrate the Long Raw over to BLOB column type which is writeable by the Data Control and can be significantly faster.
Microsoft OLE Container Control
Write operations which occur after activation of the OLE object do not work properly in VB 4.0. The object written to the database is corrupt. This works correctly in VB 5.0.
Microsoft Data Bound Listbox control
Does not respond to ORADC.UpdateRecord. Instead use MoveNext or MovePrevious to force the update.
Microsoft Data Bound Combobox control
Does not respond to ORADC.UpdateRecord. Instead use MoveNext or MovePrevious to force the update.
Microsoft Data Bound Grid control
Whenever the Data Control?s underlying Recordset is moved to EOF or BOF, the grid will not paint properly if the user attempts to use it while in that state. So, each time you are finished using ORADC1.Recordset in your code it is advisable to check for BOF and EOF, and if it true, do a MoveFirst followed by a MoveLast in the case of EOF or MoveLast followed by MoveFirst in the case of BOF. This will cause the rows to be repainted.
The Scroll (DBGRID.Scroll) method of the grid will not work.
The Refresh (DBGRID.Refresh) method of the grid will not work. Use ORADC.Recordset.Refresh instead.
Deleting a row using the delete key on the keyboard causes the current row to jump ahead 2 rows rather than one. Workaround is to use a button associated with the code ORADC.Recordset.Delete.
MSGRID bookmarks (DBGRID.Bookmark) and Oracle Objects bookmarks (ORADC.Recordset.Bookmark) are not compatible. Setting the ORADC.Recordset.Bookmark property to a bookmark obtained from DBGRID.Bookmark will result in an OIP-4121. Similarly, populating the grid?s SelBookmarks collection with bookmarks obtained from ORADC.Recordset.Bookmarks will result in some rows not properly selected.
To workaround the problem, do not share bookmarks between Oracle Objects and the MSGrid.
That is, only set DBGrid1.Bookmark property to a bookmark that you obtained from DBGrid1.Bookmark. Only set ORADC.Recordset.Bookmark to a bookmark that you obtained from ORADC.Recordset.Bookmark.
For example, use:
DBGrid1.Bookmark = DBGRID.SelBookmarks(0)
instead of
ORADC.Recordset.Bookmark = DBGRID.SelBookmarks(0)
MSGRID SelBookmarks property doesn't work with ORADC.Recordset.Bookmark
Setting the ORADC.Recordset.Bookmark property to a bookmark obtained from DBGRID.Bookmark will result in an OIP-4121. Similarly, populating the grid's SelBookmarks collection with bookmarks obtained from ORADC.Recordset.Bookmarks will result in some rows not properly selected.
To workaround the problem, do not share bookmarks between Oracle Objects and the MSGrid.
For example, use:
DBGrid1.Bookmark = DBGRID.SelBookmarks(0) instead of ORADC.Recordset.Bookmark = DBGRID.SelBookmarks(0)
Tested Version: 3.0 Build 34
Sheridan Data Bound Combo control
Updates database with NULL for any update. Use MS Combo box until this is resolved.
Sheridan Data Bound Dropdown control
No known issues.
Sheridan Data Bound Grid control
Whenever the Data Control?s underlying Recordset is moved to EOF or BOF, the grid will not paint properly if the user attempts to use it while in that state. So, each time you are finished using ORADC1.Recordset in your code it is advisable to check for EOF or BOF, and if it is true, do a MoveLast in the case of EOF, and do a MoveLast followed by a MoveFirst in the case of BOF.
Doing a delete when no rows are visible on grid (this can happen when you delete every row that is visible on the grid when there are more rows than one page worth), followed by doing a delete on the empty looking grid will cause repainting problems. This should only be an issue if you have a loop of ORADC.Recordset.Delete since the user will not normally delete a row when one is not visible. One possible workaround is to add a MovePrevious followed by a MoveNext to each delete in the loop. This will cause Sheridan to keep at least one row visible on the grid throughout the deletes and will avoid the problem. Another workaround is to refresh after doing the deletes.
Performing AddNew on underlying dynaset (ORADC.Recordset.AddNew) when dynaset has not been fully fetched yet will result in OIP-4118 error. Workaround is do a MoveLast to force a full fetch, then call AddNew.
Related to the above problem, there may be other cases where Sheridan does not move to the last row when it is supposed to when all the rows have not yet been fetched. For example, this may occur when you call MoveLast on the grid itself (Grid.MoveLast) prior to all rows being fetched. To workaround any problem like that, call MoveLast on the underlying dynaset instead
(ORADC.Recordset.MoveLast).
Related to above problem, MoveRecords method of grid will move to the last row of all rows fetched so far if not all rows have been fetched yet.
The Refresh method of the grid (SSDBGRID1.Refresh) will do nothing. Use ORADC.Recordset.Refresh instead.
Sheridan Enhanced Data Control
Works fine with Oracle Data Control except for Find functionality which only works for "equals" case and only when no rows have been deleted.
FarPoint Data Bound Grid Control
Tested Version: 2.5.020
Access Violations will occur when bound to Long Raw when size of long raw minus 118 bytes is multiple of 32k. Farpoint has confirmed this bug and it should be fixed in a maintenance release of Spread. Please contact Farpoint for more information about how to obtain a fix.
After deleting the last row in the grid, Farpoint will not reposition
on the new last row. Continuing to delete will succeed in deleting the
new last row, but the deleted rows will not disappear from the grid. To
workaround this add a MovePrevious and MoveNext to each delete in your
code or call refresh when done deleting.
The class library provided with this release is equivalent to one provided in version 2.3. None of the new functionality has been exposed yet. This will become available in a future release. Users wishing to use the new functionality of oo4o from C++ immediately can use the #import facility of Visual C++ which creates wrapper objects for the interfaces in OIP8.TLB. Care must be taken using this approach that all object references are released or else object and connection leaks may result.
Error: CoInitializeEx() not found in OLE32.DLL
You will receive an error similar to this one if you use the Class Libraries with an older version of Win95, and you call OStartup() with the MultiThreading option. To correct this you need to obtain NT 4.0, or the DCOM patch for Windows 95.
Bound control libraries (OMFC4x.LIB) support under MSVC 4.2 or later.
The current release of OMFC40.LIB is supported only for the MSVC 4.0 compiler. Because different versions of the MSVC 4.x compiler require different OMFC4x.LIB libraries, this release provides the OMFC40.MAK in the \{ORACLE_HOME}\oo4o\cpp\mfc directory. With this, client can built their own OMFC libraries for their versions of compilers.
Using the data control with VC++
An error condition will cause an exception in MFC42.DLL. For example while running a VC++ application with the data control an invalid data input which should otherwise generate an OIP error will cause an unhandled exception in MFC42.DLL.
In the IIS 4.0 you need to use the <OBJECT> tag for instantiating OO4O.
<OBJECT RUNAT=Server SCOPE=Application ID=OraSession PROGID="OracleInProcServer.XOraSession"></OBJECT>
You can then access the OraSession object by simply referring to it without using the Application("OraSession") syntax. The SCOPE=Application takes care of it.
The following is a sample global.asa file.
<OBJECT RUNAT=Server SCOPE=Application
ID=OraSession PROGID="OracleInProcServer.XOraSession"></OBJECT>
<SCRIPT LANGUAGE=VBScript
RUNAT=Server>
Sub Application_OnStart
End Sub
Sub Application_OnEnd
End Sub
</SCRIPT>
Reading Long/Long raw columns in ASP
You have to use OraField object's method GetChunkByteEx to read Long/Long
raw columns from ASP. See the online help for more information. Oracle
recommends that you use LOBs instead.
|
Copyright © 1999 Oracle Corporation. All Rights Reserved. |
|