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

День добрый! Есть такой вопрос: нужно сделать сортировку по подразделениям, откуда идет отгрузка (накладные на внутреннее перемещение) в такой таблице:
.create view t as select * from
katsopr, synonym katpodr otkuda,
synonym katpodr kuda
where (( word(600) == katsopr.vidsopr
and katsopr.cpodrfrom == otkuda.nrec
and katsopr.cpodrto == kuda.nrec))
order by ????;
Буду очень признательна тем, кто поможет

order by otkuda.nrec, например.

не работает - пустой отчет выдает
(без сортировки отчет не пустой)

Не может быть такого...набири в sql запрос просто без create view..

select katsopr.dsopr,katsopr.nsopr,
otkuda.name,kuda.name
from
katsopr,
katpodr otkuda,
katpodr kuda
where (( word(600) == katsopr.vidsopr
and katsopr.cpodrfrom == otkuda.nrec
and katsopr.cpodrto == kuda.nrec))
order by otkuda.nrec;

Индексов таких нет в БД по Катsopr..поэтому отчет будет выполняться только на внешней выгрузки и очень долго. У меня была такая задача - сделать Товарно-денежный отчет по выбранному подразделению. Если накладные оприходованы все,то можно пойди от складских ордеров. А легче использовать готовые отчеты Галактики.
Взять отчет в складе - сравнение проводок и ордеров к ним, изменить форму под то, что надо и получите по выбранному подразделению отчет по движению всему. Если нужны только накладные определенного вида - отфильтруйте их в отчете.

С уважением, Игорь

Насчет долго -не совсем правда.
Вполне быстро выполняется ,если написано на FCOM-E.
У меня данный select из всей БД
по сегод. день отрабатывает примерно за 2 минуты, учитывая количесвто накладных около 57000 записей по внешней выгрузке, а если ограничить датами , то время запроса значительно уменьшается..

Есть такая партия ... тьфу ты, индекс то есть... который помочь может ...
но ему нужен будет период за который выбирать данные ...

попробуй так ...

.form testform
.ard
.var
dateend:date;
datebegin:date;
.endvar
.create view t as select * from
katsopr(KATSOPR04),katpodr, synonym katpodr otkuda,
synonym katpodr kuda
where
((
datebegin<<katsopr.dopr
and katsopr.cpodrfrom == otkuda.nrec and katsopr.cpodrto == kuda.nrec
))
and dateend>katsopr.dopr and
katpodr.nrec=katsopr.cpodrfrom and
600=katsopr.vidsopr order by katpodr.name;

.fields
katpodr.name katsopr.dopr katsopr.nsopr kuda.name
.endfields
.begin
datebegin:=date(1,month(cur_date)-3,year(cur_date));
dateend:=cur_date;
end.
Откуда Дата Номер Куда
.{ table t
^ ^ ^ ^
.}
.endform

не фонтан в смысле быстродействия , из 55 тыщ записей в katsopr за последние полгода выбрала 1200 по виду 600 за 35 секунд ...
с датами можно чего-нить и похимичить :диалог выбора вызвать или еще чего такого

Ден

Вопрос не сколько у Вас вообще накладных, а сколько 600-тых (накладных на внутренне перемещение), т.к. тут срабатывает индекс. Выгрузка идет уже с учетом этого индекса.
Поэтому все зависит от того, каких накладных сколько. Насчет..FCOM или что другое - это безразлично, т.к. все равно в системе работает один и тот же интерпретатор, вызываемый из разных средств.

В связи типом накладной 600 запрос Туманова О. будет еще менее эффективным, т.к. хотя он ограничивает по датам, но зато перебирает все типы накладных. Если БД за много лет, то может и будет эффективнее, а если нет, то навряд-ли. Отлаживать эффективность когда нет индексов невозможно ВООБЩЕ (без привязки к конкретному предприятию) и говорить о времени не применительно к конкретной БД. Надо знать сколько складов вообще, какое движение (интерсивность), какое соотношение количества накладных по типам в Катsopr и много другое. Зная все это можно постоить эффективный запрос. А если не знать, то все разговоры о времени не очень полезны.

С уважением, Игорь

2 NINA

select * from
katsopr, synonym katpodr otkuda,
synonym katpodr kuda
where (( word(600) == katsopr.vidsopr
and katsopr.cpodrfrom == otkuda.nrec
and katsopr.cpodrto == kuda.nrec))
order external by otkuda.name?;

Игорь, а я и выгребал по 600 накладным. Вот только что еще раз выполнил энтот запрос :
57000 записей за 65 секунд по внешней выгрузке - это более чем удовлетворительно.Если же ограничить датами (что обычно и делается) время выполнения на порядок уменьшится.
Весь вопрос - когда становится критичным выполнение отчета.У каждого свои критерии на этот счет.(вот было бы 20 минут или 2 минуты с индексом, то да, стоит задуматься над оптимизацией).Но в данном случае , по мне, эта не та ситуация из за которой следует что-то еще копать.
Кстати Nina чего-то не говорит - получилось ли что ??

Привет всем еще раз, огромное спасибо всем вам! Но я спрвилась своими методами, проще говоря пришлось переписать всю фрмку Сорри, что только сейчас отвечаю. Если интересуют подробности, то аськой или мылом... но там ИМХО нет ничего особо интересного для вас, там все гораздо проще оказалось Пасиба

Ден и вы правы, просто order by otkuda.name (nrec, kod и пр.) работает, приношу извинения.

Ден, да я не спорю и запрос нормальный. Должен работать нормально.
Только не уверен, что если ввести ограничения по датам еще в нем, то это даст какой-то эффект. Теоретически не должно дать. Индекса нет и значит все равно все записи будут перебираться.

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

Так что правы Вы..часто не следует так вот наворачивать проблему. У Вас подход правильнее моего...Надо мне отвыкать

С уважением, Игорь

И все-таки время выполнения заметно уменьшается, Игорь, хотя теоретически вроде не должно (соглачен с Вами) такого быть..
Еще вот заметил, что обычно при попытке компиляции Sql-скрипта без нужного индекса выдается предупреждение, а здесь как то сразу выгрузка начинается. Мож тут какие ньюансу есть .`) ???

Игорь откуда пессимизм?
По поводу критичности выполнения..
Поддерживаю на 100%