You are not logged in.
Hello,
I found small problem. In some cases when I call SetMaxLengthFilterForTextFields procedure then EOverflow exception is raised. Problem exist for the properties which does not have index parameter defined. For example:
TTest1Item = class(TSQLRecord)
private
FTestProp: TDateTime;
published
property TestProp: TDateTime read FTestProp write FTestProp;
end;
TTest2Item = class(TSQLRecord)
private
FTestProp: RawUTF8;
published
property TestProp: RawUTF8 read FTestProp write FTestProp;
end;
TTest3Item = class(TSQLRecord)
private
FTestProp: string;
published
property TestProp: string read FTestProp write FTestProp;
end;
and of course when overflow control is on in compiler. This is not a problem with production code but in testing code it makes some troubles. I have change condition:
if (SQLFieldType in TEXT_FIELDS) and (cardinal(FieldWidth-1)<262144) then
to:
if (SQLFieldType in TEXT_FIELDS) and (cardinal(FieldWidth)<262144) and (FieldWidth <> 0) then
After this correction everything works correctly.
best regards
Adam Siwon
Offline
Hello,
I have not changed original source code of mORMot. But I made copy of this procedure to my own code. Its because I have my own version of truncate filter. My version of filter saves to the log file informations about truncation. Thats why in my case exception occurs. When Overflow checking is disabled then for original mORMot code problem not exists.
best regards
Adam Siwon
Offline
So you would have to change your "forked" version to support overflow checking.
Your own code is to be modified, not mORMot's, I suppose.
But there is no problem in mORMot's code, which is always compiled without overflow checks, therefore not to be changed.
Compiler generated overflow checking slow down the process a lot, this is why we rely on manual or algorithm-level checks, and sometimes the overflows are expected to happen (e.g. when we cast an integer into a cardinal, so that a single comparison is able to check for both >=0 and <count conditions).
Offline
So you would have to change your "forked" version to support overflow checking.
Your own code is to be modified, not mORMot's, I suppose.But there is no problem in mORMot's code, which is always compiled without overflow checks, therefore not to be changed.
Yes.
Compiler generated overflow checking slow down the process a lot, this is why we rely on manual or algorithm-level checks, and sometimes the overflows are expected to happen (e.g. when we cast an integer into a cardinal, so that a single comparison is able to check for both >=0 and <count conditions).
I know that overflow slows down the process. I'm using it only when I'm compiling application in debug mode. Thank you very much for assistance.
best regards
Adam Siwon
Offline