Новые шокирующие результаты экспериментов
Лия, создайте в справочнике (kadbl_kv.dbf) новое поле формата 20.13 , и пересчитайте в нём значения по полю Pl (которое вроде бы 10.4). Вы получите мноооого чисел вида 2145.1918000000001 и 1854.0447999999999 
Далее, попробуйте создать поле формата 20.12, и пересчитайте его теперь уже по полю 20.13. Всё вроде бы становится на свои места, например, числа выше округляются до 2145.191800000000 и 1854.044800000000.
Но теперь создайте ещё одно поле формата 20.13, и пересчитайте его по 20.12 - все хвосты вылезут опять 
Почему так получается - всё ещё вопрос. Я провёл и другой эксперимент: создал совершенно новую пустую таблицу, в ней три поля (24.14, 10.4, и ещё раз 24.14), и прогнал по ним пару случайных чисел:
0.12339999999990
2345.12339999999990
Сначала в поле 10.4 они, как и предполагалось, превращаются в
0.1234
2345.1234
А дальше, при новом пересчёте в 24.14 , результаты ошеломляют:
0.12340000000000
2345.12339999999990
Вот тебе, бабушка, и рокенролл.
Следовательно, всё дело в обработке чисел с двойной точностью. В файлах dBase (который и есть dbf), числа с плавающей точкой хранятся в формате Double: Signed 64-bit IEEE double-precision floating point number (8 bytes) (см. http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf). Хоть какой там формат задай (10.4 или 24.14, не важно), всё равно внутри получится Double.
В математику формата Double влазить сейчас неохота, но вообще этот результат хотя и удручающий, но не неожиданный, если вспомнить, чему учили в универе про машинное представление чисел с плавающей точкой. В принципе, должен был раньше догадаться.
Так что вердикт: обрезайте все теоретически возможные хвосты ДО их занесения в таблицы и ДО сравнения. Не стесняйтесь использовать Round, там где это нужно, хотя вы уже высказали своё отношение к этому 
. Я подозреваю, что таков уж характер ваших данных - где-то там всё время появляется значность до 13 разряда. Раз уж это так, придётся их ROUND-ом.
