> Автор: AleksMed
> А не лучше ли для этого использовать представления или курсор
> адаптер?

Ну или хотя бы просто переносить нужные записив КУРСОР, а не в таблицу.


Posted via ActualForum NNTP Server 1.4

> Автор: Не_проходи_мимо
тоже делаю и с Column меняю в FormDesigner column1 на kod (ну чтоб
получилось grid1.kod.CONTROLSOURCE = "x.kod"), и у меня перестаёт работать,
меняю опять на column1, работает...почему...не понятно..

Если я правильно понял из представленного набора букв, то имя колонки у тебя
(первоначально) "kod"

После запа колонка перестает реагировать на свое имя "kod". Я правильно
понял???


Так вот, это уже неоднократно обсуждалось и обсуждается с периодичностью раз
в неделю, максимум в две. Поиск по ZAP и GRID даст подтверждение.

А суть проблемы такая. Когда грид теряет свой источник (а ZAP есть ничто
иное, как создать таблицу подобной структуры и подменить новой таблицей
исходную) происходит разрушение всех объектов GRID`a, в том числе твоей
колонки "kod".

Потом грид видит новый источник. В пропертях проставлено columnCount=-1,
поэтому грид создает столько новых колонок, сколько столбцов в новом
источнике и сам раздает им имена (column1, column2 ...)

Решается просто:

Перед ZAP делаем


GRID.RecordSource=''

sele X &&(наша таблица)
zap

GRID.RecordSource='X'


&&В этом месте допустимо обращаться к колонкам по ранее определенным именам,
т.к. все наши колонки с их своиствами и методами остались целы


Posted via ActualForum NNTP Server 1.4

> Что лучше, а что хуже это полемический вопрос и модератором может
> рассматриваться, как неявный флуд, по моему(select ...into cursor|table)
> курсор(если Write-Read), ничем не отличается от таблицы, кроме как
> указывается путь в таблице, а курсор этот путь берёт из установки, где
> создавать временные файлы...:-)))

Да, но при этом:
1Не факт, что курсор будет физически записан на диск - а это уже быстрее.

2 при закрытии курсор будет АВТОМАТИЧЕСКИ уничтожен вместе с компаудным
индексом (если такой был создан) - нет необходимости отслеживать его руками

3 Никаких ZAP - просто перезапросили данные в тот же курсор и привет.

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


В связи с этим я с тобой не согласен что в данном случае "Что лучше, а что
хуже это полемический вопрос"!


Posted via ActualForum NNTP Server 1.4

> >1Не факт, что курсор будет физически записан на диск - а это уже
> быстрее
> также не факт, что памяти хватит для записи огромных массивов
> информации в курсор

Вот это не понял. Совершенно. При необходимости Fox сохранит часть курсора
на жеский диск.
Ключевое слово "при необходимости". Как правило выборки в курсор больших
объемов необоснованы. Т.е. курсоры как правило довольно таки небольшие и
запросто висят в памяти не свливаясь на диск.

А если мы еще и выборку делаем в курсор только на чтение (без опции
readwrite)? из одной таблицы и запрос полностью оптимизируем по индексам, то
реальной копии данных не делается. А происходит наложение фильтров на
исходную таблицу.


При этом всем
?dbf() вернет "путь к файлу", даже если файл физически на диске не создан. И
из той же сесии мы можем сказать use (dbf('Мой_Курсор')) in 0 again alias
ttt. И это сработает. курсор будет переоткрыт в другом алиасе (даже если
файл на диск не был сброшен)

> >2 при закрытии курсор будет АВТОМАТИЧЕСКИ уничтожен вместе с
> компаудным
> индексом (если такой был создан) - нет необходимости отслеживать его
> руками
>
> Что то не совсем понятно...есть курсор(select * from bd in cursor)
> index on kod tag kod of put_temprory && всё рано придётся удалять
> индекс принудительно (erase put_temprory.cdx)

Не сказал, что кроме всего прочего индекс должен быть структурным, т.е.
select * from bd into cursor Мой_Курсор
index on kod tag kod

При этом создастся файл
?JUSTPATH(DBF())+justfname(DBF())+'.cdx'

Который при закрытии курсора (естественно при корретном закрытии, а не по
отрубанию питания) будет удален.


> >3 Никаких ZAP - просто перезапросили данные в тот же курсор и
> привет.
> Но всё равно же после перезапроса, придётся перерисовывать грид, так
> как структура таблицы переписывается заново, а в временной таблице она
> остаётся прежней и команда Delete all append from, отработает быстрее, чем
> перезапрос курсора, а если памяти мало, то курсор будет сливаться на
> диск...


Что вы говорите.

Ну давай логически по рассуждаем.
Delete all - это значит что надо пробежаться по всем неудаленным записям и
пометить их на удаление. По сути надо перечитать ВСЮ таблицу, т.к. чтобы
определить удалена запись или нет надо считать метку на удаление для каждой
записи.

append from ... должен проанализировать структуру текущего файла и файла
откуда мы будем заливать данные. Сравнить их. Определить какие поля есть
смысл лить, какие неполучится.

Добавить данные в таблицу и слить все изменения на диск.

Ты действительно думаешь, что создать файл с необходимой структурой и
заполнить его (и все это зачастую в памяти, без сливания на диск) будет
отрабатывать дольше?


> Но может я не прав..:-))
В этой жизни может быть все.


Posted via ActualForum NNTP Server 1.4

> >3 Никаких ZAP - просто перезапросили данные в тот же курсор и
> привет.
> Но всё равно же после перезапроса, придётся перерисовывать грид,

Ну а здесь - да. придется.
Но это не сложно:

GRID.RecordSource=''

sele * from ... where ... into cursor X

GRID.RecordSource='X'

И если названия полей в новом курсоре такие же как и в предыдущем, то даже
controlsourse колонкам переопределять непотребуется.


Posted via ActualForum NNTP Server 1.4

> Автор: Не_проходи_мимо
> Тут различные весовые категории(рейтинги)...:-))), поэтому спорить,
> показывать свою неосведомлённость...я помолчу...:-))

А где ты рейтинг увидел? :-)

Кол-во сообщений еще ни о чем не говорит ;-)


Posted via ActualForum NNTP Server 1.4