НадеждаМДобрый вечер. Начала по вашим примерам и примеру отсюда http://kodu.neti.ee/~juri4/vfp60/ca_03_ru.htm пробовать работать с cursoradapter.

В связи с чем возник вопрос: как в CA получить результат работы процедуры?

все тем же родным SQLEXEС - ом?
Зависит от того, что именно возвращает эта процедура и для чего она нужна. Можно ведь в свойстве CursorAdapter.SelectCmd вместо команды Select-SQL написать вызов процедуры. Ну, примерно так


Если процедура MyProc возвращает некую выборку, то результат этой выборки будет отображен как курсор в CursorAdapter.

Хотя, разумеется, если рассматривать некий "общий случай" (сферического коня в вакууме), то, разумеется, придется использовать SQLExec().

CursorAdapter, прежде всего, создавался как "обертка" над командой Select-SQL. Все вокруг этого и крутится. Ну, по простому: сделали выборку записей, изменили записи, сбросили изменений обратно. Если Вам требуется нечто, отличное Select-SQL, то следует подумать, а нужен ли Вам CursorAdapter?

прошелмимоВладимирМ
Хотя, разумеется, если рассматривать некий "общий случай" (сферического коня в вакууме), то, разумеется, придется использовать SQLExec().

CursorAdapter, прежде всего, создавался как "обертка" над командой Select-SQL. Все вокруг этого и крутится. Ну, по простому: сделали выборку записей, изменили записи, сбросили изменений обратно. Если Вам требуется нечто, отличное Select-SQL, то следует подумать, а нужен ли Вам CursorAdapter?
Владимир, чего сказать то пытались?
Рассуждение о бренности бытия и о конях в вакууме?

Когда-же Вы приоритеты измените в сторону абстрактных приемов,
скорости разработки и сопровождения, стаб-ти работы прилож-й
на фокспро?
Так как только появятся абстрактные задачи не привязанные ни к каким конкретным условиям, так сразу...

Когда же Вы поймете, что не существует "абстрактных приемов"? Все приемы очень даже "конкретные". Есть куча сопутствующих требований, которые просто необходимо выполнить. А ради неких "абстрактных приемов" переписывать готовое приложение с нуля никто и никогда не будет.

Вот я и спрашиваю в последнем топике об этих "сопутствующих требованиях". Точнее, зачем вообще на клиенте нужнен результат работы хранимой процедуры? Что с этим результатом предполагается делать? А далее уже можно советовать, подойдет для этих задач CursorAdapter или нет. Стоит ли тянуть весь "паровоз" "абстрактных приемов" ради данной конкретной задачи?

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

НадеждаМ : как в CA получить результат работы процедуры?
ВладимирМ : CursorAdapter.SelectCmd = "Execute MyProc". Но в общем случае SQLExec()
прошелмимо : Когда-же Вы приоритеты измените в сторону абстрактных приемов
???
ВладимирМ : Какие инструменты использовать, зависит от решаемой задачи
прошелмимо : Зачем Вы начали беседу про SQLExec()?
???

Не замечаете странностей в подобной дискуссии? Дальше еще веселее

ВладимирМ : Зависит от того, что именно возвращает эта процедура и для чего она нужна
НадеждаМ : Процедура ... возвращает некую выборку
ВладимирМ : Что с этой выборкой предполагается делать на клиенте?
прошелмимо : Вы и не задавались задачей выяснять, что за выборка, а лили вновь "понос" про обертки и т.д.,
???

Хорошо, уточним про "обертку"

ВладимирМ : CursorAdapter, прежде всего, создавался как "обертка" над командой Select-SQL. Все вокруг этого и крутится. Ну, по простому: сделали выборку записей, изменили записи, сбросили изменений обратно. Если Вам требуется нечто, отличное Select-SQL, то следует подумать, а нужен ли Вам CursorAdapter?
прошелмимо :исп-е курсорадаптера предполагает некоторые принципы и способы написания ХП, вот про это и нужно было намекнуть

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

Если то, что я написал, расходится с Вашим пониманием, того, для чего предназначен CursorAdapter, то где Ваше определение?

Значит, для чего предназначен CursorAdapter Вы не знаете? Не то, что он делает, а для чего его следует использовать? Жаль...

НадеждаМКак удалить запись через CA?

Как применить вот эти свойства?
CursorAdapter.DeleteCmd [ = cCommand ]
CursorAdapter.DeleteCmdDataSourceType [= cDataSourceType]
CursorAdapter.DeleteCmdDataSource [ = cDataSource]
Я попытаюсь объяснить принцип работы с удаленными данными. Думаю, тогда будет проще понять о чем вообще речь.

Итак, основа основ - это запрос к серверу. Команда Select-SQL (CursorAdapter.SelectCmd), пусть и выполняемая внутри хранимой процедуры. Эта команда возвращает некую выборку. Очевидно, что выборка - это не есть исходная таблица. Это другая таблица. Физически другая. Даже расположенная в другом месте.

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

Существуют стандартные команды для модификаций таблиц. Insert-SQL, Update-SQL, Delete-SQL. Следовательно, для выполнения модификации необходимо сформировать соответствующие команды и передать их на сервер. Что необходимо знать, чтобы сформировать эти команды?

1. Имя таблицы, которую будем модифицировать (CursorAdapter.Tables)
2. Поле или набор полей, по которым можно однозначно идентифицировать запись. Так называемое, ключевое поле или первичный ключ (CursorAdapter.KeyFieldList)
3. Какие поля будем модифицировать (CursorAdapter.UpdatableFieldList). Список полей через запятую.
4. Из каких полей выборки (на клиенте) брать информацию для обновления полей на сервере. Так сказать "карта соответствия" (CursorAdapter.UpdateNameList). Какое поле на клиенте какому полю на сервере соответствует. Список пар полей через запятую.

Собственно, это и есть минимально необходимый набор настроек CursorAdapter, чтобы обеспечить автоматическое обновление данных на сервере. В большинстве случаев этого вполне достаточно. Есть еще ряд "тонких" настроек, но значения по-умолчанию этих "тонких" настроек, опять же, в большинстве случаев, как раз те, что нужно.

Объект CursorAdapter при возникновении события сохранения внесенных изменений на основании этих 4 настроек автоматически формирует необходимые команды на модификацию (Insert-SQL, Update-SQL, Delete-SQL) и также автоматически отправляет их на сервер.

Что является этим самым "событием сохранения внесенных изменений"?

В FoxPro есть такое понятие как "буферизация". Если представить исходную выборку (исходную таблицу) как лист бумаги с некоторым текстом, то буферизация - это прозрачная калька, положенная поверх этого листа. Внося изменения, Вы "пишите" эти изменения не сразу на лист, а на эту самую прозрачную кальку. Затем, при возникновении определенного события, происходит перенос изменений с "кальки" на собственно лист.

К чему это все? А к тому, что результат выборки в CursorAdapter всегда находится в режиме оптимистической буферизации. По умолчанию, в режиме оптимистической буферизации строк (3), но может быть переключен в режим оптимистической буферизации таблиц (5). Установить для него режим пессимистической буфериазции или отключить буферизацию совсем - невозможно.

Это значит, что выполняя модификации в курсоре, полученном из CursorAdapter, фактически, Вы модифицируете буфер этого курсора. Как следствие, под событием "сохранения внесенных изменений" понимается процесс "сброса буфера" или, другими словами, переноса изменений из буфера в сам курсор

Сброс буфера происходит

В режиме строковой буферизации

1. При попытке перехода на другую запись
2. При попытке закрытия курсора
3. По команде TableUpdate()

В режиме табличной буферизации только по команде TableUpdate() и никак иначе.

Именно по этой причине, чаще всего, устанавливают режим табличной буферизации (5), чтобы исключить неконтролируемый сброс буфера. Неконтролируемый программистом.

Как следствие, процесс сохранения внесенных изменений запускается командой TableUpdate()

А зачем же тогда сделаны дополнительные свойства вроде CursorAdapter.DeleteCmd, CursorAdapter.InsertCmd, CursorAdapter.UpdateCmd? Ведь команды на модификацию будут сформированы автоматически.

А это сделано на тот случай, если команды, автоматически формируемые CursorAdapter для обновления данных Вас не устраивают. В этом случае при сбросе буфера (по команде TableUpdate()) будут использованы команды, указанные в этих свойствах.

Соответственно, выбор за Вами. Если 4-х стандартных настроек (Tables, KeyFieldList, UpdatableFieldList, UpdateNameList) достаточно для заложенной в приложении логики обновления данных, то этим и следует ограничиться. Если же этого недостаточно, то следует проанализировать насколько логика приложения отличается от логики CursorAdapter и либо полностью подменять эту логику, либо "слегка" корректировать. CursorAdapter предоставляет возможность сделать и то, и другое.