| Subject | Re: [IBO] IB_Parse.pas - ROWS not recognized as SQL token |
|---|---|
| Author | Geoff Worboys |
| Post date | 2010-04-16T00:03:33Z |
Hi Thomas,
know "correct" sorting depends on the compare operators used.
'_' comes before 'S' is many collations
but
'_' comes after 'S' (but before 's') in ASCII (and ANSI/Win1252)
The code which processes the array uses simple Delphi operators
('<' and '<>') and also StrComp (byte order comparison, which
is effectively ASCII/ANSI in this case), so the code requires
the correction you noted: '_' must come after 'S' in the list.
Your correction should be safe because the array is private to
the ib_parse unit, so no other code (using different compare
operators) can be relying on a different sort order.
--
Geoff Worboys
Telesis Computing
> ...The search code assumes the array is sorted... and as we all
> 'ROLLBACK',
> 'ROW_COUNT', // fb1.5
> 'ROWS', // fb2.0, ib6.5
> 'RUNTIME',
> ...
> which does not recognize ROWS as keyword. If I make it that way:
> ...
> 'ROLLBACK',
> 'ROWS', // fb2.0, ib6.5
> 'ROW_COUNT', // fb1.5
> 'RUNTIME',
> ...
> ROWS is detected as SQL token properly.
> Comments?
know "correct" sorting depends on the compare operators used.
'_' comes before 'S' is many collations
but
'_' comes after 'S' (but before 's') in ASCII (and ANSI/Win1252)
The code which processes the array uses simple Delphi operators
('<' and '<>') and also StrComp (byte order comparison, which
is effectively ASCII/ANSI in this case), so the code requires
the correction you noted: '_' must come after 'S' in the list.
Your correction should be safe because the array is private to
the ib_parse unit, so no other code (using different compare
operators) can be relying on a different sort order.
--
Geoff Worboys
Telesis Computing