Из таблицы Оракд вытаскиваю данные в курсор фокс. Если бы было удаленное представление, то вопроса нет (создаю БД, в ней именованное соединение и удал/представление), но без БД фокса как сделать полученный курсор обновляемым? Для этого делаю:
CURSORSETPROP("Buffering",5)
CURSORSETPROP("AllowSimultaneousFetch",.f.)
CURSORSETPROP("KeyFieldList","objid,kod,date_")
CURSORSETPROP("SendUpdates",.t.)
CURSORSETPROP("Tables","buhg.sxhistorys")
CURSORSETPROP("UpdateType",1)
CURSORSETPROP("WhereType",3)
CURSORSETPROP("UpdatableFieldList","objid,kod,date_,value_")
CURSORSETPROP("UpdateNameList","objid,kod,date_,value_")
CURSORSETPROP("Tables", CURSORGETPROP("Tables")),
- но потом при tableupdate() изменений aerror сообщает о ненахождении оракловской таблицы buhg.sxhistorys. Сам курсор получен по Sqlexec(_screen.handle, <запрос>, <название курсора>), и вот как обновить уд/данные-как использовать этот канал _screen.handle? Кто знает, подскажите.

Для этих целей подойдет CursorAdapter - примеры его использования легко можно найти поиском по форуму.

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

Использовать свойства CursorAdapter-а, не желая использовать сам CursorAdapter...
странное желание

kalina
Из таблицы Оракд вытаскиваю данные в курсор фокс. Если бы было удаленное представление, то вопроса нет (создаю БД, в ней именованное соединение и удал/представление), но без БД фокса как сделать полученный курсор обновляемым? Для этого делаю:
CURSORSETPROP("Buffering",5)
CURSORSETPROP("AllowSimultaneousFetch",.f.)
CURSORSETPROP("KeyFieldList","objid,kod,date_")
CURSORSETPROP("SendUpdates",.t.)
CURSORSETPROP("Tables","buhg.sxhistorys")
CURSORSETPROP("UpdateType",1)
CURSORSETPROP("WhereType",3)
CURSORSETPROP("UpdatableFieldList","objid,kod,date_,value_")
CURSORSETPROP("UpdateNameList","objid,kod,date_,value_")
CURSORSETPROP("Tables", CURSORGETPROP("Tables")),
- но потом при tableupdate() изменений aerror сообщает о ненахождении оракловской таблицы buhg.sxhistorys. Сам курсор получен по Sqlexec(_screen.handle, <запрос>, <название курсора>), и вот как обновить уд/данные-как использовать этот канал _screen.handle? Кто знает, подскажите.

Если не хотите использовать СА, то пишите соответствующий Sql-оператор в виде "строковой переменной" и отправляйте на Oracle-вский сервер для выполнения с помощью Sqlexec(_screen.handle, <SQL-оператор>)

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

kalina
Нет, я хочу с курсором делать что угодно, а потом одной командой tableupdate() сделать соотв. изменения в табл оракл и совсем не думать, с какими записями пришлось возиться, фокс за меня это сделает.

Вот как раз именно для этого и был написан курсорадаптер. Это так трудно понять?

Посмотрите какое описание имет view (например создав view и натравив на него gendbc), надо все их установить, после этого SPT станет работать как view.





Исправлено 1 раз(а). Последнее : PaulWist, 26.07.10 18:16

UpdateNameList должен задаваться ПАРАМИ значений - я точно не помню нужно ли префикс схемы писать (видимо это зависит от того написан он в свойстве Tables или нет - а уж писать ли его там зависит от того к какой схеме идёт соединение - если к той-же самой в какой таблца лежит, то не обязательно, хотя и не помешает), но как-то вот так оно должно выглядеть: "objid buhg.sxhistorys.objid, kod buhg.sxhistorys.kod, date_ buhg.sxhistorys.date_, value_ buhg.sxhistorys.value_"
При этом результат GenDBC никак не поможет в конструировании этого свойства, ЗАТО если корректное удалённое представление открыть и через CURSORGETPROP посмотреть эти свойства - то это будет самое то
P.S. Курсорадаптер по сути эти же самые "параметры" в своих свойствах и держит - так что работая в VFP8 и тем паче в VFP9 наверное стоит всё-же им пользоваться - по крайней мере попробовать

kalina
Нет, я хочу с курсором делать что угодно, а потом одной командой tableupdate() сделать соотв. изменения в табл оракл и совсем не думать, с какими записями пришлось возиться, фокс за меня это сделает. А так как Вы предлагаете, это надо каждый чих с записью курсора оформлять в sqlexec.

Просто "курсор" VFP понятия не имеет, как работать с данными того же ORACLE, какие бы свойства не определили.
Так как отсутствует у такого курсора информация хотя бы о "_screen.handle". У Oracle файлы тоже имеют расширение DBF, но это не dBase-овский файл. Для работы с файлами Oracle необходимы средства ODBC или надо разрабатывать их самостоятельно...

pioner-v
Просто "курсор" VFP понятия не имеет, как работать с данными того же ORACLE, какие бы свойства не определили.
Так как отсутствует у такого курсора информация хотя бы о "_screen.handle".

Курсор же не от святого духа появился

kalina
Из таблицы Оракд вытаскиваю данные в курсор фокс

Думаю, это делалось с помощью SQLEXEC - поэтому фокс прекрасно знает handle = CURSORGETPROP("ConnectHandle")

Цитата:

Вот как раз именно для этого и был написан курсорадаптер. Это так трудно понять?

Сергей, если человек не может понять технологию - это не есть проблема окружающих. Просто КАЖДОМУ - свое время. Кстати, меня это тоже касается ;)

Рома

pioner-v
Просто "курсор" VFP понятия не имеет, как работать с данными того же ORACLE, какие бы свойства не определили.
Так как отсутствует у такого курсора информация хотя бы о "_screen.handle".

Курсор же не от святого духа появился

kalina
Из таблицы Оракд вытаскиваю данные в курсор фокс

Думаю, это делалось с помощью SQLEXEC - поэтому фокс прекрасно знает handle = CURSORGETPROP("ConnectHandle")

Конечно, курсор - не святой дух. Автор вопроса писал, что получает его с помощью ф-ции SQLEXEC.
А информация о "_screen.handle" - я имел ввиду, что курсор не знает как самому направить данные обратно.
У него нет свойств подобных(если СA1=CREATEOBJECT('CursorAdapter')):
CA1.DataSource=_screen.handle
CA1.DataSourceType='ODBC'



Исправлено 2 раз(а). Последнее : pioner-v, 27.07.10 00:32

Огромное спасибо за комментарии! "курсор не знает как самому направить данные обратно"-самое смешное, что cursorgethandle=1 (под рукой нет правильного синтаксиса), но почему, если не пользуется этим? Я задал вопрос из-за искушения- ведь в помощи однозначно написано, что курсор ОДБС может быть обновляемым! И близко не упоминался СА! Какое-то 1 или 2 простых доп.действий- и самолет взлетел бы, но все оказалось сном (сомнамбулы).

kalina
в помощи однозначно написано, что курсор ОДБС может быть обновляемым!

А курсор из нативных таблиц может быть необновляемым. Ну то есть ReadOnly. И еще есть опция Readwrite для таких курсоров? Противоречия не видите? Может под словом "обновляемый" в документации понимается несколько не то, что понимаете Вы?

Неужели не заработало? Давай тогда ДОСЛОВНО ошибку, которую AERROR() кажет после неудачного TABLEUPDATE()-а - причём если она odbc-ная, то все поля массива показывай. Да и сам текст запроса и строку соединения (точнее имя юзера/схемы из неё) было бы неплохо видеть - вдруг где опечатка...
У меня давно и успешно система работает именно по такой схеме - для курсора полученного через SQLEXEC() устанавливаются указанные свойства, после чего вносимые в него изменения по TABLEUPDATE() отправляются обратно на сервер. Удалённое представление используется лишь как своеобразное "хранилище" текста запроса (точнее даже базовой части текста запроса, т.к. часть WHERE подставляется динамически), и соответствующих настроек.
P.S. Исторически пошло так - с 7-ки ещё, где никаких тебе курсорадаптеров не было... Естественно что в настоящее время это не актуально как раз по той причине что курсорадаптер всё это хозяйство успешно заменяет

2 Сергей
Есть такая статья в хелпе "Updating Remote Data with SQL Pass-Through" - и по мне, так вполне очевидно, что автор вопроса исходил именно из неё, и понимал под "обновляемостью" именно то, о чём написано в этой статье. Пример его кода говорит об этом. Просто там нет полноценного примера, и потому сложно самому всё правильно настроить. При этом более-менее нормальное описание синтаксиса этой настройки (как задавать пары) есть лишь в хелпе по одноименному свойству курсорадаптера - тогда как в хелпе по свойству курсора (по функциям CursorSet/GetProp) написана ересь: во-первых не указано что должны быть пары локальное_пробел_удалённое (даже "наоборот" они написаны), во-вторых какая-то глупая ремарка про "имена недопустимые для фокспро" - тогда как заданы должны быть пары имён для ВСЕХ обновляемых и ключевых полей...

Игорь, к сож. у меня нет никакого кода под рукой, к инету случайный доступ, да, получилось, сначала с СА, потом и без него по аналогии, причем для себя не смог объяснить казус: когда курсор получен из одной таблицы, то таблеапдейт работает нормально со вторым параметром фальш, а если из больше одной таблицы, но обновляются поля одной, то только если второй параметр - истина, я то думал, что он просто забивает изменения параллельного пользователя, и к истине во втором параметре пришел случайно. Но работает, и хорошо.

Обычно для "многогтабличных" настраивают свойства обновления СТРОГО для одной обновляемой таблицы - несколько обновить не получится. а фокс может попытаться - особенно если в tables их указать несколько.
Ещё один важный нюанс - varchar поля. т.к. на сервере там скажем "12" а на клиенте в 8-м фоксе будет "12__" - ну т.е. добьёт пробелами - то при попытке "обычного" (WhereType в режиме key_and_modified или key_and_modifiable) tableupdate будет зафиксирован конфликт (фокс считает что якобы на серере тоже было с пробелами в хвосте поле, а реально оно не так) - и тут единственный выход "писать принудительно" - т.е. сравнивать только по ключевому полю - а вот если среди ключевых полей есть варчары - то тогда дело швах - настроить таким способом обновление не выйдет - только руками генерить команды апдейта... CAD кстати частично помогает тут - через его ConversionFunc можно отсечь хвостовые пробелы, но не на все 100% - только в 9-ке используя со стороны фокса varchar поля получается более-менее нормально работать.