This file contains important information specific to this release of Oracle Objects for OLE version 2.3. The following topics are covered:
This release is a 32-bit version of Oracle Objects for OLE and will work on Windows NT, Windows 95 and Windows 98.
Class libraries are provided for Microsoft Visual C++ version 2.x and version 4.x, version 5.x.
What is included in this release:
32-bit In Process OLE Automation Server for Windows NT, Windows 95 and Windows 98.
32-bit Class Libraries for Microsoft MFC 2.x/4.x/5.x.
32-bit Oracle Data Control (.OCX) for Windows NT, Windows 95 and Windows 98.
Since Microsoft Visual C++ 2.x/4.x 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.
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):
\ORAHOME\MSHELP - Oracle Objects online documentation.
\ORAHOME\OO4O23 - SQL scripts and constants file.
\ORAHOME\OO4O23\CPP - Libraries, includes, DLLs, and source for the class library.
\ORAHOME\OO4O23\CPP\MFC - Libraries, includes and source for the MFC Bound Class Library.
\ORAHOME\OO4O23\EXCEL\SAMPLES - Excel Samples.
\ORAHOME\OO4O23\VB\SAMPLES - Visual Basic 4.0 Samples.
\ORAHOME\OO4O23\VB\SAMPLES\QT - Visual Basic 4.0 Quick Tour guide.
\ORAHOME\OO4O23\IIS\SAMPLES - IIS Samples.
If you cannot guarantee that your end user will have this version of Oracle Objects for OLE installed on their machine, you will need to redistribute certain files along with your application.
Please see the online help (TechnicalNotes-->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.
New features have been documented in the online help file. Care has been taken so that existing features of the previous version are supported.
The most important enhancements introduced in this release are 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 whould be added to the InProcServer32 key: ThreadingModel = "Both" (This is added by default in the NT environment).
* The in-process server files as well as the data control files (oip23.dll, oip23.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.
A new method GetChunkByteEx has been introduced to enable reading of Long/Long raw data withing ASP. For more information on syntax please refer to the online help.
Here is an asp sample below to demonstrate usage:
<%@ LANGUAGE = VBScript
%>
<%Response.ContentType =
"image/JPEG"%>
<%
Dim OraDatabase, Oradynaset
Dim Chunksize, BytesRead,
CurChunkEx
'This assumes a pool of
database connections have been created in the global.asa
Set OraDatabase = OraSession.getDatabaseFromPool(10)
'This assumes a table called "art_gallery" and displays
JPEG images stroed in the table
Set OraDynaset = OraDatabase.CreateDynaset("select art from
art_gallery where artist = 'Picasso'", 0)
BytesRead = 0
'Reading in 32K chunks
ChunkSize= 32768
Do
BytesRead =
OraDynaset.Fields("picture").GetChunkByteEx(CurChunkEx
,i * ChunkSize, ChunkSize)
if BytesRead > 0 then
Response.BinaryWrite CurChunkEx
end if
Loop Until BytesRead < ChunkSize
'Cleanup, remove all local refrences
Set OraDynaset = Nothing
Set Oradatabase = Nothing
%>
New samples have been added to demonstrate threadsafety features and using it withing the Internet Information Server environment.
The C++ sample can be found at \ORAHOME\OO4O23\CPP\WORKBOOK\MULTHRD and the IIS samples can be found at \ORAHOME\OO4O23\IIS\ directories.
ChunkSize for for LONG LONG RAW columns
The ChunkSize can 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 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 rownumber 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
ORADB_NOWAIT Option of OpenDatabase
This option may be of limited use with Dynasets based on heavily used tables. This option causes ORA-54 errors to occur with Row Locks as documented, but it will also do the same for other resource contentions. In certain cases too many ORA-54 errors may be raised to be manageable. You will want to test your application with a realistic database load to see if this affects you.
ORAPARM_INPUT, OUTPUT and BOTH IOTYPE with ADD and ADDTABLE Methods
Care should be taken to be sure that this value is 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 param. In that case you should make two parameters). The errors this can cause are rare, but if you see parameter related errors you should check this.
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.
Microsoft Visual Basic Standard Controls
Tested Versions: VB 4.0 and VB 5.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 requires use of code (see AppendChunk method example code in online help for more information)
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 (ie DBGRID.Scroll) method of the grid will not work.
The Refresh (ie 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, don’t 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
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, don't 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: 2.0b Build 0186
Sheridan Data Bound Combo control
Same issues as Dropdown control below.
Sheridan Data Bound Dropdown control
In order to use for lookup table (such as by setting DropDownHwnd property on Grid), set 'ListAutoValidate' property to FALSE otherwise the dropdown selection will not commit to the underlying field.
ListAutoPosition does not work. Typing a string in field will not cause the corresponding list item to get highlighted.
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 (ala 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 (ala 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 maintainece 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. Continuting 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.
Should have the same issues as Microsoft Data Bound Grid control as noted above.
Error: CoInitializeEx() not found in OLE32.DLL
You will receive an error similar to this one if you use the Class Libraries with NT 3.51 or 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 windows95.
Bound control libraries (OMFC4x.LIB) support under MSVC 4.2 or later.
Current release of OMFC40.LIB is supported only for MSVC 4.0 compiler. Since different version of MSVC 4.x compiler requires different OMFC4x.LIB libraries, this release provides the OMFC40.MAK under \{ORACLE_HOME}\oo4o23\cpp\mfc directory. With this, client can built their own OMFC libraries for their versions of compilers.
IIS 4.0
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)
Here 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 GetChunkByteEx to read Long/Long raw columns.
Issues involving VIPER environment
An application that is built with the Oracle Objects for OLE C++ class library or that uses the Oracle Data Control will not run if that application uses an Oracle In Process Server that is installed in VIPER.
GetChunkByte and AppendChunkByte methods will not work in Visual Basic if Oracle In Process Server is installed in VIPER.
The following differences in behavior (from version 1) have been noted:
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.
There is a known problem with the Oracle RDBMS version 7.3.2.0 affecting LONG column which is fixed in version 7.3.2.2 or later. 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. You should obtain an upgrade to your database. 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 7.3.2.2 and the rdbms bug# is 360985.
Bugs or problems fixed in Version 2.3 Production
General
*596025: NO DATA HITS WHEN USING ORADYNASET WITH PARAMETER
This release supports queries on fixed-length character fields
which may contain
only one character.
*628807: THE VB SAMPLE PROGRAM, DATACTRL DOES NOT CHECK FOR
EOF/BOF CONDITIONS
*642151: MEMORY LEAK WHEN QUERYING REGISTRY VALUES
The registry is being closed to take care of memory leaks.
*643194: IN VB, CALLING OPENDATABASE WITH ORADB_NONBLK
CAUSES OIP440
*661400: SYSTEM RUNS OUT OF VIRTUAL MEMORY WHEN USING ARRAY
PARAMETERS INCORRECTLY.
This release now initialises/frees memory even in the error cases.
*662614: CANNOT RETRIEVE LONG VALUES WHEN QUERYING A JOIN
This release permits users to retrieve the first 64 k bytes of long fields when the query is a join.
*653936: ORAANSI.DLL IS SHIPPED WITH NO VERSION INFORMATION
ORAANSI.DLL now has version information consistent with the
other DLLs shipped
in Objects for Ole.
*631028:(Japanese Specific)OIP 4121 ERROR WHEN FETCHING
RECORDS
USING FIND METHOD
Data Control
*557266: ORADC CONTROLS
CONNECTION LOST BY UNLOAD EVENT IN VB5
The ORADC datacontrol now supports cancel
of form-unload/
query-unload operations in Visual Basic.
*588231:USING FINDFIRST IN
A DYNASET CAUSES AN OIP4121 ERROR AT EOF
*603381: GPF WHEN EMBEDDING AN ORADC .OCX ON AN EXCEL FORM
This release makes it possible to embed the datacontrol inside of an excel form.
*609458: THE SAVE ARGUMENT TO VALIDATE METHOD DOES NOT REFLECT
TRUE DATA CHANGED STATE.
Developers can use the save argument passed to oradc_validate
for determining if the data has
changed.
*628164: ACCESS VIOLATION USING DBCOMBO WHERE DATASOURCE IS
ORADC
AND CONTAINS SPACES
This release supports queries on character fields which may contain blanks or spaces only.
*624443: EMPEDIT SAMPLE DOES NOT WORK ON NT 3.51 WITH VC++ 4.0
This release of the class library now works with NT 3.51, NT 4.0 and Windows 95 environments.
*595402 : Fix for Memory corruption when using FindFirst and scalar functions, like Upper in VB.
Oracle Data Control Specific