Неверно формируется индексный файл таблицы FPD2.6 при добавлении записей из VFP9.
Сложный индекс с фильтром, добавляю данные в таблицу чужой программы.

В FPD2.6 выполним такой код:
----------------------------
close all
set talk on
clear
create table tab (podr c(1),tn n(4,0),g n(2,0),m n(2,0),vo c(1),pr c(1),pr1 c(1),s n(10.3))
index on PODR+STR(TN,4)+CHR(IIF(G>90,G-90,G+10))+CHR(M)+VO+LOWER(PR1) tag podr for pr#chr(254)
use tab order tag podr shared

Переключимся в VFP9
-------------------
use tab order tag podr shared
* пытался вставить здесь SET NOCPTRANS TO podr,vo,pr,pr1 - на результат не влияет
for i=1 to 100
insert into tab (podr,tn,g,m,vo,pr1,s) values;
(chr(i),4000+i,12,8,chr(47),"",i)
endfor
USE IN tab

Вернемся в FPD2.6
--------------
clear
select tab
sum s
*здесь сумма 100 записей = 5050
repl all pr with chr(254)
* после этого сумма должна быть 0, но нет
sum s
use tab exclusive
reindex
*после переиндексации все приходит в норму
set order to tag podr
sum s

Скореее всего, дело в использовании функций CHR() в индексном выражении, в т.ч. в фильтре
при разных кодовых страницах.

Это как-то можно решить?

Jonny540s_gonchcreate table tab (podr c(1),tn n(4,0),g n(2,0),m n(2,0),vo c(1),pr c(1),pr1 c(1),s n(10.3))
index on PODR+STR(TN,4)+CHR(IIF(G>90,G-90,G+10))+CHR(M)+VO+LOWER(PR1) tag podr for pr#chr(254)
use tab order tag podr shared
После CREATE таблица открывается автоматом в режиме EXCLUSIVE, а ты потом ее еще раз открываешь, уже после индексации.
Может быть, в этом все дело? Хотя должна появиться ошибка при повторном открытии.

Ругаться будет, если открывать в другой рабочей области под тем же алиасом.
А так, если в текущей рабочей области что-то было открыто- оно закроется, потом откроется то, что прописано в команде USE...
Т.е. просто переоткроется таблица уже в режиме SHARED.

Dima T Тут почитай
Почитал. Решения пока не придумал.
С кодовой страницей в таблице TAB из примера все нормально, CP866.
Еще раз обращаю внимание, что ДАННЫЕ пишутся в таблицу ПРАВИЛЬНО. Там, где надо, данные конвертируются (Фамилии, напр.),
где не надо - не конвертируются (если в символьном поле храниться, напр., двоичный код, не я это придумал).
При записи в такую таблицу VFP по умолчанию конвертирует символьные данные из CP1251 в CP866.
Т.е. пишем символ "Я" из VFP в таблицу FPD, открываем ее в FPD, и видим ту же букву "Я", только уже в СР866.
Процесс в части символьных данных вполне управляем(set nocptrans to ..., cpconvert(1251,866,...)).
Проблема где-то в индексах.
Если в индексном выражении используется CHR(X), получается косячок, надо после вставки данных из VFP переиндескировать таблицу в FPD. А хотелось бы этого избежать...

AndreTMЕсли все действия произвести в FPD - получается тоже неверная сумма после replace pr ?

Да, и после добавления записей (раз у вас индекс с фильтром) - не попробовать ли сначала принудительно передвинуть указатель (GO или SKIP)?

Если все делать в FPD, все работает как надо.
SUM S двигает указатель по всем записям, удовлетворяющим условию фильтра в индексном выражении.
Хоть 10 раз суммируй- результат не изменится, даже закрыть-открыть таблицу ничего не меняет, зато переиндексация все приводит в порядок.
Интересно, что после repl all pr with chr(254) команда BROW показывает пустое окно (как должно быть), зато команда LIST выводит в конкретном случае 3 записи на экран, причем они идут не подряд. И эти записи суммируются.

AndreTMХа, тупим мы! Соответственно, нашел для вас в уже обсуждавшемся
Все, вопрос закрыт. Не буду писать прямо в таблицу, сделаю передачу данных через вспомогательный файл. Это всяко надежнее, чем заставлять переиндексировать таблицы после переноса данных.

ВСЕМ СПАСИБО!