Здравствуйте. Есть две таблицы: Spravochnik.dbf  и itog.dbf . Обе таблицы содержат реквизит номер цеха nz. Необходимо сравнить эти две таблицы по реквизиту "номер цеха" (nz) и в случае совпадения заменить реквизит код производства (kpr) массива Spravochnik.dbf  реквизитом код производства (kpr) массива itog.dbf.
Подскажите, пожалуйста, как это можно сделать?

Это сообщение отредактировал(а) Данкинг - 6.6.2012, 15:30

Relation давно уж надо на помойку выбросить


Можно update и по таблице сделать, но толь я не знаю как готовить, то ли он действительно такой медленный

Хм. А апдейтить Spravochnik столько раз, сколько строк в ITOG - это, конечно, лучше? 

Добавлено через 4 минуты и 1 секунду
Да и зачем писать программу, если связь на уровне СУБД устанавливается, т.е. её средствами?

Сколько найдет. Если таких записей в Spravochnik  нет, то и апдейтиться ничего не будет.
Плюс моего решения - не зависит от индекса

Фокс до сих пор поддерживает @say, но это не значит что этим нужно пользоваться

Это сообщение отредактировал(а) Reese - 7.6.2012, 17:02

Но каждый раз будет проходит все записи целиком. Смысл?

Такой же как и в 



В вашем случае тоже обрабатываются все записи.

Просто update понятнее т.к. такой код читать легче чем искать где и  как устанавливали relation, и безопаснее, т.к. в случае сломанного индекса ваш пример во всей таблице Spravochnik поставит в поле kpr одно значение, а в моем - просто отработает медленнее.

 

Не знаю именно самого механизма работы - может быть, там используется какой-то свой внутренний UPDATE. Я про то, что при связывании я делаю всё одной командой - REPLACE - и жду, пока она отработает. Да и в любом случае - зачем писать программу, если можно сделать одной строкой?

Добавлено через 43 секунды

Какого сломанного: я в подобных случаях обычно заново переиндексирую.

Какой же одной ? В одну строчку разница.



А если индекс сломался во время работы replace for ?

Это сообщение отредактировал(а) Reese - 8.6.2012, 13:07

Нет, это просто я написал, как это сделать программно. Но самом фоксе же есть построитель выражений, в том числе и для установки связей. Я всегда его и использую.

Это с чего вдруг? Вот ни разу подобного не было.

1. Этот построитель дал вам тот-же код
2. Использование визардов - зло



При сетевой работе (особенно если программа написана через всякие relation) - слетают регулярно. (Особенно если некоторые пользователи вместо кнопки отмена выдергивают вилку компа)

Это сообщение отредактировал(а) Reese - 8.6.2012, 14:56

Правильно, но я же PRG не писал.

Как правило - да, но не всегда и не везде.

При чём здесь это? А что будет, если прилетят зелёные человечки и унесут системник?

Про выдергивание вилки я конечно несколько утрировал, но я часто встречался с тем что пользователи сбрасывают задачу или жмут reset когда уже нажали "сохранить" и вспомнили что-что-то забыли.

Да при этом вообще таблица не сохранится, что бы с ней ни делали. Именно RELATION или индексы тут ни при чём.

Причем тут сохранение таблицы?
Таблица уже есть. В нее записывают данные при помощи уже написанной программы, а написан процесс сохранения какого нибудь документа при помощи relation, append blank, и replace.
База лежит на сетевом диске, работают два пользователя, и один из них сбрасывает задачу в момент записи данных. Вот тут обычно и происходит слом индексов. (обычно при попытке искать по такому индексу всегда возвращается первая запись). 

В смысле, если открыть таблицу, записать что-нибудь в поле и снять задачу 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

Привет, у меня похожий вопрос, но у меня не получается... 
Есть 2 таблицы (табл1, табл2).
Таблица 1 - это курсор в котором всего 2 столбца.
Таблица 2 - это 2 этих же столбца + ещё 2 других.
Одинаковые столбцы z2 C(8), z3 N(8)
Мне надо, чтобы при удаление/добавление/редактирование, записей в этих столбцах первой таблицы, тоже самое происходило во второй (Обратное не надо). Но остальные столбцы второй таблицы должны остаться без изменения. Если всё совпадает, то ничего не делать.
Вообщем, что бы таблица 2 реагировала на изменение в таблице 1 в общих столбцах, но она не должна терять информацию, которая содержится в других столбцах.

Это каким образом осуществляется?

Ну первая таблица, редактируется кем то периодически, не зависимо от меня. То удалят строку, то добавят новую.
А моя (вторая таблица) должна всё это отражать в себе.

Удаление осуществляется программно или вручную?

Вручную.

Тогда никак: триггеров на фоксе ещё не придумали.

Это сообщение отредактировал(а) Данкинг - 14.10.2012, 20:57

Можно просто по таймеру проверять изменения.
Если таблица лежит в контейнере, то можно и триггер (вообще то они в фоксе есть).

Где они есть: небось только в 9-м фоксе и только для таблиц в составе БД?

В 6-ом точно были. Но как я уже говорил, только для таблиц в контейнере БД.