Search found 78 matches

by cis-wurzen
Thu 19 May 2022 11:10
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

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.
by cis-wurzen
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)
by cis-wurzen
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.
by cis-wurzen
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?
by cis-wurzen
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 -----

by cis-wurzen
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

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.
by cis-wurzen
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.
by cis-wurzen
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:

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.
Output:

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;
------------------
If "DROP JAVA SOURCE" is in line, every following line will included in active SQL.
Obviously Oracle answers with ORA-00933
by cis-wurzen
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.
Output
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
by cis-wurzen
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.
TOraAlerter Members

Session
Specifies the session for TOraAlerter to create an internal TOraSession object based on this session settings.
Need to set CLIENT_INFO for FListenConnection in "procedure TOCIAlerter.Start" (OraClasses.pas) after "FListenConnection.Connect('');".

Access to FListenConnection via class helper is possible but calling FListenConnection.ExecCommand after start of FListenThread hangs application.
by cis-wurzen
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:

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.
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:

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;
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.
by cis-wurzen
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
by cis-wurzen
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.
by cis-wurzen
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:

Code: Select all

if IsRefresh and (FDataSet.Options.FullRefresh or FDataSet.ReadOnly) and
   not DataSetService.FUpdTableIsArtificial then
9.2.5:

Code: Select all

if IsRefresh and (FFullRefresh or FReadOnly) then
The restriction "UpdTableIsArtificial" has gone.