Subject | Invalid KeyLinks cause by different search/sort rules |
---|---|
Author | str.exsoft |
Post date | 2013-02-21T13:20:22Z |
Hi,
we updated our application to Delphi XE3 and IBO 4.9.b54a. After running a test a second time, we get the error: 'Invalid KeyLinks Entry ...'.
The cause seems to be this:
* calculating the KeyLinks uses a TIB_StringList for the TableKeys which has entries TABLENAME=KEYFIELD1,KEYFIELD2,... for each table
* TableKeys is sorted by TABLENAME (part before the '=', it is not sorted by the whole item string) - the sort function uses IB_Parse.CompareIdentifierNames
in my example the list is filled with something like this:
...
RG=SYSNR,LF....
...
RG_ARTIK=ARNR
...
* to find an entry with TIB_StringList.FindNearestIndex, the function AnsiCompareText is used to compare "TABLENAME=" (equal sign including!)
* AnsiCompareText says e. g., that 'RG=SYSNR,' is greater than 'RG_ARTIK=' (AnsiCompareText is country specific)
* a wrong entry is retrieved (RG instead of RG_ARTIK)
<== sorting and searching are using different rules
Seems to be a bug? Is there a new version on the way?
... I don't have the overview over all the possible impacts to patch it by myself...
...by the way - why are duplicates allowed in TableKeys?
Regards
Stefan
we updated our application to Delphi XE3 and IBO 4.9.b54a. After running a test a second time, we get the error: 'Invalid KeyLinks Entry ...'.
The cause seems to be this:
* calculating the KeyLinks uses a TIB_StringList for the TableKeys which has entries TABLENAME=KEYFIELD1,KEYFIELD2,... for each table
* TableKeys is sorted by TABLENAME (part before the '=', it is not sorted by the whole item string) - the sort function uses IB_Parse.CompareIdentifierNames
in my example the list is filled with something like this:
...
RG=SYSNR,LF....
...
RG_ARTIK=ARNR
...
* to find an entry with TIB_StringList.FindNearestIndex, the function AnsiCompareText is used to compare "TABLENAME=" (equal sign including!)
* AnsiCompareText says e. g., that 'RG=SYSNR,' is greater than 'RG_ARTIK=' (AnsiCompareText is country specific)
* a wrong entry is retrieved (RG instead of RG_ARTIK)
<== sorting and searching are using different rules
Seems to be a bug? Is there a new version on the way?
... I don't have the overview over all the possible impacts to patch it by myself...
...by the way - why are duplicates allowed in TableKeys?
Regards
Stefan