По ключевым полям, как правило, есть индекс. В этом случае абсолютно все-равно какой тип данных используется. Время поиска будет сопоставимо при любом типе данных.

Так что с точки зрения быстродействия - это дело исключительно личных предпочтений программиста.

Проблема с Combo возникает если:

1) В качестве источника данных выступают напрямую поля таблицы (RowSourceType = 6)
2) Ключевое поле имеет числовой тип

Соответсвенно, решением проблемы является замена источника данных (я использую массивы) или изменение типа (что проблематично)

===========================================================
Насчет длины ключа.

Как правило, в качестве ключевого поля используются поля типа Integer. Т.е. физически они занимают 4 байта на каждую запись. При этом, опять же как правило, используются только положительные значения, т.е. диапазон значений ключа от 0 до 2 147 483 647.

Много это или мало?

Опять же, как правило, срок жизни программы не превышает 2...3 лет. Данные живут несколько больше, примерно 10...15 лет. Предположим, что данные у нас "вечные" и живут 100 лет.

Это значит, что для того, чтобы достичь предела насыщения типа Integer пользователи должны в течении 100 лет ежедневно без перерыва на праздники и выходные вколачивать в базу данных примерно по 60 тысяч записей.

Согласен, бывают и такие задачи. НО!!! Для подобных задач DBF-таблицы становятся уже неприемлимыми, поскольку они просто физически не могут вместить такое количество записей. Предел DBF-таблиц - это 1 миллиард записей, т.е. примерно половина диапазона типа Integer.

Если вернуться к типу Character, то исходя из предположения, что длина ключа не должна превышать тип Integer, мы должны установить длину C(4). Предположим, что в качестве значения могут использоваться все 254 символа кодовой страницы. Это значит, что предельно возможное количество значений такого ключа составит:

254**4= 4,162,314,256

Т.е. всего в 2 раза больше чем для типа Integer. Если же вспомнить, что ряд символов использовать неудобно по разным причинам, то остается около 100 допустимых символов для использования в качестве ключа. Т.е. возвращаемся примерно к тому же диапазону значений, что и для типа Integer.

Итого, с точки зрения длины ключа тип Character не дает никаких преимуществ при использовании в DBF-таблицах по сравнению с типом Integer.

Подчеркну еще раз, в данном случае я рассмотрел только аспект физической длины ключа. Однако есть задачи, когда использование в качестве ключевого поля типа Character становится предпочтительнее. Но это связано уже не с какими-то техническими проблемами, а исключительно с логикой реализации задачи.

Если же вспомнить, что в MS SQL и в VFP8 существует такое понятие как автоинкрементные поля, которые просто не могут не быть числовыми. То вопрос о типе ключевого поля вообще становится чисто теоретическим. И опять же переходит из области чисто практической в область личных предпочтений программиста.

Суть бага заключается в том, что выбранное текущее значение НЕ ОТОБРАЖАЕТСЯ. Т.е. значения Value абсолютно правильные, но вот вместо DisplayValue отображается пустая строка.

Как правило, этот баг проявляется при использовании ComboBox внутри Grid. Причем при потере фокуса в текущей ячейке правильное отображение восстанавливается. Проблема именно в той ячейке, где в данный момент находися фокус.