Hi bogik!

SQLSETPROP(хендл, "Transactions", 2)
lnRes = SQLEXEC(хендл, "INSERT ... в первую")
* Обработка ошибки
lnRes = SQLEXEC(хендл, "INSERT ... во вторую")
* Обработка ошибки
..... и т.д.
* Если всё в порядке
SQLCOMMIT(хендл)

* Если на каком-то этапе возникла ошибка и транзакцию надо откатить
SQLROLLBACK(хендл)


Вариант с ХП неудобен, если нужно будет передавать в эту ХП очень много
параметров (ну т.е. реально много полей в этих базах, и их все нужно
задавать). - тут придётся как-то мудрить с передачей всего этого массива
данных в ХП (в принципе если ты с XML умеешь обращаться что со стороны
фокса, что со стороны T-SQL то это не проблема).

Posted via ActualForum NNTP Server 1.3

Hi PaulWist!

Речь то шла про ОДНУ ХП - и как туда передать весь этот массив из данных для
10 новых записей - вот где вопрос :)
P.S. Чем лично мне не нравится ХП для элементарных операций (точнее мне до
сих пор никто не показал удовлетворительного решения проблемы).
Имеем таблицу, скажем из 10 полей. Имеем у себя на форме 10 текстбоксов, в
которых мы МОЖЕМ изменить данные этих полей (но МОЖЕМ и не менять!) Как
передать в ХП информацию, чтобы обновить эту самую запись - при этом НЕ
МЕНЯЯ тех полей, к которым в форме не прикасались.
Т.е. со стороны клиента оно понятно - либо автоматом, либо вручную
формируется команда UPDATE f1 = ?value1, f2 = ?value2 ... WHERE ... при этом
в список обновления включаются ТОЛЬКО необходимые мне поля (RV/CAD это умеет
автоматом делать, впрочем зная GETFLDSTATE() можно и "вручную" набрать эту
команду).
Обычно предлагают "по тупому" отказаться от выборочного сохранения - т.е.
если уж меняли 1 поле, то UPDATE надо делать всем 10-ти (используя для
"нетронутых" полей те значения, что попали на клиент в момент извлечения
данных с сервера).
Примерно такая-же проблема с INSERT через ХП. Либо "считают" что NULL в
параметре это признак "пусть работает Default", либо вводят второй набор
параметров (т.е. помимо СОБСТВЕННО значений ещё и флаги - а есть ли значение
или его реально нету! Хотя теоретически можно это и одним дополнительным
параметром сделать - но писанины при этом куча :( )
Также иногда советуют "сделай 2, 3, 10 ... ХП - на разные случаи". Это
конечно выход, но IMHO криво это и нехорошо :(

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> А в чем собственно тут проблемма?!

Ну вот, я же говорил - всегда делают удивлённое выражение лица и говорят что
так программы не пишутся :) Я понимаю, что проще сказать "низя" и забыть...

> Вы что же будете формировать разные команды обновления на сервере при
> изменении разных полей на клиенте?

Да, а почему собственно нет?

> А если этих полей в таблицы 20, а 30

Какая разница - фокс это автоматом позволяет делать, но даже если и вручную,
то особых проблем нет... Со стороны ХП в принципе тоже это возможно - но
только туда ещё надо передавать дополнительные параметры-флаги.

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> Вот это я не понял !? Это как через Pass-Through "автоматом" это
> выполнить?

1) Я не говорил что ИМЕННО SPT+Автомат - т.е. рассматриваются также варианты
RV (в принципе не дружит с ХП), CAD (пока не пробовал плотно - но говорят
что там какая-то беда с параметрами возвращаемыми из ХП)...
2) Ну если уж КОНКРЕТНО SPT+Автомат - то без вопросов делается.
ПРИМЕРНО так (извини, ломает ночью синтаксис проверять - идея думаю и так
понятна)
После чего фокс автоматом будет конструировать INSERT/UPDATE/DELETE
команды - при выполнении TableUpdate() - причём для каждой записи свои -
если там изменилось одно поле - то UPDATE на одно поле - если была вставка и
в её процессе (или после вставки, но до сохранения) изменены лишь 2 поля -
то в Insert попадут только они - оставшиеся поля сервер заполнит
Default-ами - если они конечно есть...

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> Да, это известный метод

Ну и я о том-же :)

> Фактически, вы руками делаете, то, что делает Remote View Designer

Не дизайнер, а сам RV это делает. Т.е. RV это такая "упрощающая" надстройка
над SQLEXEC()... А вот возможность формирования автоматических команд
обновления - это фишка фоксового движка - доступна и для SPT курсоров...

> А если нет Default на поле, то как будет выглядеть команда UPDATE,
> посланная на сервер?

Извини не понял... При чём тут вообще UPDATE - при изменениях записей
никакие Default-ы не срабатывают в принципе. Положим ты ошибся, и имел в
виду команду INSERT всё-же...

Тут есть 2 стороны - фоксовая и серверная.

Если НЕ используется RV, то никаких Default со стороны фокса нет и быть не
может (к сожалению эту "фишку" RV либо вообще невозможно "перенести" на SPT
курсоры, либо я просто не знаю никакого способа).
Если есть Default на стороне фокса -то они срабатывают совершенно аналогично
банальному REPLACE, выполненному сразу после вставки записи в курсор - т.е.
при создании записи сразу производится вычисление этих выражений и
помещаются соответствующие значения в поля курсора. Соответственно потом
(при TABLEUPDATE(), когда и формируются команды обновления базовых таблиц)
фокс при формировании INSERT команды учтёт эти поля как изменённые.
Если Default-а нет - и прямого редактирования поля тоже нет - то фокс просто
не включит данное поле в список полей команды INSERT. Это кстати объясняет
смысл ошибки 1547 - Cannot insert an empty row from a view into its base
table(s) - в таком сценарии фокс формирует некорректную команду типа INSERT
INTO SomeTable () Values () - т.е. с пустыми списками полей.

Если же речь идёт про сторону сервера, и про тамошние Default-ы - то вообще
не понимаю в чём затруднения - это не имеет никакой связи с тем как фокс
формирует команду INSERT - т.е. целиком на совести сервера, как он
прореагирует на INSERT INTO SomeTable (SomeFiledWithDefault) VALUES
(?uValueFromVFPCursor) - я полагаю что нормальный сервер в таком случае
вообще не должен даже пытаться вычислять выражение прописанное в Default -
но если и вычисляет, то по любому должен его потом проигнорировать и
использовать то что указано в команде INSERT... Иначе это уж совершенно
кривой и неадекватный сервер получается :(

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> В любом случае, мне не нравится, что за меня VFP решает, какое поле
> обновить, а какое нет.

Хм, он ничего не решает - он по тупому "исполняет" что ты накодировал или
наводил! Если ты "трогал" поля - они пойдут на сервер - если нет, то и
вопросов нет :)

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

Posted via ActualForum NNTP Server 1.3