SIGSEV with ZDbcCache on line 795

The official tester's forum for ZeosLib 7.1. Ask for help, post proposals or solutions.
Post Reply
douglascast
Fresh Boarder
Fresh Boarder
Posts: 1
Joined: 03.06.2016, 21:03

SIGSEV with ZDbcCache on line 795

Post by douglascast »

Hi guys, I'm trying to understand a little error I'm having with a end; stament in Pascal and Zeos components.

On my application I have some forms and a datamodule to store all the database stuff, but when I try to save some information to the database one end; command causes a SIGSEV with ZDbcCache on line 795 (Index :=-1; the line content), but if I change the end position this works well (or I suppose so), but the problem is that the same end works on the other forms that I have, so this end placement is a (visual) exception only in my 'place register' form.

Using Lazarus 1.6 and Zeos 7.1.4

Hier is how I use the code in the User Register Form

Code: Select all

try
 with datam.qry do begin
 datam.connection.AutoCommit:=True;
 datam.connection.StartTransaction;
 SQL.Clear;
 SQL.Text='INSERT INTO ...';
 ParamByName('param').AsString:=tedit.Text;
 ParamByName('param').AsInteger:=combobox.ItemIndex;
 ExecSQL;
 
 try
  datam.connection.Commit;
  clear_data_fields;
 except
  datam.Rollback;
  ShowMessage('Error');
 end;
 end; //this end is fine and before the second try end;
except
 ShowMessage('Impossible to connect to the database');
end; 

Code: Select all

try
 with datam.qry do begin
 datam.connection.AutoCommit:=True;
 datam.connection.StartTransaction;
 SQL.Clear;
 SQL.Text='INSERT INTO ...';
 ParamByName('param').AsString:=tedit.Text;
 ParamByName('param').AsInteger:=combobox.ItemIndex;
 ExecSQL;
 end; //in the Place Register form I'm obliged to use it hier
 
 try
  datam.connection.Commit;
  clear_data_fields;
 except
  datam.Rollback;
  ShowMessage('Error');
 end;
except
 ShowMessage('Impossible to connect to the database');
end;
Hier it's the code of the ZDbcCache file

Code: Select all

{**
  Cleans the specified row buffer.
  @param Buffer a pointer to row buffer.
}
procedure TZRowAccessor.ClearBuffer(Buffer: PZRowBuffer);
var
  I: Integer;
  P: PPointer;
begin
  with Buffer^ do
  begin
    Index := -1; //LINE 795
    UpdateType := utUnmodified;
    BookmarkFlag := 0;
    for I := 0 to FColumnCount - 1 do
      case FColumnTypes[I] of
        stAsciiStream, stUnicodeStream, stBinaryStream:
          if (Columns[FColumnOffsets[I]] = 0) then
            SetBlobObject(Buffer, I + 1, nil);
        stBytes,stGUID,stString, stUnicodeString:
          if PNativeUInt(@Columns[FColumnOffsets[I] +1])^ > 0 then
          begin
            P := PPointer(@Columns[FColumnOffsets[I] +1]);
            System.Dispose(P^);
          end;
      end;
    FillChar(Columns, FColumnsSize, 0);
    for I := 0 to FColumnCount - 1 do Columns[FColumnOffsets[I]] := 1;
  end;
end;  
Any help is wellcome.
marsupilami
Platinum Boarder
Platinum Boarder
Posts: 1956
Joined: 17.01.2011, 14:17

Re: SIGSEV with ZDbcCache on line 795

Post by marsupilami »

Hello douglascast,

this seems strange because end is not even a command and usually is completely compiler related. No Zeos things should be executed there. Can you prepare a small sample program and database that raise this error? Did you try Zeos 7.2? Although Zeos 7.2 is still officially in Beta state it should be more stable than 7.1 already.

One strange thing that I see in your example nonetheless: in your inner try ... except ... end clause you first commit your changes to the database and then call clear_data_fields. If for some reason an exception is raised in clear_data_fields, you will go to the exception bloc, try to rollback an explicit transaction, that doesn't exist there anymore and get another exception. This in turn will skip your ShowMessage('Error'), and then call the exception handler of the outer try ... except ... end block - which in tun will tell you that you can't connect to your database. You might want to consider to move clear_data_fields after the inner try ... except ... end block or even better after the outher one.

With best regards,

Jan
Post Reply