sanya_tir1. Подскажите в чем разница между Local View И Queries?
Query - это "учебник". Пока Вы плохо значете синтаксис Select-SQL им еще можно пользоваться. Но по мере изучения команды Select-SQL надобность в нем пропадает.

Хотя, подправить синтаксис готового Query - элементарно: открываете на редактирование файл Query.qpr и правите как обычный программный код.

MODIFY COMMAND Query.qpr

После внесения изменений, его надо не забыть откомпилировать, чтобы получить файл qpx, который собственно и используется в программе.

А вот Local View - это уже один из основных рабочих инструментов. Основная его "фенька" в том, что изменения внесенные в результат выборки можно (при определенных настройках Local View) автоматически сбросить в исходные таблицы, на основании которых этот View был построен.

Ну, и попутно, у Local View есть еще ряд свойств аналогичных свойствам обычных таблиц FoxPro, чего нет у Query (значения по умолчанию, Rule, задание типов данных)

Еще одно отличие Local View от Query заключается в способе хранения: Query - это обычный файл prg с измененным расширением. А вот Local View физически хранится в контейнере базы данных (DBC) и без него существовать не может!

sanya_tirГде, что предпочтительнее использовать?
Я уже написал, не вижу причин вообще использовать Query.qpr кроме как учебника по команде Select-SQL. Хотя, для быстрого построения собственно кода команды Select-SQL вероятно он годится.

Основной рабочий инструмент - это все-таки Local View. Можно рассматривать Query как некую часть Local View с очень ограниченными возможностями.

sanya_tirИ почему в Local View нельзя написать самому SQL - запрос, только просмотр предлагает,
Начиная с версии VFP8 - можно. В более ранних версиях тоже можно, но уже без дезайнер - только программно через команду CREATE SQL VIEW + DBGetProp()

sanya_tirда еще на мой взгляд не совсем корректно его формируе ....join...join....on...on, хотя по идее надо join..on...join..on
Да, это глюк дезайнера запросов. Опять же был исправлен только в версии VFP8.

В более младших версиях, если связь организована по типу INNER JOIN, то следует переносить условие связи с закладки JOIN на закладку FILTER. Для прочих типов связей - только программная модификация

sanya_tir2. Есть Grid, который выдает таблицу по local view (ost_), хочу сделать, чтобы при щечке по названию поля происходила сортировка по этому полю.... как это сделать? или нужно несколько local view отсортированных по разным полям?
Проблема имеет несколько способов решения:

1) Можно сделать параметрический Local View с параметром в опции ORDER BY. К сожалению, это можно сделать только программно. Через дезайнер придется конструировать вычисляемое поле вроде:

IIF(?param=1,Field1,IIF(?param=2,Field2,Field3))

И устанавливать сортировку по этому полю. Но в таком варианте есть ряд тонкостей.

2) Готовое Local View можно индексировать как обычную таблицу если он находится в режиме буферизации строк (3). Т.е. при щелчке на заголовок Grid либо строишь нужный индексный TAG, либо переключаешся на ранее созданный.

При обновлении Local View по команде Requery() все открытые индексы по этому View также обновяться. При закрытии Local View созданные индексы будут удалены.

lnuа чем тогдо отличаєтся Local View от курсура создонного так:
Select * from db into cursor c1
?
Тем же, чем Local View отличается от Query, поскольку результат Query это собственно и есть такой курсор.

И еще, по курсорам посмотри здесь

Раздел "Курсор"
http://www.foxclub.ru/kb/index.php?sid=24056&aktion=artikel&rubrik=001&id=6&lang=ru

По сути, View - это все тот же Select-SQL и если вопрос стоит только отобрать нужные данные, то вполне подойдет и обычный Select-SQL.

View удобен в тех случаях, когда происходит изменение полученной по Select-SQL выборки и эти изменения надо записать в исходные таблицы.

Также есть некоторый выигрыш в случае, если результат выборки используется в Grid и требуется фильтровать реузльтат по параметру не закрывая форму.

Выигрыш или удобство здесь в том смысле, что надо писать меньше кода. Всю ту же самую функциональность можно реализовать и через Select-SQL, просто придется писать больше кода.

Где хранить данные - в таблицах DBF или на SQL-сервере - это впрос, зависящий от многих факторов. Наиболее важные:

1) Предполагаемый объем базы данных (количество записей на таблицу, общий объем в байтах)
2) Предполагаемое количество пользователей
3) Есть ли деньги на покупку SQL-сервера на предполагаемое количество соединений?

Для таблиц FoxPro оптимальным является не более 20...30 пользователей и размер таблиц не более нескольких миллионов записей. Хотя может работать и с большей нагрузкой.

Физический предел DBF-таблиц - 2ГБ на одну таблицу
Теоретический предел по количеству записей - 1 миллиард (теоретический, потому что раньше наступает предел по объему в байтах, на практике, вряд ли Вы превысите 100 миллионов записей)

Нет. Неправильно.

Разница в том, что если ты используешь Select-SQL, то команду UPDATE ты должен написать .

Если же используешь View, то та же самая команда UPDATE будет подаваться автоматически .

Но сами команды отличаться не будут!

Впрочем, ручаться не могу, поскольку не уверен в логике внутренней реализации команды UPDATE во View. Но, по косвенным признакам, во View дается построчная команда UPDATE (т.е. по одной команде на каждую измененную строчку)

Более того, можно так настроить Select-SQL, что он будет обладать всеми свойствами View. Но для этого надо будет написать несколько настроек через CursorSetProp()

В принципе, можно и так, хотя при таком синтаксисе логичнее вместо команды UPDATE-SQL использовать REPLACE.

FM32YO aka KIDбыл приведен пример:
BEGIN TRANSACTION
LOCATE FOR id=currentId
n=RECNO()
RLOCK()
UPDATE BD SET ...
UNLOCK RECORD n
END TRANSACTION

Возникает вопрос, а нужно ли блокировать запись?
Я попробовал "задержать" транзакцию посредством wait window, при этом, пока транзакция не завершена - никто не может редактировать ту же запись...
Или же блокировка там для чего-то иного?

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

Если запись заблокирована другим пользователем ДО того, как началось обновление, то команда UPDATE-SQL или REPLACE выдадут ошибку 108 или 109, которую надо будет перхватить обработчиком ошибок. Функция RLOCK() сообщение об ошибке не вызовет, хотя, конечно, логичнее окружить ее IF

IF RLOCK()
REPLACE ...
ELSE
ROLLBACK
* Сообщение о невозможности модификации
ENDIF

nk_81Добрый день,Владимир. А можно осветить это подробней? То есть ,хотим получить модифициремый курсор.
Зачем: Есть справочник
Пользователь1 – работает с группой записей А
Пользователь2 – работает с группой записей В
Пользователь3 – работает с группой записей А + В
Необходимо, чтоб пользователь 3 – видел все изменения выполненные
пользователями 1 и 2 ( и обратно соответственно).
В книжках пишут, что это можно сделать с помощью функции SQLSetProp() и CursorSetProp() ,но у меня не получилось.
Это несоклько другая проблема. Модифицируемый курсор здесь никак не поможет.

Если для просмотра пользователем данных Вы используете Select-SQL или Local View (в данном случае это не имеет значения), то на клиентской машине Вы создаете копию данных никак не связанную собственно с исходными данными.

Это значит, что изменения в исходных данных уже никак, никоим образом не будут видны в выборке, полученной по старым данным.

Для того, чтобы увидеть изменения сдланные другими пользователями необходимо повторить выборку. Т.е. заново выполнить запрос.

Для Local View с этой целью используеься специальная функция Requery(). Которая по сути просто выполняет повторный запрос к исходным таблицам. Для курсора полученного по Select-SQL придется заново его выполнить.

На практике, перезапрос может быть организован несколькими способами:

1) Переоткрыть форму - имеет смысл, если для пользователей не имеет принципиального значения немедленное отображение изменений другим польователем

2) Добавить специальную кнопку "Обновить", нажатие которой вызывает принудительное обновление содержимого формы. Фактически - это переоткрытие формы.

3) Добавить системный таймер, который периодически будет запускать обновление содержимого всех открытых форм. Ну, или таймер на каждую форму.