Галактика в вопросах и ответах

Кто знает как сделать UPDATE по таблице при наложении ограничений из другой табл.

Например: Модифицируем BaseFin при условии, что тип платежного документа (бух.справки) PlPor.TIdK=10019

При формировании в Update подцепки как в Selec, а именно:

where ((plpor.nrec/==basefin.cplpor and 10019==plpor.tidk))

изменяются записи с BaseFin.cPlPor = 0, а не те которые есть в базе.

В LOT на конвертор нашел запись вида:
UPDATE SPSTEP
WHERE (( SPSTEP.cStepDoc == StepDoc.nRec AND
StepDoc.cBaseDoc == BaseDoc.nRec AND
WORD(1000)+BaseDoc.VidDoc == SpDocNal.TipDoc AND
SPSTEP.nRec /== SpDocNal.cSpDoc ))
SET SPSTEP.cGrNal := SpDocNal.cGrNal;

которая одним своим видом приводит в замешательство и полностью перечеркивает Гал.доку по формированию подцепок...

Из Lot так не получится.Я с этим давным давно столкнулся.Нельзя так проапдейтить таблицу, нее являющейся корневой в подцепках.Обрати внимание, что в галактическом lot-е именно spstep - корневая.
По всей видимости это особенности галактического SQL.
Вот такие дела.Есть два выхода.
1.Бежать по basefin-у с таким же tidkgal.Что у plpor,что у basefin - tidkgal д.б. одинаковы.Иначе - проверку таблиц запускай.

2.Такой простенький update можно организовать c помощью VIp или fcom

В третьих если кто скажет как это из lot можно организовать буду сильно удивлен

точно.
запросом можно проапдейтить только корневую таблицу.

только вот я не понял почему запрос в конверторном лоте приводит в замешательство?

а так не получится?:
where ((basefin.cplpor/==plpor.nrec and 10019==plpor.tidk))

О замешательстве...
Не в плане дискуссии о док-ции, которая по моему мнению составленна таким образом, что не способствует нахождению ответов, а есть "отмазкой" для ее составителей.
Итак из нее самой:
п.2.5 Операторы модификации данных
...
Если CURRENT отсутствует, то модификация производится для всех записей, удовлетворяющих ограничениям из WHERE.
...
Однако ни слова про то, что WHERE не соответствует описанию приведенному выше в разделе 2.4.4.

where ((basefin.cplpor/==plpor.nrec and 10019==plpor.tidk))
хочет индекс NREC+TIDK.

Может здесь как-то ROOT прикрутить или сделать в 2-а этапа через PICKи?

VIP и FCOM конечно помогут. Но если такие действия нужно вставить в скрипт?

а чем вас такой вариант не устраивает:
where(( 10019 == basefin.tipDoc and basefin.cplpor /== plpor.nRec )) ?

basefin.tipDoc = plpor.tidk в данном случае, на сколько я помню...

при использвании update Root во Where не прокатывает.

Так то оно пройдет, но все-таки, Peter Gunn, вопрос первоночальный не в этом состоял - как в lot умудриться проапдейтить некорневую таблицу

Народ, а что может помешать выйти за рамки двойных скобок и попробовать:
update basefin where ((plpor.nrec/==basefin.cplpor))and plpor.tidk = 10019 set basefin.TidkGal:=___;

Да вообщем-то ничего...тока так тоже не будет работать

Нда.., действительно не выходит. Выходит только так:
update
basefin
where ((basefin.cplpor == plpor.nrec))and plpor.tidk = WORD('10')
set basefin.TidkGal:=10;

С BaseFin получилось хотя и медленно за счет перебора всего PlPor.
А вот как быть с SoprHoz, где нет прямой ссылки на PlPor, а только в нагрузку справа с TIPDOC (индекс SOPRHOZ02).

И вообще предлагаю обсудить возможность выработки общего метода...

where ((basefin.cplpor/==plpor.nrec and 10019==plpor.tidk))
хочет индекс NREC+TIDK.

ну это совсем просто:
where ((basefin.cplpor/==plpor.nrec and 10019==plpor.tidk (NoIndex)))

просто по таблицам индексы не поню, а лазить ломает

Проверил...

where ((basefin.cplpor/==plpor.nrec and 10019==plpor.tidk(NoIndex)))

Работает, но медленее чем

where ((basefin.cplpor/==plpor.nrec and (plpor.tidk=10019))

Предлагаю вернуться к вопросу о SoprHoz