Есть сервер (MySQL, PostgreSQL и пр.), подключение по ODBC. Конструктор удаленных представлений видит таблицу, берет символьную колонку исходного типа char или varchar, ставит свой тип character, а длину ставит 20, если длина исходного >=20, и реальную, если она меньше 20. Если в Properties поменять - то этого изменения хватает только до следующего обращения к Properties этой или другой колонки. Соответственно, в grid, browse, отчетах и прочих элементах отображаются (и позволяется ввод) только 20 символов на поле. Что за дурацкий глюк ?

pack database не помогает. Все равно длина хотя-бы одного поля остается равной 20. Во вновь созданной базе .dbc и вновь созданном view наблюдается та же картинка. Мало того. Имеется большая проблема с буферизацией. В режиме мягкой буферизации таблицы-представления (5) функция tableupdate дает запросы на изменение (или вставку) только для последней измененной (добавленной) записи. Переключение режима транзакций для соответствующего представления дает только включение begin ... commit для блока открытия-работы-закрытия представления, но никак не влияет на результат :(. Это дело наблюдается как для grid, так и для browse.
Жопа, короче, с VFP6. Уже попробовал это же как на MySQL, так и на PostgreSQL с разными версиями ODBC-драйверов. Дело-таки в VFP. У меня SP5.

>1) Создал таблицу в MySQL с полем Char(40)
>2) Создал Remote View к этой таблице, добавил в список полей для выборке >имя этого поля и ... в нем это поле автоамтически получилось Char(20)?
ИМЕННО !
Но в реальной таблице - несколько текстовых полей (плохо, когда 10-15-20). Автоматически при создании view хотя-бы одно создается с неправильной длиной. Чем больше полей char (varchar) - тем больше ошибок. Если на всех полях поменять все длины на корректные и сохранить view - все равно окажется, что хоть одно поле осталось char 20 :-(Ж)

>По поводу буферизации у тебя неправльное понимание логики работы Remote >View.
Все я понимаю. Не понимаю только, где VFP девает обновления для остальных записей ? Раз уж юзер поменял несколько записей и делает tableupdate, то на сервер должны выдаваться несколько операторов update (insert) ? Неважно, делается begin - commit или нет. Это к слову пришлось. Или tableupdate нужно как-то по-хитрому выдавать ? Например, в цикле, проходя по каждой записи обновленного курсора ? Бо я увидел, что обновляется именно запись, которая текущая на момент tableupdate. А если записей 100-200 ? И что:
go top
scan while .not. eof()
tableupdate()
endscan

Ну и кто-то выдает begin-commit (автоматом или через Exec)
Так, что-ли ???

По tableupdate проехали - я тупой, забыл про параметр :-) А с ошибкой в размере колонок ... Я в задумчивости ...

Действительно, кроме как глюком View-дизайнера это не объясняется. Обойти его можно. Нужно исправлять ошибки в длинах полей по одной и сохранять. А при открытии запроса в дизайнере не обращать внимание на ошибку в длине ПЕРВОГО открываемого char-поля. Как сказал ВладимирМ: "Большая магия, однако !" Мне кажется, глюк объясняется большим количеством символов перевода строки в memo-поле Properties для строк таблицы-контейнера базы данных, относящихся к названиям столбцов. Когда смотришь на текст
............&...........-........inoorder.contragent_name.....&MC70
(точки вместо переводов строк), то сам путаешься :-)