AV when trying to create a dataset from a schema in linux

Data Abstract
1

With D 10.3 it fails with access violation. Works fine on Windows.

With D 10.2 it fails with access violation. Works fine on Windows.

I can send the sample project with test service causing the anomaly.

lConnection :=  ServerDataModule.ConnectionManager.NewConnection('replicatordb');
if not lConnection.InTransaction then lConnection.BeginTransaction;
lQuery := ServerDataModule.Schema.NewDataset(lConnection, 'db_names');
dw := lQuery.DynamicWhere;
dw.Clear;
dw.NewBinaryExpression('', 'db_name',  dboEqual, aLocalDataBaseName);
lQuery.Active := True;
if lQuery.eof then
begin
  lCmd :=  ServerDataModule.Schema.NewCommand(lConnection, 'insert_db_names');
  lCmd.ParamByName('id').AsString            := GenUUID;
  lCmd.ParamByName('db_name').AsString       := aLocalDataBaseName;
  lCmd.ParamByName('changed_at').AsDateTime  := now;
  lCmd.ParamByName('last_table_name').AsString  := aSchema + '.' + aTableName;
  lCmd.ParamByName('tag').AsInteger          := 0;
  lCmd.Execute;
end;

Best regards.

2

Hi,
do you mean create dataset from the schema instead of create schema from the dataset?

3

yes, was a typo. See that line.

lQuery := ServerDataModule.Schema.NewDataset(lConnection, 'db_names');

Best regards.

4

btw, this line has no sense.

probably, it should be

dw.Expression := dw.NewBinaryExpression('', 'db_name', dboEqual, aLocalDataBaseName);
5

Thanks, will fix

6

Update

Unidac driver don’t works in RIO with actual stable DA.
Firedac driver works ok with RIO.

I use Unidac 7.4.11 in this project without DA (just like plain library) and works perfects on windows and linux, so I guess there’s some conflict between UNIDAC and DA Driver for UNIDAC in general.
Also, FireDAC Driver for DA works perfect on Windows but FAILS on LINUX at this line with access violation:

50

36
Captura de pantalla 2019-01-16 a la(s) 12.53.36.png1108×248 9.05 KB

This happens with BOTH drivers.

I test all my main projects, working fine with Delphi 10.2.3 DA 1383, but fail with RIO 10.3 and DA build 1399.

Dont know how to help anymore at this point. Im a little dissaperated. All the normal stuff with unidac works excellent with the new compiler but DA is full ruined right now.

Tell me why to do.

Bets regards

7

Update…

Changed procedure:

function TDAEConnection.QuoteIdentifier(const iIdentifier: string): string;
var
  lQuoteChars: TDAQuoteCharArray;
begin
  {$ifdef console}
  {$ifndef fpc}
  // 26/01/2018 -> G.G. Adaptacion para postgres y unidac
  if (Self is TDAEUniDACConnection) then
  begin
    if (TDAEUniDACConnection(self).fDriverType = dauPostgreSQL) then
    begin
      Result := iIdentifier;
      exit;
    end;
  end;
  if (Self is TDAEFireDACConnection) then
  begin
    if (TDAEFireDACConnection(self).DriverType = mkPostgreSQL)  then
    begin
      Result := iIdentifier;
      exit;
    end;
  end;
  {$endif}
  {$endif}

DEBUG

FireDAC works ok

UNIDAC fails with message

03

51
Captura de pantalla 2019-01-16 a la(s) 18.59.51.png718×449 12.4 KB

RELEASE
Firedac or Unidac BOTH FAILS with message

01

20
Captura de pantalla 2019-01-16 a la(s) 19.20.20.png743×387 10.7 KB

Let me know what to do. I have until the Friday to solve this.

8

Hi,

you wanted to send to me a simple testcase that reproduces this issue …

9

Faster is you in my vm … but anyway will try to get one…

And then what? We never know if theres mor bugs out there?

Bets regards

10

re Unidac error:
you have used wrong overload function:

    lQuery := ServerDataModule.Schema.NewDataset(lConnection, 'db_names');

correct one is

    lQuery := ServerDataModule.Schema.NewDataset(lConnection, 'db_names',[],'','',false,true);

in your overload function, DynamicWhere was ignored because SQL was generated w/o WHERE {WHERE}. in my overload, it was generated correctly.

after this fix, debug and release version with UniDAC works w/o any problems.

11

workaround: add this code into eDefines.inc:

{$IFDEF NEXTGEN_or_DELPHILINUX}
  {$DEFINE FPC_SAFECALL_BUG}          // nextgen&linux compiler causes bug with safecall declarations
{$ENDIF}