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

В сетевом режиме на фоксе лучше уже вообще не работать, он всё же не для этого.

Конечно. В этом случае сохранение происходит только после ухода с поля. Т.к. в момент ручного редактирования мы работаем с буфером. (Не помню, можно ли его отключить)
Но в любом случае это не называется работой с БД



Он именно для этого и разрабатывался.

Это сообщение отредактировал(а) Reese - 9.6.2012, 15:03

Нет. Сохранение происходит или при закрытии (нормальном) фокса, или же принудительно командой FLUSH.

Может быть, когда альтернативы не было. Но сейчас я не представляю сетевую работу с фоксовой таблицей в 13 миллионов записей (какая вот у меня есть на FireBird).

Да. тут я не совсем прав. Если быть точным, то сохранение происходит в зависимости от типа буферизации. Не помню сейчас как они точно называются, но в двух случаях запись происходит при смене строки (тут я тоже не совсем точен насчет поля). Но это что касается работы с таблицей вручную, а так с таблицами все таки не работают. Только если что поправить надо.



Он и сейчас занимает свою нишу. Но сепецов по нему все меньше и меньше, да и Microsoft не хочет его развивать. Не выгоден он им. 

Да. 13 миллионов будет уже тяжеловато для фокса. Но на 10-20 рабочих мест при размере таблиц в пределах 10 миллионов с сумарным весом БД  в пределах 2 гб - фокс чуствует себя совсем не плохо. Опять же вместо сервера можно поставить простенький NAS (главное чтоб SMB нормально поддерживал и блокировки работали) и в случае какой нибудь поломки можно и по телефону объяснить что и куда скопировать т.к. уж чего-чего а с файлами всякие тетушки обычно справляются. Если что-то крупнее, то я тоже предпочту FireBird или DB2 (благо бесплатная версия не имеет ограничений на размер БД) к ним можно из того же Фокса подключиться.

А где она меняется?

Работают-работают.  

Это если там одно поле только. Ну или два.

свойство BufferMode у объектов _screen и form


15 полей. объем таблицы - чуть меньше 1 Гб


А смысл. Для такой работы обычно табличные процессоры используют.

А в меню фокса нет такой опции?

Ну, значит, поля по размеру небольшие.

Какие ещё процессоры: открыл таблицу в фоксе - и вперёд.

Кстати, попробовал связку и UPDATE - связка в разы быстрее работает, как я и говорил.

В в среднем C(50)


Нет. А зачем она там ?



Excel, Calc и т.д.


А поля, по которым идет поиск,  проиндексировали ? Ну не может оно в разы быть медленнее

Это сообщение отредактировал(а) Reese - 10.6.2012, 11:08

Только просматривать и редактировать таблицу в фоксе куда удобнее, чем в Excel, который к тому же только 65 с чем-то там тысяч записей поддерживает. В Calc с версии ОО 3.3 поддерживается и больше, но при этом файл на 300000 записей открывается час, т.е. скорость у ОО оставляет желать лучшего.

А, забыл.  Прога на работе, тогда после выходных гляну.

Ну вот, смотря что хранить в такой таблице.

Глянул, кстати. UPDATE с индексированным полем аналогично долго работает.

Ну быть такого не может.
Можете скинуть код с описанием полей и индексов? 

Ну, суть в том, что вторая таблица индексируется по полю (пусть будет INDEXPOLE), далее идёт цикл по первой таблице и запрос типа такого:

так я же писал что update по таблице действительно медленный
SCAN + update - тогда быстро
И еще, какой уровень оптимизации? Что-то я не уверен что в вашем случае UPDATE  будет использовать индекс.

Это сообщение отредактировал(а) Reese - 18.6.2012, 11:39

А при чём здесь scan ? Какая разница, откуда я получаю значение?

При том что join на update-е у фокса медленный. Поэтому Join эмулируем через select ... into cursor и scan c update-ом.
Увы, но это то ли просто особенность фоксового SQL-движка, то ли, вообще, баг.

Это сообщение отредактировал(а) Reese - 18.6.2012, 15:06