Eprst писал(а) 13. Января 2012 :: 08:09:INSERT INTO tmp_docs('dt','dc')
Так я тоже пробовал - результат один - краш.
Eprst писал(а) 13. Января 2012 :: 08:09:Это раз,
а во-вторых... дальше у тбя брэээд ..не пит, просто брэд
выбрал запись из регистра, имеешь iddoc документа , толкнувшего его и iddoc измерения - Заказ.
Ну а дальше, ты пытаешься фильтрануть его своим условием в иннер джоин, 2 раза - первый раз на документ движения и второй раз на свой заказ.
ну и получаешь бред - твой селект не выберет ни одной строчки, разве что в Заказ не будет тот же документ, что и документ движения регистра, а нафига его туда писать - не ясно, такой регистр, как правило, не закрывается никогда.
Давай еще рвз
INSERT INTO tmp_docs(dt,dc)
SELECT SUBSTR(о.Заказ,1,4), SUBSTR(о.Заказ,5,9)
FROM [Регистр.ВозвратныеОтходы] о
INNER JOIN [Журнал] ж ON ж.iddoc = о.iddoc
AND ((ж.date = :ДатаСвертки0 AND ж.time >= id2str(863990000, 6)) OR (ж.date >= :ДатаСвертки))
INNER JOIN [Журнал] жж ON жж.iddoc = SUBSTR(о.Заказ,5,9)
AND ((жж.date = :ДатаСвертки0 AND жж.time < id2str(863990000, 6)) OR (жж.date < :ДатаСвертки))
Первый джойн, который
ж, проверяет, что дата и время дока удоалетворяют условию
новый документ, а второй джойн, который
жж, - проверяет обратное условие, но по значению реквизита, а не документа.
Может, конечно, стоит уйти от иннеров в сторону лефтов? но мне казалось, что накладывая условие в соединении, я уменьшу количество обрабатываемых строк.... нет?
В результате я хочу получить только те старые документы, на которые есть ссылки в новых докуметах или движениях.
P.S.: На самом деле запрос уже несколько мутировал
SELECT жж.iddocdef || жж.iddoc [Док :Документ]
FROM [Регистр.ВозвратныеОтходы] о
INNER JOIN [Журнал] ж ON ж.iddoc = о.iddoc
AND ((ж.date = :ДатаСвертки0 AND ж.time >= id2str(863990000, 6)) OR (ж.date >= :ДатаСвертки))
INNER JOIN [Журнал] жж ON жж.iddoc = SUBSTR(о.Заказ,5,9)
AND ((жж.date = :ДатаСвертки0 AND жж.time < id2str(863990000, 6)) OR (жж.date < :ДатаСвертки))
GROUP BY жж.iddocdef, жж.iddoc
Сейчас в нем нет инсерта, коль тот крашит 1С, но там стало лучше видно, что я хочу получить.
Вместо GROUP BY пробовал DISTINCT, но так и не смог понять, что быстрее...