Search found 13 matches

by cross_join
Mon 30 May 2016 10:27
Forum: Universal Data Access Components
Topic: SmartFetch high memory usage on SQL Server
Replies: 11
Views: 2985

Re: SmartFetch high memory usage on SQL Server

azyk wrote:We failed to reproduce the specified behavior, when dataset fetch all data from table. Please try compose a small example allowing to reproduce the issue and send it to andreyz*devart*com.

We tried to reproduce it with the following code:

Code: Select all

UniConnection1.SpecificOptions.Values['SQL Server.Provider'] := 'prDirect';
UniTable1.SpecificOptions.Values['SQL Server.FetchAll'] := 'False';
UniTable1.SmartFetch.Enabled := False;

UniTable1.Open;
What exactly did you fail to reproduce???
Your code lead to fetch all table's rows to dataset. It's known bug of prDirect mode regardless FetchAll option's value.
Try it with any table and check UniTable1.RecordCount if OutOfMemory error won't be shown before :)
by cross_join
Fri 06 May 2016 07:53
Forum: Universal Data Access Components
Topic: SmartFetch high memory usage on SQL Server
Replies: 11
Views: 2985

Re: SmartFetch high memory usage on SQL Server

azyk wrote:We failed to reproduce the specified behavior, when dataset fetch all data from table. Please try compose a small example allowing to reproduce the issue and send it to andreyz*devart*com.

We tried to reproduce it with the following code:

Code: Select all

UniConnection1.SpecificOptions.Values['SQL Server.Provider'] := 'prDirect';
UniTable1.SpecificOptions.Values['SQL Server.FetchAll'] := 'False';
UniTable1.SmartFetch.Enabled := False;

UniTable1.Open;
Of corse you failed to reproduce because you're using FetchAll = 'False' !
FetchAll is "true" by default and set it to "false" is not usable in "real world" SQL Server's applications because of additional connection and transaction for every TUniTable component.
See my explanation above (http://forums.devart.com/viewtopic.php?p=115848#p115848).
by cross_join
Wed 27 Apr 2016 17:33
Forum: Universal Data Access Components
Topic: SmartFetch high memory usage on SQL Server
Replies: 11
Views: 2985

Re: SmartFetch high memory usage on SQL Server

No, direct mode doesn't resolve this issue.

Code: Select all

UniConnection1.SpecificOptions.Values['Provider'] := 'prDirect';
"Out of memory" error when SmartFetch is disabled (in 32-bits application) so it consumes more memory than OLEDB or native client.

For SmartFetch:
Open with SmartFetch, LiveBlock = false
Elapsed 3 sec
Memory usage: 1062 MB
Open with SmartFetch, LiveBlock = true
Elapsed 3 sec
Memory usage: 1060 MB
Also known issue that "Provider=prDirect" lead to fetching all rows from table regardless FetchAll=False.
by cross_join
Thu 14 Apr 2016 10:25
Forum: Universal Data Access Components
Topic: SmartFetch high memory usage on SQL Server
Replies: 11
Views: 2985

Re: SmartFetch high memory usage on SQL Server

AlexP wrote:Please describe in more details the problems you have encountered while using the FetchAll property - and we will try to help you solve them.
Here is an old discussion about (in Russian)

With FetchAll=True for every TUniTable an additional connection and transaction is created.
With many legacy TUniTable this lead to errors like "cannot create new transaction because capacity was exceeded".

Indeed SQL Server doesn't allow multiples transactions in the same connection. But it allows multiples cursors. I hope SmartFetch will use only one connection and won't use transactions but corresponding cursor's type.

P.S. MSSQL server cursors API reference
by cross_join
Mon 11 Apr 2016 09:25
Forum: Universal Data Access Components
Topic: SmartFetch high memory usage on SQL Server
Replies: 11
Views: 2985

Re: SmartFetch high memory usage on SQL Server

AlexP, thank you for answer.
It would be an important evolution of SmartFetch closing to smart BDE behaviour, because the custom option "FetchAll=False" lead to double connection in TUniTable component out of transaction scope.
by cross_join
Mon 04 Apr 2016 15:51
Forum: Universal Data Access Components
Topic: SmartFetch high memory usage on SQL Server
Replies: 11
Views: 2985

SmartFetch high memory usage on SQL Server

Hello,

I'm testing SmartFetch with SQL Server on some large table (several millions lines, about 20 columns, no BLOBs or texts). All connection settings are by default so OLEDB client should be used.

Indeed, SmartFetch is more rapid to extract data but the memory consumption is the same as I have without SmartFetch.
What's happened?
Open without SmartFetch
Elapsed 22 sec
Memory usage: 1377 MB
Open with SmartFetch, LiveBlock = false
Elapsed 5 sec
Memory usage: 1409 MB
Open with SmartFetch, LiveBlock = true
Elapsed 6 sec
Memory usage: 1409 MB

Code: Select all

  MemUsage1 := CurrentProcessMemory;
  Started := Now;
  Memo1.Lines.Add('Open without SmartFetch');
  UniTable1.Open;
  Memo1.Lines.Add(Format('Elapsed %d sec', [SecondsBetween(Now, Started)]));
  Memo1.Lines.Add(Format('Memory usage: %d MB', [(CurrentProcessMemory - MemUsage1) div (1024 * 1024)]));
  UniTable1.Close;

  Memo1.Lines.Add('Open with SmartFetch, LiveBlock = false');
  UniTable1.SmartFetch.Enabled := true;
  UniTable1.SmartFetch.LiveBlock := false;
  MemUsage1 := CurrentProcessMemory;
  Started := Now;
  UniTable1.Open;
  Memo1.Lines.Add(Format('Elapsed %d sec', [SecondsBetween(Now, Started)]));
  Memo1.Lines.Add(Format('Memory usage: %d MB', [(CurrentProcessMemory - MemUsage1) div (1024 * 1024)]));
  UniTable1.Close;

  Memo1.Lines.Add('Open with SmartFetch, LiveBlock = true');
  UniTable1.SmartFetch.Enabled := true;
  UniTable1.SmartFetch.LiveBlock := true;
  MemUsage1 := CurrentProcessMemory;
  Started := Now;
  UniTable1.Open;
  Memo1.Lines.Add(Format('Elapsed %d sec', [SecondsBetween(Now, Started)]));
  Memo1.Lines.Add(Format('Memory usage: %d MB', [(CurrentProcessMemory - MemUsage1) div (1024 * 1024)]));
  UniTable1.Close;
by cross_join
Fri 01 Apr 2016 08:44
Forum: SQL Server Data Access Components
Topic: Error When trying to perform edit operations
Replies: 7
Views: 4023

Re: Error When trying to perform edit operations

"FetchAll = true" is not a good solution at all because the dataset load all table's data to client. It's very dangerous that this value is used by default.
by cross_join
Wed 10 Feb 2016 10:13
Forum: Universal Data Access Components
Topic: TUniTable.UniDirectional lead to read only dataset (MSSQL)
Replies: 3
Views: 913

Re: TUniTable.UniDirectional lead to read only dataset (MSSQL)

Thank you for replying.
However, there is no relation between UniDirectional and ReadOnly in documentation.
On other hand, UniDirectional doesn't make dataset read-only with PostgreSQL, the scrolling forward and adding the data work fine with cached updates. It's not the case with MS SQL.
by cross_join
Tue 09 Feb 2016 14:53
Forum: Universal Data Access Components
Topic: TUniTable.UniDirectional lead to read only dataset (MSSQL)
Replies: 3
Views: 913

TUniTable.UniDirectional lead to read only dataset (MSSQL)

Hello,
When I set TUniTable.UniDirectional property to "true" and try to add a new record I get the error "dataset is read only".
Is it specific for MSSQL and Provider=prDirect?
Issue was reproduced with UniDAC 6.1.6 on Lazarus 1.4 and Delphi 7.

Any workarounds are welcome.
by cross_join
Fri 30 Oct 2015 12:22
Forum: Universal Data Access Components
Topic: TUniTable, PostgreSQL and FetchAll option
Replies: 3
Views: 832

Re: TUniTable, PostgreSQL and FetchAll option

azyk, thank you for explanations.
by cross_join
Thu 29 Oct 2015 10:48
Forum: Universal Data Access Components
Topic: TUniTable, PostgreSQL and FetchAll option
Replies: 3
Views: 832

TUniTable, PostgreSQL and FetchAll option

Hello all,
When setting

Code: Select all

UniTable.SpecificOptions.Values['FetchAll'] := 'false';
UniDAC open a second connection.

What are the reasons to use second connection?
What PostgreSQL particularities do this impact?
by cross_join
Wed 11 Feb 2015 17:51
Forum: Universal Data Access Components
Topic: TUniQuery and memory management
Replies: 2
Views: 6792

TUniQuery and memory management

Hello,

Indeed, there are two related problems that block using of large datasets.
  • After TUniQuery deletion the memory is not released until exiting application. But there is no memory leaks.
  • TUniQuery.SmartFetch does not work if UniDirectional is true. After scrolling on few records Query.EOF is true.
This problem is reproduced always but it more critical on large datasets scrolling (100K rows and more). I.e. when scrolling on 10000 rows with column of type varchar(255) the memory consumption is about 188 Kbytes (see results).

Example was built with Delphi 7, same problem with Lazarus.

Code: Select all

program UniMemoryUsage;

{$IFDEF FPC}
  {$MODE Delphi}
{$ENDIF}

{$APPTYPE CONSOLE}

uses
  Classes, SysUtils,
  Windows,
  {$IFDEF FPC}
  jwapsapi,
  {$ELSE}
  PSAPI,
  {$ENDIF}
  Uni, InterBaseUniProvider;

function CurrentProcessMemory: cardinal;
var
  MemCounters: TProcessMemoryCounters;
begin
  MemCounters.cb := SizeOf(MemCounters);
  if GetProcessMemoryInfo(GetCurrentProcess,
  {$IFDEF FPC}
      MemCounters,
  {$ELSE}
      @MemCounters,
  {$ENDIF}
      SizeOf(MemCounters)) then
    Result := MemCounters.WorkingSetSize
  else
    RaiseLastOSError;
end;

var
  Conn: TUniConnection;
  Qry: TUniQuery;
  Row: integer = 0;
  TextValue: string;
  m1, m2: cardinal;

begin
  try
    Conn := TUniConnection.Create(nil);
    Conn.ProviderName := 'InterBase';
    Conn.Database := ExtractFilePath(ParamStr(0)) + 'test.gdb';
    Conn.Server := 'localhost';
    Conn.UserName := 'SYSDBA';
    Conn.Password := 'masterkey';
    Conn.Open;

    m1 := CurrentProcessMemory;
    writeln('Before TUniQuery.Create. Current memory: ', CurrentProcessMemory);
    Qry := TUniQuery.Create(nil);
    Qry.Connection := Conn;
    Qry.SQL.Text := 'SELECT id, name FROM test_memo';
    // Settings to reduce memory usage
    Qry.UniDirectional := true;
    Qry.SpecificOptions.Values['FetchAll'] := 'false';
    Qry.FetchRows := 25;
    //Qry.SmartFetch.Enabled := true;
    //Qry.SmartFetch.LiveBlock := true;
    //Qry.SmartFetch.PrefetchedFields := 'name';
    Qry.Open;
    writeln('Qry.Open. Current memory: ', CurrentProcessMemory);
    while not Qry.EOF do
    begin
      Inc(Row);
      TextValue := Qry.FieldByName('NAME').AsString;
      if Row mod 1000 = 0 then
          writeln('Fetched ', Row, ' rows. Current memory: ', CurrentProcessMemory);
      Qry.Next;
    end;
    Qry.Close;
    writeln('Qry.Close. Current memory: ', CurrentProcessMemory);
    Qry.Free;
    m2 := CurrentProcessMemory;
    writeln('Qry.Free. Current memory: ', m2);
    writeln('Difference, Kbytes: ', (m2 - m1) div 1024);
    Conn.Free;
  except
    on E: Exception do
      writeln('Error: ', E.Message);
  end;
end.
 
Results:
Before TUniQuery.Create. Current memory: 4947968
Qry.Open. Current memory: 5160960
Fetched 1000 rows. Current memory: 5160960
Fetched 2000 rows. Current memory: 5160960
Fetched 3000 rows. Current memory: 5160960
Fetched 4000 rows. Current memory: 5160960
Fetched 5000 rows. Current memory: 5160960
Fetched 6000 rows. Current memory: 5160960
Fetched 7000 rows. Current memory: 5160960
Fetched 8000 rows. Current memory: 5160960
Fetched 9000 rows. Current memory: 5160960
Qry.Close. Current memory: 5160960
Qry.Free. Current memory: 5136384
Difference, Kbytes: 184