mORMot Open Source

Hi,

in our legacy application we're using SynDbOracle. I realized it is not possible saving years > 4096 using array binding. In our application the date 9999-12-31 is used as infinite. With "normal" parameter binding it is no problem saving those values.

The problem is the conversion from ISO string to TOracleDate in TSQLDBOracleStatement.ExecutePrepared

....
ftUTF8,ftDate: begin
              L := length(VArray[j])-2; // -2 since quotes will be removed
              if VType=ftDate then
                if L<=0 then
                  oDataDAT^[j].From(0) else
>>>>>>    oDataDAT^[j].From(PUTF8Char(pointer(VArray[j]))+1,L)
....

The problem can also easily be reproduced using a TOracleDate variable.

1) do a From('9999-01-01T15:00:00')
2) do a ToIso8601

You'll see that the resulting value is 1807-01-01T15:00:00 which can also be found in a inserted record.

Is this behaviour known ?

best regards,
Matthias

Hi,

using the http api server in single threaded mode (tmMainConnection) it allows to use transactions. If a transaction of one client is going on, it corretly rejects transaction starts of other clients (after some internal retries).

But if another client does an insert or update out of any transaction this one is executed in the currently active transaction of the other client.

Is this a known or the intended behaviour?

Best regards,
Matthias

Hi,

i just wanted to share a thought. In SetInternalProperties of the SQLDBProxyConnectionProperties, called from the constructor, the initial connect is made to the SQLDBServerHttpApi. After getting the token the session is established and the session id is retrieved.

SynDB.pas
procedure TSQLDBProxyConnectionPropertiesAbstract.SetInternalProperties;
...
begin
  ...
  Process(cGetToken,self,token);
  ...
  CurrentSession := Process(cGetDBMS,InputCredential,fDBMS);
end;

If anything is going wrong here (causing an exception), the destructor is called - since the exception happened in the constructor. In the destructor Process(Quit) is called, trying to end the session on the server.

destructor TSQLDBProxyConnectionPropertiesAbstract.Destroy;
begin
  try
    inherited Destroy;
    Process(cQuit,self,self);
  finally
    fProtocol.Free;
  end;
end;

If the connection never has been established (due to an connection error, wrong password) it will raise another exception in the destructor and in case of an timeout related connection error another wait for the timeout to happen. Wouldn't it make more sense to suppress the call to quit in such scenarios?

Thanks for your opinion,
Matthias

Hi,

if we use the following query

select bound from (Select :bound bound from dual union all Select :bound2 bound from dual) order by 1

the column named "bound" returns ''.

SynLog reveals, that the column has been truncated.

20170621 09311207 SQL   TOurOracleStatement(04242EE0) select bound from (Select 'Testinhalt' bound from dual union all Select 'Testinhalt2' bound from dual) order by 1
20170621 09311207 DB    Truncated column BOUND

If the query is run again, it works due to the query cache. Disabling the query cache always generates this error.

The logging is called in the TSQLDBOracleStatement.GetCol-method.

Can anyone confirm this or have an idea of how to solve it?

thanks for your response,
Matthias

Hi,

we are migrating the database layer of our existing legacy application to mORMot, mainly using the compatibility class TQuery.
For accessing the database we use FireDAC as we also utilize the oracle events feature (DBMS_ALERT).

Running our own testcases we experienced a problem using query parameters if null values are involved. FireDAC complains that the datatype is not defined.
Especially if the query is cached it can happen that a parameter is null the first time, and of correct value the next time the query is executed.

Finally we fixed it on our side by calling a template method in procedure TQuery.Execute(ExpectResults: Boolean); before the actual parameter binding takes place. In this template method we set the actual data type of the original FireDAC parameter instance. We know the parameter types anyways, as in our existing code the parameters had been declared explicitly.

Maybe there is also another possible approach to fix it.

Best regards,
Matt