32 bit Patch 19.15.0.0.220419 is now available.
No fix.
We (and our clients) are still forced to use the 18.3 client, even though the server version is 19 or 21.
Search found 78 matches
- Thu 19 May 2022 11:10
- Forum: Oracle Data Access Components
- Topic: Memory not released after closing TSmartQuery with LOBs
- Replies: 16
- Views: 65863
- Tue 23 Nov 2021 15:59
- Forum: Oracle Data Access Components
- Topic: Memory not released after closing TSmartQuery with LOBs
- Replies: 16
- Views: 65863
Re: Memory not released after closing TSmartQuery with LOBs
19.13.0.0.211019 oci.dll (1397248 bytes, 22.10.2021 00:45) still broken.
OCI-21500: internal error code, arguments: [kgepop: no error frame to pop to], [], [], [], [], [], [], []
OCI-21503: program terminated by fatal error
OCI-04030: out of process memory when trying to allocate 16336 bytes (koh-kghu sessi,alloc lob locator)
OCI-21500: internal error code, arguments: [kgepop: no error frame to pop to], [], [], [], [], [], [], []
OCI-21503: program terminated by fatal error
OCI-04030: out of process memory when trying to allocate 16336 bytes (koh-kghu sessi,alloc lob locator)
- Tue 09 Nov 2021 13:46
- Forum: Oracle Data Access Components
- Topic: Memory not released after closing TSmartQuery with LOBs
- Replies: 16
- Views: 65863
Re: Memory not released after closing TSmartQuery with LOBs
Patches are also for client available/applicable, like p32832237_190000_WINNT.zip for 32 bit Windows.
Replaces oci.dll and other files.
Server version doesn't matter. Got OCI-21500 [kgepop: no error frame to pop to] also with 19.12 Client and 11.2 server,
19.13.0.0.211019 for Windows should arrive soon. I'll test.
Devart should fix this with Oracle together.
Replaces oci.dll and other files.
Server version doesn't matter. Got OCI-21500 [kgepop: no error frame to pop to] also with 19.12 Client and 11.2 server,
19.13.0.0.211019 for Windows should arrive soon. I'll test.
Devart should fix this with Oracle together.
- Mon 30 Aug 2021 09:55
- Forum: Oracle Data Access Components
- Topic: Memory not released after closing TSmartQuery with LOBs
- Replies: 16
- Views: 65863
Re: Memory not released after closing TSmartQuery with LOBs
Still having this issue with 19.12.0.0.210720 patch.
Any news from Oracle?
Any news from Oracle?
- Thu 10 Jun 2021 12:09
- Forum: Oracle Data Access Components
- Topic: Error OCI-04030 (out of process memory) with Oracle Client 19.x (32 bit) when loading many rows from a table with LOBs
- Replies: 6
- Views: 6753
Re: Error OCI-04030 (out of process memory) with Oracle Client 19.x (32 bit) when loading many rows from a table with LO
Same or related:
viewtopic.php?f=5&t=40657 from 05/2020
We are still using client 18.3 with 19.x servers.
viewtopic.php?f=5&t=40657 from 05/2020
We are still using client 18.3 with 19.x servers.
- Fri 14 May 2021 09:23
- Forum: Oracle Data Access Components
- Topic: GUI program exits silently (32 bit, low RAM, LOB)
- Replies: 3
- Views: 3887
Re: GUI program exits silently (low RAM, LOB)
Oracle 19.11 ODAC 11.4.2 still same behavior
Code: Select all
ODAC: 11.4.2
Mem: 4.972.544
Mem: 1.917.714.432
Client: 19.11.0.0.0
Server: 19.0.0.0.0
Start 1
Open OK 1
Last OK 1 999 records
Mem: 1.975.554.048
Mem: 1.975.586.816
Start 2
Open OK 2
Errors in file :
OCI-21503: Programm durch schwerwiegenden Fehler beendet
OCI-04030: Zu wenig Prozessspeicher für Versuch 16336 Byte zuzuweisen (koh-kghu sessi,alloc lob locator)
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
02A43917 CALLrel 02BF677A 18D3D0 1 2A43570 2A439D0
2A43570 2A439D0
042978A0 CALLreg 00000000 397E20 3
042FF5FC CALLrel 04297510 397E20 3A1A98 0 1 51C4294
51C43A4
04312B5B CALLrel 042FE220 397E20 74A313E8 3FD0 0
74A31414 0
04353269 CALLrel 04311F50 397E20 74A313E8 3FC4 0 0
2C558A0
04587720 CALLrel 04352F50 397E20 74A313D8 FA4 1 2C558A0
3D8654
04587100 CALLrel 045875C0 397E20 FA0 A 1 2C558A0 0 0
04582455 CALLrel 04586AF0 397E20 FA0 A 1 2C558A0 0 0
0283D0B5 CALLrel 02BF6E10 397708 FA0 A 2C558A0 0 40
0283376A CALLrel 0283A510 397708 18FC20 32 1 0 0 0 0
_OCIDescriptorAlloc CALLptr 00000000 397708 18FC20 32 0 0
()+43
0073B4A0 CALLreg 00000000 397708 18FC20 32 0 0
007335C2 CALLreg 00000000 0 70B5AC 0 19 77AE79A6
77AE5C8C
00737B8B CALL??? 00000000 782E3D 20DA838 18FCF8 71A91D
79B9FFC0 0
0073831E CALL??? 00000000 18FE58 738AF2 18FE40 18FF48 0
782E3D
007364AC CALLrel 00737F3C 112F0 20112F0 18FE84 65591B
18FE64 655928
0065591B CALL??? 00000000 18FE64 655928 18FE84 18FE8C
65596C 18FE84
00739DE0 CALL??? 00000000 18FE98 739E25 18FEB8 18FEC0
739E36 18FEB8
0073A097 CALLrel 00739CBC 18FEDC 73A0B2 18FED4 0
20112F0 18FEEC
0073A36D CALL??? 00000000 18FF00 73A39B 18FEEC 20112F0
18FEF8 5E0310
005E0310 CALL??? 00000000 208D330
00523A97 CALL??? 00000000 18FF1C 523ADF 18FF14 782E3D
208D330 18FF4C
0077797C CALLrel 00523A50 18FF28 7779DF 18FF4C 18FF54
777AAE 18FF4C
00782F15 CALLrel 007778D8 18FF70 782F49 18FF80 782D9C
782D9C 7FFDE000
76E56A12 CALLreg 00000000 7FFDE000 76E569F0 8264BCFC
18FFDC 772CAB2F 7FFDE000
772CAB2D CALLreg 00000000 7FFDE000 83A7FBC8 0 0
7FFDE000 7FF9
772CAAF5 CALLrel 772CAB00 FFFFFFFF 772AFE31 0 0 782D9C
7FFDE000
00000000 CALL??? 00000000
Call stack signature: 0xe5b8866a9ee1f71f
call stack performance statistics:
total : 0.110000 sec
setup : 0.063000 sec
stack unwind : 0.000000 sec
symbol translation : 0.031000 sec
printing the call stack: 0.016000 sec
printing frame data : 0.000000 sec
printing argument data : 0.000000 sec
printing kernel stack : 0.000000 sec
----- End of Call Stack Trace -----
Errors in file :
OCI-21500: Interner Fehlercode, Argumente: [kgepop: no error frame to pop to], [], [], [], [], [], [], []
OCI-21503: Programm durch schwerwiegenden Fehler beendet
OCI-04030: Zu wenig Prozessspeicher für Versuch 16336 Byte zuzuweisen (koh-kghu sessi,alloc lob locator)
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
02A43917 CALLrel 02BF677A 18EA64 1 2A43570 2A439D0
2A43570 2A439D0
0429D5D7 CALLreg 00000000 397E20 3 208D330 0 4C0043
42004F
0429CB24 CALLrel 0429CF80 397E20 3A1A98 53FF
050165FE CALLrel 0429CA90 397E20 520624C 5206240
04582455 CALLrel 04586AF0 397E20 FA0 A 1 2C558A0 0 0
0283D0B5 CALLrel 02BF6E10 397708 FA0 A 2C558A0 0 40
0283376A CALLrel 0283A510 397708 18FC20 32 1 0 0 0 0
_OCIDescriptorAlloc CALLptr 00000000 397708 18FC20 32 0 0
()+43
0073B4A0 CALLreg 00000000 397708 18FC20 32 0 0
007335C2 CALLreg 00000000 0 70B5AC 0 19 77AE79A6
77AE5C8C
00737B8B CALL??? 00000000 782E3D 20DA838 18FCF8 71A91D
79B9FFC0 0
0073831E CALL??? 00000000 18FE58 738AF2 18FE40 18FF48 0
782E3D
007364AC CALLrel 00737F3C 112F0 20112F0 18FE84 65591B
18FE64 655928
0065591B CALL??? 00000000 18FE64 655928 18FE84 18FE8C
65596C 18FE84
00739DE0 CALL??? 00000000 18FE98 739E25 18FEB8 18FEC0
739E36 18FEB8
0073A097 CALLrel 00739CBC 18FEDC 73A0B2 18FED4 0
20112F0 18FEEC
0073A36D CALL??? 00000000 18FF00 73A39B 18FEEC 20112F0
18FEF8 5E0310
005E0310 CALL??? 00000000 208D330
00523A97 CALL??? 00000000 18FF1C 523ADF 18FF14 782E3D
208D330 18FF4C
0077797C CALLrel 00523A50 18FF28 7779DF 18FF4C 18FF54
777AAE 18FF4C
00782F15 CALLrel 007778D8 18FF70 782F49 18FF80 782D9C
782D9C 7FFDE000
76E56A12 CALLreg 00000000 7FFDE000 76E569F0 8264BCFC
18FFDC 772CAB2F 7FFDE000
772CAB2D CALLreg 00000000 7FFDE000 83A7FBC8 0 0
7FFDE000 7FF9
772CAAF5 CALLrel 772CAB00 FFFFFFFF 772AFE31 0 0 782D9C
7FFDE000
00000000 CALL??? 00000000
Call stack signature: 0xe5b8866a9ee1f71f
call stack performance statistics:
total : 0.469000 sec
setup : 0.078000 sec
stack unwind : 0.000000 sec
symbol translation : 0.032000 sec
printing the call stack: 0.343000 sec
printing frame data : 0.000000 sec
printing argument data : 0.000000 sec
printing kernel stack : 0.000000 sec
----- End of Call Stack Trace -----
Errors in file :
OCI-21500: Interner Fehlercode, Argumente: [kgepop: no error frame to pop to], [], [], [], [], [], [], []
OCI-21503: Programm durch schwerwiegenden Fehler beendet
OCI-04030: Zu wenig Prozessspeicher für Versuch 16336 Byte zuzuweisen (koh-kghu sessi,alloc lob locator)
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
02A43917 CALLrel 02BF677A 18EA64 1 2A43570 2A439D0
2A43570 2A439D0
0429D617 CALLreg 00000000 397E20 3 208D330 0 4C0043
42004F
0429CB24 CALLrel 0429CF80 397E20 3A1A98 53FF
050165FE CALLrel 0429CA90 397E20 520624C 5206240
04582455 CALLrel 04586AF0 397E20 FA0 A 1 2C558A0 0 0
0283D0B5 CALLrel 02BF6E10 397708 FA0 A 2C558A0 0 40
0283376A CALLrel 0283A510 397708 18FC20 32 1 0 0 0 0
_OCIDescriptorAlloc CALLptr 00000000 397708 18FC20 32 0 0
()+43
0073B4A0 CALLreg 00000000 397708 18FC20 32 0 0
007335C2 CALLreg 00000000 0 70B5AC 0 19 77AE79A6
77AE5C8C
00737B8B CALL??? 00000000 782E3D 20DA838 18FCF8 71A91D
79B9FFC0 0
0073831E CALL??? 00000000 18FE58 738AF2 18FE40 18FF48 0
782E3D
007364AC CALLrel 00737F3C 112F0 20112F0 18FE84 65591B
18FE64 655928
0065591B CALL??? 00000000 18FE64 655928 18FE84 18FE8C
65596C 18FE84
00739DE0 CALL??? 00000000 18FE98 739E25 18FEB8 18FEC0
739E36 18FEB8
0073A097 CALLrel 00739CBC 18FEDC 73A0B2 18FED4 0
20112F0 18FEEC
0073A36D CALL??? 00000000 18FF00 73A39B 18FEEC 20112F0
18FEF8 5E0310
005E0310 CALL??? 00000000 208D330
00523A97 CALL??? 00000000 18FF1C 523ADF 18FF14 782E3D
208D330 18FF4C
0077797C CALLrel 00523A50 18FF28 7779DF 18FF4C 18FF54
777AAE 18FF4C
00782F15 CALLrel 007778D8 18FF70 782F49 18FF80 782D9C
782D9C 7FFDE000
76E56A12 CALLreg 00000000 7FFDE000 76E569F0 8264BCFC
18FFDC 772CAB2F 7FFDE000
772CAB2D CALLreg 00000000 7FFDE000 83A7FBC8 0 0
7FFDE000 7FF9
772CAAF5 CALLrel 772CAB00 FFFFFFFF 772AFE31 0 0 782D9C
7FFDE000
00000000 CALL??? 00000000
Call stack signature: 0xe5b8866a9ee1f71f
call stack performance statistics:
total : 0.531000 sec
setup : 0.109000 sec
stack unwind : 0.000000 sec
symbol translation : 0.031000 sec
printing the call stack: 0.360000 sec
printing frame data : 0.000000 sec
printing argument data : 0.000000 sec
printing kernel stack : 0.000000 sec
----- End of Call Stack Trace -----
- Mon 18 May 2020 18:25
- Forum: Oracle Data Access Components
- Topic: GUI program exits silently (32 bit, low RAM, LOB)
- Replies: 3
- Views: 3887
GUI program exits silently (32 bit, low RAM, LOB)
Fetching many rows with lobs does sometimes not show an EOutOfMemory exception.
The program vanishes silently.
Very good reproducable with 19.6 oracle client, server version does not matter.
Tested with ODAC 10.3.9 and 11.1.3
Running form Delphi throws (internally) exception class $C0000005 'access violation at 0x72a0c823: read of address 0xfffffffb' from OraClasses.pas
From the user's point of view, it is very annoying if the program disappears without a message.
Although fetching gigabytes of data is not very smart.
Running the console (see sample code) prints stack trace from oracle client.
Sample code
The program vanishes silently.
Very good reproducable with 19.6 oracle client, server version does not matter.
Tested with ODAC 10.3.9 and 11.1.3
Running form Delphi throws (internally) exception class $C0000005 'access violation at 0x72a0c823: read of address 0xfffffffb' from OraClasses.pas
Code: Select all
Check(OCI8.OCIDescriptorAlloc(OCISvcCtx.hOCIEnv, LOBLocator, OCI_DTYPE_LOB, 0, nil));
From the user's point of view, it is very annoying if the program disappears without a message.
Although fetching gigabytes of data is not very smart.
Running the console (see sample code) prints stack trace from oracle client.
Code: Select all
ODAC: 11.1.3
Mem: 7.208.960
Mem: 1.819.230.208
Client: 19.6.0.0.0
Server: 12.2.0.1.0
Start 1
Open OK 1
Last OK 1 999 records
Mem: 1.874.677.760
Mem: 1.874.714.624
Start 2
Open OK 2
Errors in file :
OCI-21500: Interner Fehlercode, Argumente: [kgepop: no error frame to pop to], [], [], [], [], [], [], []
OCI-21503: Programm durch schwerwiegenden Fehler beendet
OCI-04030: Zu wenig Prozessspeicher für Versuch 16336 Byte zuzuweisen (koh-kghu sessi,alloc lob locator)
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
02D488C7 CALLrel 02ED2448 18D3D4 1 2D48520 2D48980
2D48520 2D48980
71F80150 CALLreg 00000000 301C200 3
71FE61D8 CALLrel 71F7FDC0 301C200 3025E68 0 1 72E8B110
72E8B214
71FF998D CALLrel 71FE4EE0 301C200 3063CC0 3FD0 0
3063CEC 0
72039E89 CALLrel 71FF8D70 301C200 3063CC0 3FC4 0 0
2F241A0
72262E50 CALLrel 72039B70 301C200 3063CB0 FA4 1 2F241A0
305CA18
72262830 CALLrel 72262CF0 301C200 FA0 A 1 2F241A0 0 0
7225DBE5 CALLrel 72262220 301C200 FA0 A 1 2F241A0 0 0
02B3FDD5 CALLrel 02ED2AD8 301BAF0 FA0 A 2F241A0 0 40
02B374AA CALLrel 02B3D230 301BAF0 18FC20 32 1 0 0 0 0
_OCIDescriptorAlloc CALLptr 00000000 301BAF0 18FC20 32 0 0
()+43
...
Sample code
Code: Select all
{$APPTYPE CONSOLE}
program odactest19ram;
uses
SysUtils, Windows, PsAPI, Ora;
procedure WriteMemUsage;
var
MemCnt: PROCESS_MEMORY_COUNTERS;
begin
if GetProcessMemoryInfo(GetCurrentProcess, @MemCnt, SizeOf(MemCnt)) then
Writeln(Format('Mem: %.0n', [MemCnt.WorkingSetSize / 1]));
end;
var
Session: TOraSession;
Query: TOraQuery;
I: Integer;
P: Pointer;
procedure DoTest(ASql: string);
begin
Inc(I);
Writeln('Start ', I);
Query.SQL.Text := ASql;
Query.Open;
Writeln('Open OK ', I);
try
Query.Last;
Writeln('Last OK ', I, ' ', Query.RecordCount, ' records');
WriteMemUsage;
except
on E: Exception do
begin
Writeln('Last not OK ', I, ' ', Query.RecordCount, ' records');
Writeln(E.ClassName, ' ', E.Message);
WriteMemUsage;
end;
end;
Query.Close;
WriteMemUsage;
end;
begin
Writeln('ODAC: ', ODACVersion);
I := 96 * 1024 * 1024; // 96 MB - try different values - YMMV
WriteMemUsage;
while True do // waste some RAM - if no big table is available
begin
try
GetMem(P, I);
FillChar(P^, I, $FF);
except
Break;
end;
end;
WriteMemUsage;
I := 0;
Session := TOraSession.Create(nil);
Query := TOraQuery.Create(nil);
Query.Session := Session;
Session.ConnectString := 'system/manager@server';
Session.Connect;
Writeln('Client: ', Session.Home.OCIVersionSt);
Writeln('Server: ', Session.OracleVersion);
DoTest('SELECT O.*, TO_CLOB(OBJECT_NAME) AS CLOB FROM ALL_OBJECTS O WHERE ROWNUM < 1000');
DoTest('SELECT O.*, TO_CLOB(OBJECT_NAME) AS CLOB FROM ALL_OBJECTS O');
Writeln('End');
end.
- Thu 09 Apr 2020 15:43
- Forum: Oracle Data Access Components
- Topic: strange behavior of TOraScript
- Replies: 3
- Views: 4520
Re: strange behavior of TOraScript
Workaround:
Remove "DROP JAVA SOURCE" lines from script.
Send each "DROP JAVA SOURCE" as single line script without the ending semicolon.
With semicolon ORA-00933 is raised again.
Remove "DROP JAVA SOURCE" lines from script.
Send each "DROP JAVA SOURCE" as single line script without the ending semicolon.
With semicolon ORA-00933 is raised again.
- Wed 08 Apr 2020 19:41
- Forum: Oracle Data Access Components
- Topic: strange behavior of TOraScript
- Replies: 3
- Views: 4520
strange behavior of TOraScript
Sample code:
Output:
If "DROP JAVA SOURCE" is in line, every following line will included in active SQL.
Obviously Oracle answers with ORA-00933
Code: Select all
{$APPTYPE CONSOLE}
program a;
uses
SysUtils, Ora, OraScript, OraError, DAScript;
type
TEventDummy = class(TObject)
procedure ScriptError(Sender: TObject; E: Exception; SQL: string; var Action: TErrorAction);
procedure ScriptBeforeExecute(Sender: TObject; var SQL: string; var Omit: Boolean);
end;
{ TEventDummy }
procedure TEventDummy.ScriptBeforeExecute(Sender: TObject; var SQL: string; var Omit: Boolean);
begin
Writeln('------------------');
Writeln('BEFORE-EXEC: ' + SQL);
Writeln('------------------');
end;
procedure TEventDummy.ScriptError(Sender: TObject; E: Exception; SQL: string; var Action: TErrorAction);
begin
Writeln('------------------');
Writeln('ERROR: ' + E.Message);
Writeln('SQL: ' + SQL);
Writeln('------------------');
Action := eaContinue;
end;
var
Session: TOraSession;
Script: TOraScript;
Event: TEventDummy;
begin
Writeln(ODACVersion);
Session := TOraSession.Create(nil);
Script := TOraScript.Create(nil);
Event := TEventDummy.Create;
Script.Session := Session;
Script.OnError := Event.ScriptError;
Script.BeforeExecute := Event.ScriptBeforeExecute;
Session.ConnectString := 'any/valid@login';
Script.SQL.Add('DROP TABLE FOO;');
Script.SQL.Add('DROP TABLE BAR;');
Script.SQL.Add('DROP JAVA SOURCE BAZ;');
Script.SQL.Add('DROP TABLE FOOBAR;');
Script.SQL.Add('DROP TABLE BARFOO;');
Script.SQL.Add('-- add any number of lines here');
Script.SQL.Add('-- all lines captured in last exec!');
Script.SQL.Add('DROP TABLE BAZBAZ;');
Script.Execute;
end.
Code: Select all
11.1.3
------------------
BEFORE-EXEC: DROP TABLE FOO
------------------
------------------
ERROR: ORA-00942: table or view does not exist (as expected)
SQL: DROP TABLE FOO
------------------
------------------
BEFORE-EXEC: DROP TABLE BAR
------------------
------------------
ERROR: ORA-00942: table or view does not exist (as expected)
SQL: DROP TABLE BAR
------------------
------------------
BEFORE-EXEC: DROP JAVA SOURCE BAZ;
DROP TABLE FOOBAR;
DROP TABLE BARFOO;
-- add any number of lines here
-- all lines captured in last exec!
DROP TABLE BAZBAZ;
------------------
------------------
ERROR: ORA-00933: SQL command not properly ended ([b][u]not[/u][/b] expected)
SQL: DROP JAVA SOURCE BAZ;
DROP TABLE FOOBAR;
DROP TABLE BARFOO;
-- add any number of lines here
-- all lines captured in last exec!
DROP TABLE BAZBAZ;
------------------
Obviously Oracle answers with ORA-00933
- Mon 18 Jan 2016 10:56
- Forum: Oracle Data Access Components
- Topic: Setting the Client Info for the TOraAlerter extra session
- Replies: 5
- Views: 2417
Re: Setting the Client Info for the TOraAlerter extra session
Code: Select all
program AlerterTest;
{$APPTYPE CONSOLE}
{$R *.res}
uses
System.SysUtils, Ora, OraAlerter;
var
S: TOraSession;
A: TOraAlerter;
Q: TOraQuery;
begin
S := TOraSession.Create(nil);
S.ConnectString := 'system/manager@orcl';
S.Connect;
S.ExecSQL('BEGIN DBMS_APPLICATION_INFO.SET_CLIENT_INFO(''Main-Session''); END;');
A := TOraAlerter.Create(nil);
A.Session := S;
A.EventType := etAlert;
A.Events := 'dummy';
A.Interval := 5;
A.TimeOut := -1;
A.Active := True;
Q := TOraQuery.Create(nil);
Q.SQL.Text := 'SELECT SID,LOGON_TIME,PROGRAM,CLIENT_INFO' +
'FROM V$SESSION WHERE UPPER(PROGRAM) = UPPER(:P)';
Q.ParamByName('P').AsString := ExtractFileName(ParamStr(0));
Q.Open;
Writeln('SID':4,'LOGON_TIME':20,'PROGRAM':20,' CLIENT_INFO');
while not Q.EOF do
begin
Writeln(Q.Fields[0].AsString:4, Q.Fields[1].AsString:20,
Q.Fields[2].AsString:20, ' ', Q.Fields[3].AsString);
Q.Next;
end;
Readln;
end.
SID LOGON_TIME PROGRAM CLIENT_INFO
189 18.01.2016 11:53:13 AlerterTest.exe
269 18.01.2016 11:53:13 AlerterTest.exe Main-Session
- Wed 13 Jan 2016 15:26
- Forum: Oracle Data Access Components
- Topic: Setting the Client Info for the TOraAlerter extra session
- Replies: 5
- Views: 2417
Re: Setting the Client Info for the TOraAlerter extra session
property Session does not help.
Access to FListenConnection via class helper is possible but calling FListenConnection.ExecCommand after start of FListenThread hangs application.
Need to set CLIENT_INFO for FListenConnection in "procedure TOCIAlerter.Start" (OraClasses.pas) after "FListenConnection.Connect('');".TOraAlerter Members
Session
Specifies the session for TOraAlerter to create an internal TOraSession object based on this session settings.
Access to FListenConnection via class helper is possible but calling FListenConnection.ExecCommand after start of FListenThread hangs application.
- Wed 02 Sep 2015 10:16
- Forum: Oracle Data Access Components
- Topic: dbMonitor GetObjectID (names in Object Tree)
- Replies: 1
- Views: 1545
dbMonitor GetObjectID (names in Object Tree)
When an object (e.g. query) pointer is reused then the statements of the new object are listed under the old object item.
The test case for this is the following:
Steps:
- create a new console application in Delphi and paste the code
- adjust the constants cServer, cUserName and cPassword
- start dbMonitor
- compile and run the example
- check output
expected: output is PASS
actual: output is
[1] <8-digit hex value>
[2] <8-digit hex value>
[3] <8-digit hex value>
[4] <8-digit hex value>
FAIL
- check dbMonitor Object Tree
expected:
- it has beside the session the four items qrTest1, qrTest2, qrTest3 and qrTest4
- each qrTest<Number> has one "SELECT <Value> FROM DUAL" statement
actual:
- it has beside the session only qrTest1
- qrTest1 has four "SELECT <Value> FROM DUAL" statements
In order to fix this issue I've changed DASQLMonitor.GetObjectID to take the component name into account by building a string of the hex value of the pointer and the component name. It looks like this:
This version works for Delphi 2009 and newer for Win32 and Win64. (requires Generics.Defaults)
Consider adding this (IFDEFed if required) or something similar to your code to fix the issue. Furthermore check GetObjectName for Win64, because IntToHex uses a fixed length of eight and not a compile time evaluated value of SizeOf(Pointer) * 2.
The test case for this is the following:
Code: Select all
program ODACDBMonitorTest;
{$APPTYPE CONSOLE}
uses
SysUtils,
Ora,
DASQLMonitor,
ORASQLMonitor;
const
cServer = 'YourServer';
cUsername = 'YourUser';
cPassword = 'YourPassword';
var
ObjectIDs: array [1..4] of Integer;
procedure Test1;
var
qr: TOraQuery;
begin
qr := TOraQuery.Create(nil);
try
qr.Name := 'qrTest1';
qr.SQL.Add('SELECT 1 FROM DUAL');
qr.Open;
ObjectIDs[1] := GetObjectID(qr);
finally
qr.Free;
end;
end;
procedure Test2;
var
qr: TOraQuery;
begin
qr := TOraQuery.Create(nil);
try
qr.Name := 'qrTest2';
qr.SQL.Add('SELECT 2 FROM DUAL');
qr.Open;
ObjectIDs[2] := GetObjectID(qr);
finally
qr.Free;
end;
end;
procedure Test3Rename;
var
qr: TOraQuery;
begin
qr := TOraQuery.Create(nil);
try
qr.Name := 'qrTest3';
qr.SQL.Add('SELECT 3 FROM DUAL');
qr.Open;
qr.Close;
ObjectIDs[3] := GetObjectID(qr);
qr.Name := 'qrTest4';
qr.SQL.Clear;
qr.SQL.Add('SELECT 4 FROM DUAL');
qr.Open;
ObjectIDs[4] := GetObjectID(qr);
finally
qr.Free;
end;
end;
function TestEditCLOBWithroBeforeEdit: Boolean;
var
I: Integer;
se: TOraSession;
mo: TOraSQLMonitor;
begin
se := TOraSession.Create(nil);
mo := TOraSQLMonitor.Create(nil);
try
se.Server := cServer;
se.Username := cUserName;
se.Password := cPassword;
se.Connect;
Test1;
Test2;
Test3Rename;
finally
mo.Free;
se.Free;
end;
Result := (ObjectIDs[1] <> ObjectIDs[2]) and (ObjectIDs[1] <> ObjectIDs[3]) and (ObjectIDs[1] <> ObjectIDs[4]) and
(ObjectIDs[2] <> ObjectIDs[3]) and (ObjectIDs[2] <> ObjectIDs[4]) and (ObjectIDs[3] <> ObjectIDs[4]);
if not Result then
for I := Low(ObjectIDs) to High(ObjectIDs) do
WriteLn(Format('[%d] %.8x', [I, ObjectIDs[I]]));
end;
begin
try
if TestEditCLOBWithroBeforeEdit then
WriteLn('PASS')
else
WriteLn('FAIL');
except
on E: Exception do
begin
WriteLn('FAIL - Exception Error');
WriteLn(' E.ClassName = ', E.ClassName);
WriteLn(' E.Message = ', E.Message);
end;
end;
ReadLn;
end.
- create a new console application in Delphi and paste the code
- adjust the constants cServer, cUserName and cPassword
- start dbMonitor
- compile and run the example
- check output
expected: output is PASS
actual: output is
[1] <8-digit hex value>
[2] <8-digit hex value>
[3] <8-digit hex value>
[4] <8-digit hex value>
FAIL
- check dbMonitor Object Tree
expected:
- it has beside the session the four items qrTest1, qrTest2, qrTest3 and qrTest4
- each qrTest<Number> has one "SELECT <Value> FROM DUAL" statement
actual:
- it has beside the session only qrTest1
- qrTest1 has four "SELECT <Value> FROM DUAL" statements
In order to fix this issue I've changed DASQLMonitor.GetObjectID to take the component name into account by building a string of the hex value of the pointer and the component name. It looks like this:
Code: Select all
function GetObjectID(Obj: TObject): Integer;
var
S: string;
begin
{$IFDEF CLR}
if Obj = nil then
Result := 0
else
{$ENDIF}
if Obj is TComponent then
begin
S := IntToHex(NativeInt(Obj), SizeOf(Pointer) * 2) + TComponent(Obj).Name;
Result := BobJenkinsHash(S[1], Length(S) * SizeOf(S[1]), 0);
end
else
Result := Integer(Obj{$IFDEF CLR}.GetHashCode{$ENDIF});
end;
Consider adding this (IFDEFed if required) or something similar to your code to fix the issue. Furthermore check GetObjectName for Win64, because IntToHex uses a fixed length of eight and not a compile time evaluated value of SizeOf(Pointer) * 2.
- Tue 10 Mar 2015 12:14
- Forum: Oracle Data Access Components
- Topic: Runtime error 216 since ODAC 9.3.9
- Replies: 3
- Views: 1250
Re: Runtime error 216 since ODAC 9.3.9
I've tested 9.4.14 before my initial post and the description of the issue with your code applies to 9.4.14. However the runtime error 216 symptom exists since 9.3.9, that information might help you even if the code I referred to might be older than 9.3.9, but gets a problem since 9.3.9 due to other changes (critical sections?). Using FastMM in FullDebugMode helps to catch the issue, because freed memory is filled with $80.
Behavior:
- 9.2.5 -> everything okay regarding the shutdown
- 9.2.7 and 9.3.8 -> no runtime error 216 on shutdown, but a memory leak (37 - 52 bytes: TOCISvcCtx x 1)
- 9.3.9 and newer -> runtime error 216 on shutdown
Memory leak details
--------------------------------2015/3/10 12:57:15--------------------------------
A memory block has been leaked. The size is: 52
This block was allocated by thread 0x2BDC, and the stack trace (return addresses) at the time was:
404C16
407CF7
408366
BD3A2A [OraCall.pas][OraCall][OraCall.TOCISvcCtx.Create][6766]
BD1369 [OraCall.pas][OraCall][OraCall.TOracleHome.AllocEnvironment][5855]
C493AD [OraClasses.pas][OraClasses][OraClasses.TOCIConnection.Connect][2774]
B99BBD [DBAccess.pas][DBAccess][DBAccess.TCustomDAConnection.DoConnect][3903]
C95DC3 [Ora.pas][Ora][Ora.TOraSession.DoConnect][2459]
B99FBA [DBAccess.pas][DBAccess][DBAccess.TCustomDAConnection.PerformConnect][4019]
B9CFBE [DBAccess.pas][DBAccess][DBAccess.TCustomDAConnection.SetConnected][4982]
C98415 [Ora.pas][Ora][Ora.TOraSession.SetConnected][2892]
The block is currently used for an object of class: TOCISvcCtx
Behavior:
- 9.2.5 -> everything okay regarding the shutdown
- 9.2.7 and 9.3.8 -> no runtime error 216 on shutdown, but a memory leak (37 - 52 bytes: TOCISvcCtx x 1)
- 9.3.9 and newer -> runtime error 216 on shutdown
Memory leak details
--------------------------------2015/3/10 12:57:15--------------------------------
A memory block has been leaked. The size is: 52
This block was allocated by thread 0x2BDC, and the stack trace (return addresses) at the time was:
404C16
407CF7
408366
BD3A2A [OraCall.pas][OraCall][OraCall.TOCISvcCtx.Create][6766]
BD1369 [OraCall.pas][OraCall][OraCall.TOracleHome.AllocEnvironment][5855]
C493AD [OraClasses.pas][OraClasses][OraClasses.TOCIConnection.Connect][2774]
B99BBD [DBAccess.pas][DBAccess][DBAccess.TCustomDAConnection.DoConnect][3903]
C95DC3 [Ora.pas][Ora][Ora.TOraSession.DoConnect][2459]
B99FBA [DBAccess.pas][DBAccess][DBAccess.TCustomDAConnection.PerformConnect][4019]
B9CFBE [DBAccess.pas][DBAccess][DBAccess.TCustomDAConnection.SetConnected][4982]
C98415 [Ora.pas][Ora][Ora.TOraSession.SetConnected][2892]
The block is currently used for an object of class: TOCISvcCtx
- Mon 09 Mar 2015 16:47
- Forum: Oracle Data Access Components
- Topic: Runtime error 216 since ODAC 9.3.9
- Replies: 3
- Views: 1250
Runtime error 216 since ODAC 9.3.9
Since ODAC 9.3.9 a runtime error 216 can appear when closing an application. I cannot provide a testcase, but describe the problem with your code and expect that you find and fix the issue.
The issue is related to your manual ARC and it crashs in TOCIEnvironment.FreeErrorHandle called from TOCIEnvironment.Release, because Home is invalid. (F)Home or better to say the whole TOCIEnvironment instance is invalid, because it was already destroyed by the call to TOCIEnvironment.ClearOCISvcCtxs within the middle of TOCIEnvironment.Release. ClearOCISvcCtxs calls TOCISvcCtx(FOCISvcCtxs).Release, which calls SetEnvironment(nil), that may decrement the refcounter on the TOCIEnvironment instance it is being called from. The refcount decrease does cause the destruction and so on.
The issue is related to your manual ARC and it crashs in TOCIEnvironment.FreeErrorHandle called from TOCIEnvironment.Release, because Home is invalid. (F)Home or better to say the whole TOCIEnvironment instance is invalid, because it was already destroyed by the call to TOCIEnvironment.ClearOCISvcCtxs within the middle of TOCIEnvironment.Release. ClearOCISvcCtxs calls TOCISvcCtx(FOCISvcCtxs).Release, which calls SetEnvironment(nil), that may decrement the refcounter on the TOCIEnvironment instance it is being called from. The refcount decrease does cause the destruction and so on.
- Tue 14 Jan 2014 09:19
- Forum: Oracle Data Access Components
- Topic: RefreshRecord in ODAC 9.2.5
- Replies: 2
- Views: 1195
Re: RefreshRecord in ODAC 9.2.5
We have searched your code and found a difference in function "GetActualFieldName" bettween ODAC 8.6.11 and 9.2.5.
8.6.11:
9.2.5:
The restriction "UpdTableIsArtificial" has gone.
8.6.11:
Code: Select all
if IsRefresh and (FDataSet.Options.FullRefresh or FDataSet.ReadOnly) and
not DataSetService.FUpdTableIsArtificial then
Code: Select all
if IsRefresh and (FFullRefresh or FReadOnly) then