powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
57 сообщений из 57, показаны все 3 страниц
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246217
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Помогите пожалуйста с решением задачи.

Имеем таблицы tblElement и tblNodeElement см. на схеме ниже. (схема взята из примера приведенного Программистом-Любителем, т.к. немного попроще чем подобная схема в моей базе.
Необходимо вывести суммарную норму расхода запчастей (при ремонте) и суммарное их количество в (корневом) изделии. Расчет нормы расхода и количества в изделии, как мне кажется, производится по следующим алгоритмам:
Норма расхода запчасти на изделие:
Низд = ((([НсбN] *[ КсбN])*[KсбN-1]+[НсбN-1]*[КсбN-1])*[KсбN-2]+ [НсбN-2]*[КсбN-2])…..
Количество запчастей в (корневом) изделии:
KЗизд =( ([KЗсбN]*[KсбN-1]+[КЗсбN-1])*[КсбN-2]+[КЗсбN-2])*КсбN-3+……
Где
Низд – норма расхода запчасти на изделие
КЗизд – суммарное количество запчасти в изделии
Ксб – количество сборок
N – количество уровней вложенности (изделие-сборка-подсборка-подподсборка…)
И соответственно
НсбN, КЗсбN, KсбN – норма, количество запчастей, количество подсборок самого нижнего уровня [НсбN-1], [КЗсбN-1], [КсбN-1] –норма, количество запчастей, количество подсборок на уровень выше.
На выходе должна получиться таблица с полями
iElementID_Root, iElementID, decNorm, decCnt
где для каждой запчасти корневого изделия должна быть указана (суммарная) норма расхода на ремонт, и общее количество запчастей на изделие.
Изначально вся схема сделана в MS_SQL Server, но так как вся работа с базой идет через Access (ADP проект Access 2003 + MS_SQL Server 2008 R2), то пишу в этой ветке.
Задача, по моему, сложная используется рекурсивный запрос (ниже приведу), на готовые решения не надеюсь, подскажите куда «бить головой» и хоть примерный ход решения.

...вообще описание сложное получилось, в жизни несколько попроще. Уровней вложенности у меня на текущий момент всего два и отчасти получалось решить эту задачку простой группировкой, не исключено впрочем увеличение количества уровней в будущем до максимум 5, поэтому привел "идеальный" алгоритм по которому их может быть сколько угодно. ... Правда как реализовать этот алгоритм через DML не представляю
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246218
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246220
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я же уже давал в этом форуме пример запроса вычисляющего рекурсивно полное количество по всему дереву от корня до последних листиков ? Примеров рекурсивных запросов t-sql куча, приспособить под себя несложно.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246222
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рекурсивный запрос. Опять же взял пример П-Л, т.к. в моем варианте черт ногу сломит. (
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
WITH NodeLevel
(
   iNodeElementID, iElementID_Root, iElementID_Parent, iElementID, 
   sElementCode, sElementName
) 
AS 
(

   -- Первый корневой уровень
   SELECT 
      nd.iNodeElementID,               -- ID узла
      iElementID_Root = nd.iElementID, -- ID изделия, самого верхнего элемента
      nd.iElementID_Parent,            -- ID элемента более верхнего уровня (более крупная сборка), NULL для изделий
      nd.iElementID,                   -- ID элемента (ID самого изделия)
      nd.sElementCode,                 -- Код элемента
      nd.sElementName                  -- Название элемента
   FROM dbo.qrNodeElement nd 
   WHERE nd.iElementID_Parent IS NULL -- Условие отбора самых верхних изделий
   
   -- Все последующие уровни
   UNION ALL SELECT 
      nd.iNodeElementID,               -- ID узла
      NodeLevel.iElementID_Root,       -- ID изделия, самого верхнего элемента
      nd.iElementID_Parent,            -- ID элемента более верхнего уровня (более крупная сборка)
      nd.iElementID,                   -- ID включаемого элемента (более мелкая сборка или деталь) 
      nd.sElementCode,                 -- Код элемента
      nd.sElementName                  -- Название элемента
   FROM 
      dbo.qrNodeElement nd 
      JOIN NodeLevel ON nd.iElementID_Parent = NodeLevel.iElementID
)
SELECT 
   iNodeElementID,
   iElementID_Root,
   iElementID_Parent, 
   iElementID, 
   sElementCode, 
   sElementName
FROM NodeLevel
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246224
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да П-Л все верно, очень хорошо что сразу на тебя "нарвался" просто не понимаю как приспособить этот рекурсивный запрос именно под вычисление норм и количеств. Само по себе то все это работает на ура, дерево строится, все что нужно выдает, а вот итоговые расчеты ... тут загвоздка
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246225
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
WITH NodeLevel
(
   iNodeElementID, iElementID_Root, iElementID_Parent, iElementID, 
   sElementCode, sElementName, sNodeElementAddress, nNodeElementCount
) 
AS 
(

   -- Первый корневой уровень
   SELECT 
      nd.iNodeElementID,               -- ID узла
      iElementID_Root = nd.iElementID, -- ID изделия, самого верхнего элемента
      nd.iElementID_Parent,            -- ID элемента
      nd.iElementID,                   -- ID элемента
      nd.sElementCode,                 -- Код элемента
      nd.sElementName,                 -- Название элемента
      sNodeElementAddress = '#' + CAST(nd.iElementID AS VARCHAR(MAX)) + '#', 
      ISNULL(nd.nNodeElementCount, 0)
   FROM dbo.qrNodeElement nd 
   WHERE NOT EXISTS(SELECT * FROM dbo.NodeElement nd2 WHERE nd2.iElementID = nd.iElementID_Parent)
   
   -- Все последующие уровни
   UNION ALL SELECT 
      nd.iNodeElementID,               -- ID узла
      NodeLevel.iElementID_Root,       -- ID изделия, самого верхнего элемента
      nd.iElementID_Parent,            -- ID элемента
      nd.iElementID,                   -- ID элемента
      nd.sElementCode,                 -- Код элемента
      nd.sElementName,                 -- Название элемента
      NodeLevel.sNodeElementAddress + CAST(nd.iElementID AS VARCHAR(MAX)) + '#', 
      nNodeElementCount = ISNULL(NodeLevel.nNodeElementCount, 0) * ISNULL(nd.nNodeElementCount, 0)
   FROM 
      dbo.qrNodeElement nd 
      JOIN NodeLevel ON nd.iElementID_Parent = NodeLevel.iElementID
)
SELECT 
   iNodeElementID,
   iElementID_Root,
   iElementID_Parent, 
   iElementID, 
   sElementCode, 
   sElementName, 
   sNodeElementAddress, 
   nNodeElementCount 
FROM NodeLevel


Обратите внимание столбец nNodeElementCount считает количество листиков на ветке дерева перемножая предыдущие узлы
iNodeElementIDiElementID_RootiElementID_ParentiElementIDsElementCodesElementNamesNodeElementAddressnNodeElementCount113131.140Ручка#13#12131331.123Колпачок#13#3#131313121.132Корпус#13#12#2413124 1.124Корпус-трубка#13#12#4#65131251.125Заглушка#13#12#5#8613126 1.126Конус#13#12#6#271312111.131Стержень#13#12#11#2813117 1.127Оболочка#13#12#11#7#691311101.130Пишущий механизм#13#12#11#10#810131081.128Шарик#13#12#11#10#8#811131091.129Обод#13#12#11#10#9#81414142.56868Изжелие2.56868 #14#017141417aaaaaaaaaa#14#17#018141418bbbbbbbbbb#14#18#0
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246227
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я помню был вариант с адресами, по которым вроде как легко прослеживалась каждая деталь, где стоит и сколько их, но потом от адресов мы ушли. Все только через этот запрос. Сейчас об адресах вспоминать поздно, так как наработано уже весьма не мало.
Плюс тут еще сложность что вычисляется не только количество деталей, но и их нормы расхода, а они вычисляются немного по другому алгоритму. В общем на выходе получается "швах". Я делал расчет группировкой на основе данных полученных рекурсивным запросом. Возникли проблемы при некоторых условиях. ... Блин. Не хочу еще усложнять, если эти условия описывать это довольно много добавить надо к исходному посту.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246229
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Во-во. Про эти адреса и писал :( У меня их нет.
Надо прочитать, подумать.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246235
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чую, надо шаманить с этим:
Код: sql
1.
nNodeElementCount = ISNULL(NodeLevel.nNodeElementCount, 0) * ISNULL(nd.nNodeElementCount, 0)



Спасибо П-Л!
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246237
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот я добавил поле норма расхода и посчитал его для каждого листика дерева. Т.е. для каждого листика берется его путь наверх, в каждом узле сколько-то веток, это число умножается на норму расхода для данной ветки.

dbNodeElementNorma10000824548181633625614081024

Формула абсолютно тривиальная, точно такая же как и рсачет количества.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
CREATE VIEW dbo.qrElementTree AS

WITH NodeLevel
(
   iNodeElementID, iElementID_Root, iElementID_Parent, iElementID, 
   sElementCode, sElementName, sNodeElementAddress, nNodeElementCount, dbNodeElementNorma
) 
AS 
(

   -- Первый корневой уровень
   SELECT 
      nd.iNodeElementID,               -- ID узла
      iElementID_Root = nd.iElementID, -- ID изделия, самого верхнего элемента
      nd.iElementID_Parent,            -- ID элемента
      nd.iElementID,                   -- ID элемента
      nd.sElementCode,                 -- Код элемента
      nd.sElementName,                 -- Название элемента
      sNodeElementAddress = '#' + CAST(nd.iElementID AS VARCHAR(MAX)) + '#', 
      ISNULL(nd.nNodeElementCount, 0),
      CAST(ISNULL(nd.dbNodeElementNorma,1) * ISNULL(nd.nNodeElementCount, 0) AS DOUBLE PRECISION)
   FROM dbo.qrNodeElement nd 
   WHERE NOT EXISTS(SELECT * FROM dbo.NodeElement nd2 WHERE nd2.iElementID = nd.iElementID_Parent)
   
   -- Все последующие уровни
   UNION ALL SELECT 
      nd.iNodeElementID,               -- ID узла
      NodeLevel.iElementID_Root,       -- ID изделия, самого верхнего элемента
      nd.iElementID_Parent,            -- ID элемента
      nd.iElementID,                   -- ID элемента
      nd.sElementCode,                 -- Код элемента
      nd.sElementName,                 -- Название элемента
      NodeLevel.sNodeElementAddress + CAST(nd.iElementID AS VARCHAR(MAX)) + '#', 
      nNodeElementCount = ISNULL(NodeLevel.nNodeElementCount, 0) * ISNULL(nd.nNodeElementCount, 0),
      dbNodeElementNorma = CAST(ISNULL(NodeLevel.dbNodeElementNorma, 1.0) * ISNULL(nd.dbNodeElementNorma, 1.0) * ISNULL(nd.nNodeElementCount, 0) AS DOUBLE PRECISION)
   FROM 
      dbo.qrNodeElement nd 
      JOIN NodeLevel ON nd.iElementID_Parent = NodeLevel.iElementID
)
SELECT 
   iNodeElementID,
   iElementID_Root,
   iElementID_Parent, 
   iElementID, 
   sElementCode, 
   sElementName, 
   sNodeElementAddress, 
   nNodeElementCount,
   dbNodeElementNorma
FROM NodeLevel
--------------------------------------------------------------------------------
GO
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246238
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
1
0
0
0
0,8
2
4,5
4,8
1,8
1,6
3,36
2,56
1,408
1,024

Запятые плохо встали.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246243
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Суть понятна, попробую реализовать это в моем "кривом" коде.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246245
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ага. Перемножайте на каждом узле кол-во штук на норму расхода. Должно быть несложно.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246250
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изерлонер...попробую реализовать это в моем "кривом" коде.
вот правда, код кривой до жути. Но если бы ты в свое время не направил, все было бы ишшо хуже. А кривости имеют вполне объективные причины, жуткая загрузка текущей работой (при этом использую то что уже наработал с базой, что с одной стороны где-то ускоряет процесс, но при этом закрепляет текущее состояние базы, так как внести серьезное изменение пусть даже в кривую, но используемую в работе базу - чревато...) и отсутствие опыта. По тихоньку ситуация исправляется, надеюсь время у меня еще есть. Было бы обидно уйти с этого места работы так и не реализовав всего вложенного труда и того потенциала что дает эта база. ... Блин. За идею работаю! Не так страшно работу потерять и зарплату (другую найду) как все эти наработки.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246769
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
П-Л, в общем где-то я перемудрил со схемой данных изначально. Не получается у меня. Подозреваю что из-за схемы.
Ниже представлен кусок схемы данных. Проблема в том что данные о количестве деталей на изделие и нормы расхода разнесены по разным таблицам - выделил красным. Просто нету самой по себе нормы расхода на ремонт изделия (она есть как-бэ, и даже у меня в схеме отражена, но этот столбец фактически мной не используется, и вообще это не совсем верно, потому что норма на изделие зависит от частных норм по цехам, так что по идее это излишний столбец, данные в котором должны соответствовать сумме всех цеховых норм) Есть норма расхода запчастей на изделие В КОНКРЕТНОМ ЦЕХЕ и именно она важна. От нее плясать надо, именно этому служит таблица tblZehNorm.
Твой код рекурсивного запроса я использую не на одной таблице (tblNodeElement), а на запросе включающем в себя фактически все таблицы схемы (из которых сейчас важны именно две представленные таблицы). Рекурсивный запрос позволяет строить иерархическую схему входимости изделий и в принципе корректно показывает все данные. Однако когда я пытаюсь получить итоговые данные - суммарные нормы, суммарное количество на изделие... Суммарное количество увеличивается кратно количеству цехов в которых ставится запчасть на это изделие. (оно и понятно, просто исходя из схемы данных). Т.е. запрос собирает все данные по запчасти на изделии, суммирует их корректно... а затем умножает в два, в три и т.д. (по количеству цехов) раза. С нормами дело обстоит несколько лучше. Я могу получить корректные данные по нормам сделав запрос на группировку по данным рекурсивного запроса, однако непосредственно в самом рекурсивном запросе вывести эти данные пока не получается, где-то безнадежно туплю, все время норма получается равной нулю (ну или единице исходя из
Код: vbnet
1.
ISNULL(decZehNorm, 1)

)
В общем у меня два вопроса.
Первое, как бы ты организовал учет (хотя учет здесь не совсем корректное слово, это скорее просто такой справочник нормативов, учет ведется в другом месте и не мной), если его необходимо вести по отдельным подразделениям (цехам) и в целом по изделию. Годится ли представленная ниже схема для этого? По мне так схема годится, просто исходя из того что она себя уже достаточно показала, и больших проблем не было, но сейчас после нескольких ударов головой ап стену, у меня сомнения возникли
Второе, если твой вариант прилично отличается от представленного, то что вообще возможно сделать что бы поправить ситуацию и при этом не пришлось все переделывать с нуля? Рано или поздно все равно видимо придется, когда приобрету достаточно опыта и буду совершенно четко понимать что и как должно быть, и что вообще нужно
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246771
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЗЫ: слово Replaseable вычеркнул нафинг, что бы не путало. По факту использования нету там никакого Replaseable, я эту возможность внес в схему данных (при том здорово ее усложнив), но пока она остается "мертвой" и не используется.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246778
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изерлонер что вообще возможно сделать что бы поправить ситуацию и при этом не пришлось все переделывать с нуля?
Если не трогать схему, то я пока как вариант вижу создание отдельных "хитрых" запросов, на основе результатов рекурсивного, отдельно выводящих данные по количеству запчастей в изделии, по нормам (это по сути уже есть, только чуть доработать), и наконец общего запроса объединяющего все эти отдельные данные. Минус - по моему горькому опыту работает подобный подход весьма медленно.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246789
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЗЫ2: пусть тебя не смущают поля strPodrasdel.. iPodrasdel.. и иже с ними. Схема так или иначе постоянно улучшается дорабатывается, а хвосты остаются, либо по причине того что на них были сделаны запросы и они пока не исправлены, либо тупо по нехватке времени и опасения поломать что хоть криво, но работает.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246808
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изерлонери вообще это не совсем верно, потому что норма на изделие зависит от частных норм по цехам
ЗЫ_3: я часто путаю что от чего зависит, потому что на практике и в теории разные подходы. В литературе (руководства по ремонту, альбомы и перечни) естественно нету никаких цехов. Норма всегда дается на ремонт изделия. Однако на практике каждому цеху на ремонт изделия назначается своя норма, в сумме это все конечно должно соответствовать. Так что очень не просто взять и выкинуть какие-то столбцы. Впрочем к сожалению нормы в литературе даются далеко не на весь перечень запчастей и материалов, на большую часть это все устанавливается исходя из практики ремонта пальцем в потолок и статистики. Для норм имеющих основание в ремонтной документации введен столбец decNodeElementNormObosn и столбцы strObosnovanie и strDopObosnovanie в которых прописывается ссылка на документ. Опять же на деле пока это все только задел на будущее, и не имеет сейчас критического значения.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246842
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У тебя задача достаточно объемная, надо опять начинать от печки. Я, честно, уже подзабыл - ты как-то раньше давал более-менее подробные объяснения про свою систему. То, что у тебя некая каша из цехов/ремонтов, у меня осталось четкое впечатление. Сказать какие конкретно таблицы и как именно надо реорганизовать, увы, не смогу - надо снова погрузиться в твою задачку.

Может ты бы где-то типа в гугль докс завел описание бизнес-требований и функциональных требований, чтобы к ним можно было обращаться и совместно редактировать, а ? Я бы с радостью помог, но исходной информации маловато.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246973
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Написать можно, только по опыту предыдущих попыток, я боюсь завязнуть в не существенных мелочах, а так же в своих хотелках. Всё не так уж и сложно, но человеку со стороны трудно вникнуть, отсюда попытки объяснить простые вещи своими словами что только увеличивает сложность описания. По моему мнению система не столь сложна, проблема с ее реализацией не опытным разработчиком (мной).
Что касается хотелок... Есть конечно и сложности, на которые я просто закрываю глаза. Какие то дикие требования что в одном случае нормы рассчитываются так, в другом иначе, в одном случае деталь подлежит обязательной замене, в другом заменяется только по дефектации... В этом всём в жизни то разобраться не получается, не то что реализовать это в базе. ...когда я обратился к главному инженеру с предложением автоматизировать всё это, дабы упорядочить весь этот бардак – его ответ был – если автоматизировать бардак, то получится автоматизированный бардак. После нескольких попыток просто разобраться, стал тупо игнорировать все эти сложности, они все равно погоды не делают, и на 80–90% можно закрыть все потребности упрощенной системой, которую и пытаюсь реализовать.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246975
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А оставшиеся 10–20% можно привести к нужному виду, либо на худой конец доработать ручками.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38246978
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
П–Л, я ещё боюсь что не так уж много времени мне осталось. На полноценную переработку схемы его нет. На днях мне капитально влетело от начальства с тем что не успел в срок сделать отчёт по ремонту, с лишением премии и всё такое. Правда полноценные исходные данные для этого отчета я получил лишь накануне, и сделать всё в срок возможно было бы если бы моя система в автоматически режиме готовила бы отчёт со всем оформлением и сбрасывала его в эксель уже оформленным, для дальнейшей проверки и распечатки. Пока я такого не реализовал.
Начальству же глубоко до лампочки что даже то что я сделал позволяет ускорить работу в разы, и сидела бы на моем месте тетя со средним образованием и эксель необходимого отчета они недели две дожидались бы.
«что там делать?! Разработал нормы расхода и контролируй» «Ты! Как нормировщик обязан копировать и собирать все счёт фактуры на защиту, это не работа экономистов»
А ещё я обязан разрабатывать нормы расхода материалов и запчастей для всего производства в целом и отдельных подразделений (цехов), на других предприятиях для такого работают целые отделы вообще то. А ещё составлять планы развития производства и отслеживать их выполнение. А ещё подменять отсутствующих технологов по цехам, так как народ не держится и уходит, и кому то надо и эту работу вести. (конечно не я один на замене, но нас мало). И еще много много других ещё.
Если при следующем отчете ситуация с задержкой отчета повториться (а так оно и будет! Иначе и быть не может, до тех пор как я запущу систему в полноценное использование) меня скорей всего уволят.
Как уже писал, жалко не столько рабочего места, сколько вложенного труда, и того потенциала который так и останется не реализованным.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247087
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну в принципе опять та же ситуация: четкого описания проблемы нет, четкой постановки задачи тоже, как я понял из текущих реплиу чего-то надо посчитать.

Отсюда и советы будет неконкретные.

На количестве записей несколько десятков тысяч записей все подобные расчетв должны летать. Если не летает - увы, виноват радиус кривизны собственных рук. На том числе сущностей, что у тебя есть при нормально организованных индексах и запросах все эти нормы должны считаться ОЧЕНЬ быстро.

Из твоего бессистемного изложения у меня отложилось следующее.

Структура изделия по элементвм (вниз по сборкам, подсборкам до самых мелких деталей) вопросов не вызывает. Все остальное - вызывает.
Назначение системы - вести учет ремонта изделий.
При ремонте изделия ремонту могут подвергаться любые его элементы (составные части).
Ремонт может вестись в разных цехах. Один и тот же элемент изделия может ремонтироваться в разных (более чем одном цехе).
В каждом цехе существуют свои нормы расхода при ремонте элементов изделия.
Во время ремонта происходит фактическое выписывание (выделение) элементов для ремонта.
Общее количество всех элементов, выписанных за время ремонта изделия, суммируется и сравнивается с нормами расхода, чтобы контролировать экономию или перерасход в разрезе цехов и всего по изделию.

В такой постановке задача не кажется сложной. Я бы гарантировал готовый результат под ключ за 1 человеко-месяц (с хорошими, удобными формами и отчетами), при условии использования своей собственной платформы.

Возвращаясь к более узкому вопросу - правильно я понимаю, что проблему вызывает запрос, подсчитывающий общее количество фактически израсходованных элементов и общие нормы в разрезе цехов/всего по изделию ?
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247309
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-ЛюбительНа количестве записей несколько десятков тысяч записей все подобные расчетв должны летать. Если не летает - увы, виноват радиус кривизны собственных рук. На том числе сущностей, что у тебя есть при нормально организованных индексах и запросах все эти нормы должны считаться ОЧЕНЬ быстро.

Здесь ситуация несколько исправилась. Не скажу что все прямо так летает, но в сравнении с тем что было раньше... да летает. По крайней мере есть несколько форм с отвязанным рекордсетом в которых при перемещении по записям ... скажем так в мастер форме, в подчиненной меняется рекордсорс по соответствующему запросу и высвечивается результат в доли ... ну максимум в секунду. Это вполне устраивает... Ну есть проблема с выводом иерархии в тривью, там расчет длится 30-60 секунд, просто так все организовал что расчитываются и выводятся все имеющиеся изделия, но форма с тривью мной используется очень редко, потому пока не заморачиваюсь. Там просто переделать ее надо, но это пока не критично и особо ни на что не влияет, потому пока не занимался. Есть вещи важнее.


Программист-ЛюбительНазначение системы - вести учет ремонта изделий.

Нет. Непосредственно учет ведется в бухгалтерии на их базе. Таблицы которой и использую. О том много уже писал, то к чему пришел сейчас с учетом - устраивает. Учет - не моя задача. Я только импортирую их данные и обрабатываю их. Моя задача что бы все что там у бухгалтеров учитывается не выходило за рамки норм. Ну и соответственно подготовка отчетов по ремонту изделий, вот сколько и чего списали, а вот ссылка на позицию в нормативе. Все должно биться. Если не бьется - меня линчуют и вполне обоснованно.

Программист-ЛюбительПри ремонте изделия ремонту могут подвергаться любые его элементы (составные части).
Ремонт может вестись в разных цехах. Один и тот же элемент изделия может ремонтироваться в разных (более чем одном цехе).

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

Программист-ЛюбительВ каждом цехе существуют свои нормы расхода при ремонте элементов изделия.
Во время ремонта происходит фактическое выписывание (выделение) элементов для ремонта.
Общее количество всех элементов, выписанных за время ремонта изделия, суммируется и сравнивается с нормами расхода, чтобы контролировать экономию или перерасход в разрезе цехов и всего по изделию.

Совершенно точно. ..сравнивается с нормами расхода, и вообще с количеством сколько вообще таких деталей стоит на изделии. Превышение норм расхода еще не критично (если это не массовое явление) и можно объяснить, а вот превышение количества на изделия чревато проблемами при защите цены. Как может быть выписано на ремонт изделия А шесть штук подшипников типа... если их там всего два? Для этого у меня в системе есть индикация (условное форматирование) - превысило норму - ячейка окрашивается в оранжевый цвет, я как нормировщик принимаю решение пропустить или нет, могу вызвать из цеха ответственных "Ходи сюда - почему выписали больше? Если надо - пиши рапорт, что так надо и почему надо". Превышено количество на изделии (самом изделии как таковом, сборке, агрегате) - красный цвет. Тут же такое "требование" (документ на списание) отклоняю. Частенько происходит. А учитывая то что по некоторым деталям у меня идет удвоение, утроение, возникают мои ошибки.


Программист-ЛюбительВозвращаясь к более узкому вопросу - правильно я понимаю, что проблему вызывает запрос, подсчитывающий общее количество фактически израсходованных элементов и общие нормы в разрезе цехов/всего по изделию ?
Общее количество по выписанных по факту расчитывается сейчас корректно. Есть мелкие ошибки, по одной двум записям на изделие так же идет удвоение, пока не разобрался почему, ... так как эти ошибки достаточно легко обнаружить, ... не до них просто было и не заморачивался пока, просто держу в уме что такая проблема иногда возникает, при случае надо разобраться.
Нормы тоже более менее, критичных ошибок вроде нет. А вот количество на изделии которое должно быть... врет система. И причину я вижу совершенно четко. (схема данных на первой картинке), а вот обойти ее... при такой схеме наверное возможно созданием отдельного рекурсивного запроса только по таблице tblNodeElement без включения tblZehNorm. И затем созданием общего запроса с включением в него этих данных... Мне кажется это сейчас единственный вариант.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247311
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изерлонер (схема данных на первой картинке)
На второй моей картинке конечно же. Там где две таблицы tblNodeElement и tblZehNorm.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247338
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзерлонерПрограммист-ЛюбительНазначение системы - вести учет ремонта изделий.
Нет. Непосредственно учет ведется в бухгалтерии на их базе. Таблицы которой и использую. О том много уже писал, то к чему пришел сейчас с учетом - устраивает. Учет - не моя задача. Я только импортирую их данные и обрабатываю их. Моя задача что бы все что там у бухгалтеров учитывается не выходило за рамки норм. Ну и соответственно подготовка отчетов по ремонту изделий, вот сколько и чего списали, а вот ссылка на позицию в нормативе. Все должно биться. Если не бьется - меня линчуют и вполне обоснованно.
И все-таки твоя система ВЕДЕТ УЧЕТ ремонта изделий в тех разрезах, за которые ты отвечаешь.

ИзерлонерПрограммист-ЛюбительПри ремонте изделия ремонту могут подвергаться любые его элементы (составные части).
Ремонт может вестись в разных цехах. Один и тот же элемент изделия может ремонтироваться в разных (более чем одном цехе).

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

Это отмазки для бедных. Если у тебя де-факто связь сущностей М:М а ты звложил 1:М - ну молодец, сам себе злобный буратино. Такие ошибки НЕ ДОЛЖНЫ быть допущены. Как только это все-таки обнаружено, надо СРАЗУ ИМЕННО ЭТО исправлять. Любым потом и кровью. Это грубейшая ошибка, которую я никак не могу принять.

ИзерлонерПрограммист-ЛюбительВ каждом цехе существуют свои нормы расхода при ремонте элементов изделия.
Во время ремонта происходит фактическое выписывание (выделение) элементов для ремонта.
Общее количество всех элементов, выписанных за время ремонта изделия, суммируется и сравнивается с нормами расхода, чтобы контролировать экономию или перерасход в разрезе цехов и всего по изделию.

Совершенно точно. ..сравнивается с нормами расхода, и вообще с количеством сколько вообще таких деталей стоит на изделии. Превышение норм расхода еще не критично (если это не массовое явление) и можно объяснить, а вот превышение количества на изделия чревато проблемами при защите цены. Как может быть выписано на ремонт изделия А шесть штук подшипников типа... если их там всего два? Для этого у меня в системе есть индикация (условное форматирование) - превысило норму - ячейка окрашивается в оранжевый цвет, я как нормировщик принимаю решение пропустить или нет, могу вызвать из цеха ответственных "Ходи сюда - почему выписали больше? Если надо - пиши рапорт, что так надо и почему надо". Превышено количество на изделии (самом изделии как таковом, сборке, агрегате) - красный цвет. Тут же такое "требование" (документ на списание) отклоняю. Частенько происходит. А учитывая то что по некоторым деталям у меня идет удвоение, утроение, возникают мои ошибки.

Удвоение и утроения БЫТЬ НЕ ДОЛЖНО. Если оно проявилось, СРАЗУ ИСПРАВЛЯТЬ.

ИзерлонерПрограммист-ЛюбительВозвращаясь к более узкому вопросу - правильно я понимаю, что проблему вызывает запрос, подсчитывающий общее количество фактически израсходованных элементов и общие нормы в разрезе цехов/всего по изделию ?
Общее количество по выписанных по факту расчитывается сейчас корректно. Есть мелкие ошибки, по одной двум записям на изделие так же идет удвоение, пока не разобрался почему, ... так как эти ошибки достаточно легко обнаружить, ... не до них просто было и не заморачивался пока, просто держу в уме что такая проблема иногда возникает, при случае надо разобраться.
Нормы тоже более менее, критичных ошибок вроде нет. А вот количество на изделии которое должно быть... врет система. И причину я вижу совершенно четко. (схема данных на первой картинке), а вот обойти ее... при такой схеме наверное возможно созданием отдельного рекурсивного запроса только по таблице tblNodeElement без включения tblZehNorm. И затем созданием общего запроса с включением в него этих данных... Мне кажется это сейчас единственный вариант.
Если на количестве твоя система "врет", то это значит что это место у тебя ваапще НЕ СДЕЛАНО. Пачиму ?!

По общему описанию в своем изложении, я, хоть убей, катастрофы или суперсложности не вижу. Ну, пробежаться по деревьям, посчитать листочки - делается от нуля ровно за 5 минут из которых 4 уходит на изучение примера из БОЛ. Посчитать с учетом твоих особенных цеховых норм - ну тут чуть подольше. Трудностей, при правильной организации схемы данных, я не вижу. Практических нюансов у тебя, конечно, до фига, но это нормальная работа - вникать в нюансы, дорабатывать схему БД, запросы и формы.

К сожалению, опять получились общие советы. Конкретно я тебе ничего не подсказал.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247370
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-ЛюбительЕсли у тебя де-факто связь сущностей М:М а ты звложил 1:М - ну молодец, сам себе злобный буратино.
Э-э-э.. если имеется ввиду связь цех - запчасть, то связь таки М:М. tblContractor - таблица с цехами (а так же с поставщиками, покупателями и т.д. контрагентами - все в одной таблице).
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247371
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
понятное дело поставщики и др. в нормативах не участвуют. Задается соответственно в таблице tblZehNorm соответствующим внешним ключем. Ключей поставщиков там понятно - нет.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247372
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я имел в виду процесс ремонта элемента в нескольких цехах. Ты писал что у тебя это невозможно ?

На схеме данных надо делать подписи к таблицам. Одно-два-три предложения, как можно более конкретно описывающие назначение таблицы. Часто я делаю дополнительные комментарии просто на свободном пространстве схемы данных. Привожу содержание важных справочников (шрифтом постоянной ширины). Твоя схема недостаточно хорошо читается.

Покажи код заполнения дерева. Если у тебя всякий раз открываются рекордсеты для каждого нового уровня, то это время можно в разы сократить - за счет филтьрации одинажды открытого "широкого" рекордсета или за счет шейпов.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247382
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Когда я делал (вернее переделывал из твоего примера) код для заполнения TreeView я про рекордсеты весьма мало знал, можно сказать вообще ничего. Так что ... вот:
Код: vbnet
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
Public Sub RebuildTree()

    Dim cnn As ADODB.Connection  
    Set cnn = CurrentProject.Connection

    Dim tv As TreeView
    Dim nodeRoot As node
    Dim rsRoot As ADODB.Recordset

    Set tv = Me.ctlTree.Object
    Me.ctlTree.Visible = True
    tv.Nodes.Clear

    Set rsRoot = CurrentProject.Connection.Execute("SELECT * FROM vSostav WHERE iReplaseableElementID_Parent is Null")
        If rsRoot.EOF And rsRoot.BOF Then
          GoTo Nichts
        End If
    While Not rsRoot.EOF
    Set nodeRoot = tv.Nodes.Add( _
        Key:="ROOT" & CStr(rsRoot!iNodeElementID), _
        Text:=rsRoot!strElementName & " " & rsRoot!strElementDescription & " " & rsRoot!strElementStandart)
      nodeRoot.Tag = rsRoot!iNodeElementID
      nodeRoot.Expanded = True
      Call LoadLevel(tv, nodeRoot, rsRoot!iElementID)
      rsRoot.MoveNext
    Wend
      
    'Call TreeView_NodeClick(nodeRoot)
Nichts:
    rsRoot.Close: Set rsRoot = Nothing
    Me.ctlTree.SetFocus

End Sub

Public Function LoadLevel(tv, nodeParent, iElementID)

    Dim cnn As ADODB.Connection
    Set cnn = CurrentProject.Connection
    Dim rs As ADODB.Recordset
    Set rs = New ADODB.Recordset
    Set rs = CurrentProject.Connection.Execute("SELECT * FROM vSostav WHERE iReplaseableElementID_Parent= " & iElementID & _
    "Order by sngGroupOfEShifr, strPodGroupOfEName, strElementName, strElementDescription")
    Dim nodeGroup As node
    Dim node As node
    While Not rs.EOF
    If rs!sngGroupOfEShifr = 10 Then
    Set nodeGroup = tv.Nodes.Add( _
        relative:=nodeParent.Index, relationship:=tvwChild, _
        Key:="NODE" & nodeParent & "Изделия", _
        Text:="Изделия")
      While rs!sngGroupOfEShifr = 10
         Set node = tv.Nodes.Add( _
            relative:=nodeGroup.Index, relationship:=tvwChild, _
            Key:="NODE" & nodeParent & CStr(rs!iNodeElementID), _
            Text:=rs!strElementName & " " & rs!strElementDescription & " " & rs!strElementStandart & " " & CStr(rs!iNodeElementID))
        node.Tag = rs!iNodeElementID
        node.Expanded = True
        Call LoadLevel(tv, node, rs!iElementID)
        rs.MoveNext
        If rs.EOF Then GoTo Exit_1
        Wend
Exit_1:
        
    ElseIf rs!sngGroupOfEShifr = 10.1 Then
    Set nodeGroup = tv.Nodes.Add( _
        relative:=nodeParent.Index, relationship:=tvwChild, _
        Key:="NODE" & nodeParent & "Материалы", _
        Text:="Материалы")
      While rs.EOF = False And rs!sngGroupOfEShifr = 10.1
         Set node = tv.Nodes.Add( _
            relative:=nodeGroup.Index, relationship:=tvwChild, _
            Key:="NODE" & nodeParent & CStr(rs!iNodeElementID), _
            Text:=rs!strElementName & " " & rs!strElementDescription & " " & rs!strElementStandart) ' & CStr(rs!iNodeElementID))
        node.Tag = rs!iNodeElementID
        node.Expanded = True
        Call LoadLevel(tv, node, rs!iElementID)
        rs.MoveNext
        If rs.EOF Then GoTo Exit_2
        Wend
Exit_2:
            
     ElseIf rs!sngGroupOfEShifr = 10.3 Then
     Set nodeGroup = tv.Nodes.Add( _
        relative:=nodeParent.Index, relationship:=tvwChild, _
        Key:="NODE" & nodeParent & "ГСМ", _
        Text:="ГСМ")
      While rs.EOF = False And rs!sngGroupOfEShifr = 10.3
         Set node = tv.Nodes.Add( _
            relative:=nodeGroup.Index, relationship:=tvwChild, _
            Key:="NODE" & nodeParent & CStr(rs!iNodeElementID), _
            Text:=rs!strElementName & " " & rs!strElementDescription & " " & rs!strElementStandart) ' & CStr(rs!iNodeElementID))
        node.Tag = rs!iNodeElementID
        node.Expanded = True
        Call LoadLevel(tv, node, rs!iElementID)
        rs.MoveNext
        If rs.EOF Then GoTo Exit_3
        Wend
Exit_3:

     ElseIf rs!sngGroupOfEShifr = 10.5 Then
     Set nodeGroup = tv.Nodes.Add( _
        relative:=nodeParent.Index, relationship:=tvwChild, _
        Key:="NODE" & nodeParent & "Запчасти", _
        Text:="Запчасти")
      While rs.EOF = False And rs!sngGroupOfEShifr = 10.5
         Set node = tv.Nodes.Add( _
            relative:=nodeGroup.Index, relationship:=tvwChild, _
            Key:="NODE" & nodeParent & CStr(rs!iNodeElementID), _
            Text:=rs!strElementName & " " & rs!strElementDescription & " " & rs!strElementStandart) ' & CStr(rs!iNodeElementID))
        node.Tag = rs!iNodeElementID
        node.Expanded = True
        Call LoadLevel(tv, node, rs!iElementID)
        rs.MoveNext
        If rs.EOF Then GoTo Exit_4
        Wend
Exit_4:
      
     ElseIf rs.EOF = False Then
     Set nodeGroup = tv.Nodes.Add( _
        relative:=nodeParent.Index, relationship:=tvwChild, _
        Key:="NODE" & nodeParent & "Неопределено", _
        Text:="Неопределено")
      While rs.EOF = False
         Set node = tv.Nodes.Add( _
            relative:=nodeGroup.Index, relationship:=tvwChild, _
            Key:="NODE" & nodeParent & CStr(rs!iNodeElementID), _
            Text:=rs!strElementName & " " & rs!strElementDescription & " " & rs!strElementStandart) ' & CStr(rs!iNodeElementID))
        node.Tag = rs!iNodeElementID
        node.Expanded = True
        Call LoadLevel(tv, node, rs!iElementID)
        rs.MoveNext
        If rs.EOF Then GoTo Exit_5
        Wend
Exit_5:
     End If
     Wend
        
    
End Function



Выглядит не очень, и недостатков масса. Но так как функционально я форму с тривью нигде не использую, разве что посмотреть/проверить входимость изделий - пока ничего не переделывал.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247387
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-ЛюбительЯ имел в виду процесс ремонта элемента в нескольких цехах. Ты писал что у тебя это невозможно ?

Возможно. Но так как данные о количестве деталей в изделии, и нормы расхода разнесены по разным таблицам, а рекурсивный запрос строится на объединении этих (и нескольких других) таблиц, идет кратное увеличение количества на изделие.
... в общем я все-таки прихожу к выводу что схема в принципе верная. Не верно было делать рекурсивный запрос по соединению этих таблиц.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247388
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Заполненное дерево. ...На домашнем компе выводилось минут пять.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247390
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-ЛюбительНа схеме данных надо делать подписи к таблицам.
по правой кнопке мыши - "создать примечание"?
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247435
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По примечаниям да.

По дереву.

Для дерева должно быть достаточно двух таблиц, хранящих структуру изделий. Лишнего в запросе быть не должно. Обязано строиться моментом. Для ускорения открой рекордсет со всеми записями и потом для загрузки очередного уровня применяй к нему фильтр "iReplaseableElementID_Parent=" & iElementID. Переменную рекордсета сделай глобальной или передавай как параметр при рекурсивном обходе. Должно в разы ускориться.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247543
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-Любитель,


кстати, по поводу глобальной переменной рекордсета. В одном из твоих примеров обратил внимание что в процедуре ты открываешь рекордсет присваиааешь ему значение (ссылку на таблицу)... а где закрытие рекордсета? Там не полный код был, только одной процедуры.
У себя я сделал закрытие на событие «закрытие формы» ... но не всегда действует. Иногда пытается закрыть рекордсет, который не был открыт. Как и открыть тоже не всегда получается. Ну или например при переходе в режим конструктора, тоже ошибки вылезают с открытием/закрытием рекордсета. Это всё мелочи, которые так или иначе быстро можно обойти при работе, поэтому сильно этим пока не заморачивался, как говорил – есть более насущные проблемы, мелочи оставляю на будущее (благо с базой работаю только я, ...никто другой пока и не сможет – столько косяков моментально вылезет, которые я знаю и знаю как работать что бы они не вылезали)
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247546
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ещё, по дереву вылезала ошибка при выводе одноименных агрегатов в разных изделиях, временно решил добавлением iNodeElementID в конец текста (в коде видно). Но это только временное решение, так как ID здесь мне нафинг не нужны.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247548
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изерлонер временно решил добавлением iNodeElementID в конец текста (в коде видно)
Код: vbnet
1.
K e y : = " N O D E " & n o d e P a r e n t & C S t r ( r s ! i N o d e E l eme n t I D ) , _ T e x t : = r s ! s t r E l eme n t N ame & " " & r s ! s t r E l eme n t D e s c r i p t i o n & " " & r s ! s t r E l eme n t S t a n d a r t & " " & C S t r ( r s ! i N o d e E l eme n t I D ) )
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247550
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Прошу прощения, вставилось не совсем корректно. Пишу со смартфона...
При том эта ошибка характерна только для уровня агрегатов. Детали выводятся сколько угодно раз, хоть бы и назывались совершенно идентично.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247573
Cyrax_02
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автортак как ID здесь мне нафинг не нужны.
Я использую класс для генерации ключей:

Код: vbnet
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
Option Compare Database
Option Explicit

'=========================================================================
'Класс clsNodeKeyGenerator: генератор уникальных ключей для узлов TreeView
'=========================================================================

Private nodeKeyCounter As Long    'значение счётчика

Public Function Create() As String
    nodeKeyCounter = nodeKeyCounter + 1
    Create = Format(nodeKeyCounter)
End Function

Public Sub Reset()
    nodeKeyCounter = 0
End Sub


Private Sub Class_Initialize()
    nodeKeyCounter = 0
End Sub

Private Sub Class_Terminate()
    '
End Sub


Для каждого дерева - свой объект clsNodeKeyGenerator.
Если на ключи совсем не наплевать, то в метод Create можно передавать параметры, на основании которых будет генерироваться ключ определённого вида. Можно также для каждого типа узла ввести свои счётчики (nodeKeyCounterType1, nodeKeyCounterType2 и т.д.), а тип узла передавать в качестве параметра в метод Create. Много вариантов.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247591
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
По поводу дубливания узлов в дереве.

В случае, когда в тривью одни и те же объекты помещаются более одного раза, я добавляю в конец Key конктенацию nodes.Count
В таге храню выражение <ИмяАйдиПоля>=<Значение>. Тем самым при анализе тага текущего узла всегда ясно, что это за сущность и какой у нее айди.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247840
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-Любитель,

можешь меня поздравить. Иногда полезно ощутить себя круглым дураком. Нафига я спрашивается городил рекурсивный запрос на объединении всех таблиц, создавая себе массу сложностей и проблем?! Все гораздо проще. Надо было сделать рекурсивный запрос на одной таблице tblNodeElement, как было сделано у тебя, а уже потом присобачивать туда все что хошь. Наименования элементов, единицы измерения, цеховые нормы и цеха и т.д.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247844
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Количество деталей в изделии считает теперь корректно. А общую норму запчастей (и материалов) на изделие можно получить простой группировкой на соединении рекурсивного запроса с таблицей tblZehNorm.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247847
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-ЛюбительПо поводу дубливания узлов в дереве.

В случае, когда в тривью одни и те же объекты помещаются более одного раза, я добавляю в конец Key конктенацию nodes.Count
В таге храню выражение <ИмяАйдиПоля>=<Значение>. Тем самым при анализе тага текущего узла всегда ясно, что это за сущность и какой у нее айди.
Если правильно помню - проблема возникла из-за введения в дерево разделов "Изделия, Материалы, ГСМ, Запчасти" у самих разделов получаются одинаковые ключи, хотя они и могу находится в разных агрегатах и изделиях, отсюда видимо и пошли сложности. Разберусь с этим чуть позже. ... Возможно в ведении этих разделов и нет смысла. Материалы и ГСМ можно и в других формах посмотреть, по дереву все равно с ними работать не удобно.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247854
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На мой взгляд уровни Изделия, материалы, ГСМ, запчасти очень наглядно смотрятся. На форме, показывающей структуру узла должна быть какая-то визуальная группировка по тем же 4 разделам. Посмотри мой пример в сосоеднем топике про 64 битное дерево - я сделал новую форму frmIzdelieTreeAPI. Там есть програмная реализация некоторых приемов -
динамическая загрузка субформ
динамическое формирование источников данных форм
открытие форм с позиционированием на нужную запись

Эту форму и некоторые другие я в коде немного откомментировал. К сожадению, мои общеупотребительные модули, которые пришлось включить в проект мало откомментированы. Если не поленишься скачать и запуститьЮ можешь спрашивать на форуме, я отвечу на вопросы.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247861
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзерлонерКоличество деталей в изделии считает теперь корректно.
Дулю мне. Не все так замечательно Если деталь стоит в одной ветке дерева - например в сборке и в ее же подсборке, то суммирует. А вот если деталь стоит в совершенно разных агрегатах, но которые таки стоят все в одном изделии, расчитывает количество деталей на агрегат, вместо того что бы выдать общую сумму на изделие.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247863
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзерлонерЕсли деталь стоит в одной ветке дерева - например в сборке и в ее же подсборке, то суммирует.
И даже не так. Суммирует если агрегата два (и более), вот для них выводит корректно.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247864
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
После подсчета по дереву изделия надо еще раз просуммировать по рутовскому айди и аиди запчасти. Вот и будет сколько всего таких деталей в этом изделии.

Все остальный узлы дерева - неважно.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247866
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
WITH NodeLevel  
(
iNodeElementID, iElementID_Root, iElementID_Parent, iElementID, decNodeElementCnt, decNodeElementNormSum, decNodeElementNormObosn, iPodrasdelID, iPodrasdel3ID, 
strPodrasdel, strPodrasdel3, strPrim, strObosnovanie, strDopObosnovanie, strVid, decNodeElementCntSum
)
 AS 
(
SELECT     
                  iNodeElementID, 
                  iReplaseableElementID AS iElementID_Root, 
                  iReplaseableElementID_Parent AS iElementID_Parent, 
                  iReplaseableElementID AS iElementID,  
                  decNodeElementCnt, 
                  decNodeElementNormSum, 
                  decNodeElementNormObosn, 
                  iPodrasdelID, 
                  iPodrasdel3ID, 
                  strPodrasdel, 
                  strPodrasdel3, 
                  strPrim, 
                  strObosnovanie, 
                  strDopObosnovanie, 
                  strVid,
                  Cast(ISNULL (nd.decNodeElementCnt, 0) as decimal (8,3))
FROM  dbo.tblNodeElement AS nd
WHERE     (iReplaseableElementID_Parent IS NULL)
UNION ALL SELECT     
                  nd.iNodeElementID, 
                  NodeLevel.iElementID_Root, 
                  nd.iReplaseableElementID_Parent,
                  nd.iReplaseableElementID, 
                  nd.decNodeElementCnt, 
                  nd.decNodeElementNormSum, 
                  nd.decNodeElementNormObosn, 
                  nd.iPodrasdelID, 
                  nd.iPodrasdel3ID, 
                  nd.strPodrasdel, 
                  nd.strPodrasdel3, 
                  nd.strPrim, 
                  nd.strObosnovanie, 
                  nd.strDopObosnovanie, 
                  nd.strVid,
                  decNodeElementCntSum = Cast((ISNULL (NodeLevel.decNodeElementCnt, 0) * ISNULL (nd.decNodeElementCnt, 0)) as decimal (8,3)) 
FROM dbo.tblNodeElement AS nd
           JOIN NodeLevel ON nd.iReplaseableElementID_Parent = NodeLevel.iElementID
)
SELECT
                  iNodeElementID, 
                  iElementID_Root, 
                  iElementID_Parent, 
                  iElementID,  
                  decNodeElementCnt, 
                  decNodeElementNormSum, 
                  decNodeElementNormObosn, 
                  iPodrasdelID, 
                  iPodrasdel3ID, 
                  strPodrasdel, 
                  strPodrasdel3, 
                  strPrim, 
                  strObosnovanie, 
                  strDopObosnovanie, 
                  strVid,
                  decNodeElementCntSum
FROM NodeLevel
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247870
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-ЛюбительПосле подсчета по дереву изделия надо еще раз просуммировать по рутовскому айди и аиди запчасти. Вот и будет сколько всего таких деталей в этом изделии.

Т.е. тоже группировка?
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247874
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Оставляешь в запросе только айди рута (изделия в целом), айди запчасти, по полю расчитанного количества - агрегат суммы.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38247880
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Программист-Любитель,

не знаю и чего ты нам помогаешь, но без твоих советов и тем более примеров было бы ... очень плохо все. Весьма вероятно что давно бы оставил эту затею и грустно возился бы с экселем... до тех пор пока под зад бы не с работы не пнули, у нас это быстро. До меня нескольких человек сменили. Всё думают что один человек этакую прорву потянет. Не тянет значит работник плохой. А то что у работника соответствующих задаче инструментов нет ... то никак не дойдет. ... Военные блин (пусть и бывшие), особенная психология.
Скачал твои примеры с соседней ветки, буду разбираться.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38248695
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
П-Л, думал сначала отдельную тему завести, но так-как вопрос все-таки не совсем по Акцесс, и более к тебе нежели к другим форумчанам - задаю его здесь.
Я помню твои предупреждения о том что наименования таблиц и запросов должны звучать четко, да так что бы сразу было понятно о чем речь. Сейчас у меня проблема как раз в этой области. А конкретно по запросам. Если таблицы можно увидеть на схеме данных, посмотреть что от чего зависит, и тем более прописать в схеме примечания для каждой таблицы, то с запросами все сложнее. Для них нет такой схемы, к ним очень сложно придумать однозначные наименования (особенно если запросы по сути одни и те же и отличаются лишь в деталях) а возможно ли ставить для них примечания где-либо, я не знаю, и такой возможности не нашел.
Между тем запросов у меня выше крыши (больше чем исходных таблиц). Не все из них нужные, какие-то заменены на более новые и проработанные, а старые остались либо для связи с кодом на VBA которые еще не успел поправить, либо еще для каких-то целей. Как бы то ни было имею массу запросов типа:
Код: sql
1.
qryNormSumZeh, qryNormSumIzd, qryNorm, qryNormSumZehCnt, qrySumIzdNorm .....


и т.д. и т.п. В результате даже самому стало сложно разобраться что это за запросы и какой же из них конкретно мне нужен. Ни примечаний, ничего поясняющего нет и как их туда всунуть не знаю, все кучей в окне студии слева. Хуже того из-за такого количества запросов порой долго не могу найти то что я непосредственно вчера-то делал. Как это все возможно организовать? И возможно ли где-то писать поясняющие примечания, что бы их видно было в окне студии. В конце концов возможно ли их отсортировать по дате создания, что бы хоть так прослеживалось что и когда было сделано, и соответственно вспомнить и понять для чего, с какой целью?
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38248730
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть разные мЕтоды
1. Использование полноценной студии с проектом типа базы данных
2. Использование серверной студии с хранением объектов (запросов, функций, процедур) в структуре "папок" сервера
3. Использование серверной студии с организацией файлов по функциональным блокам.

У каждого свои плюсы и минусы.

1.
+ Самый методологически правильный, родной метод с точки зрения микрософта.
+ Можно пользоваться многими плюшками рефакторинга.
+ Контролируется правильность и непротиворечивость ВСЕХ объектов БД.
+ Можно девелопить на девелоперской и накатывать скрипты изменения на продакшен.
- Нужна полная студия.
- Нужно уметь работать с проектом типа базы данных.
- Придется иметь отдельную модельную БД со скриптами генерации демоданных.
- Нельзя рисовать таблицы и связи на диаграмме БД, тольк скрипами. Т.е. новые куски схем разрабатывать неудобно.
-(+?) Изменения не отражаются на реальных данных продакшена.

2.
+ "Родной" способ для админов БД.
+ Требуется только серверная студия, автоматом входящая в ПО.
+ Таблицы и связи правятся на диаграммах данных
- Трудно организовывать объекты по своим функциональным блокам, иерархия будет такой, какая удобна серверу.

3. Мой выбор.
+ Таблицы и связи правятся на диаграммах данных
+ Остальные объекты (вью, ф-ии, процедуры) организуются в файлы по функциональным блокам приложения
+ Можно делать частичный рефакторинг простым текстовым реплейсом, благо в один файл собран код "смежных" объектов
- Возможно рассогласование объектов, рефакторинг только частичный, при невнимательности после замены можно получить неправильный код
- Риск резать по живому - работаем на продакшене, при работе на девелоперской потом надо повторить изменения на диаграммах и не забыть прогнать измененные файлы на продакшене

Продолжение следует...
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38248751
П-Л
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как делается по п.3
В рабочем каталоге SQL кода по мере развития системы создаются файлы. Удачно, если получается такая степень группировки объектов, когда в одном файле сидят коды создания всех объектов, обслуживающих данных функциональный блок. Если их слишком много, приходится делать несколько файлов.

Внутри файла идут инструкции
дроп что-то
криейт что-то
...
дроп что-то
криейт что-то
...
дроп что-то
криейт что-то
...

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

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
-- VIEW qrCheckDataBase
-- VIEW qrCheckData                                                             
-- VIEW qrCheckDataField                                                        
-- VIEW qrCheckDataFieldDescription                                             
-- VIEW qrCheckDataAllFieldDescription                    
-- PROC CheckData_CopyTree (@iCheckDataID_OLD)                                  
-- PROC CheckData_DeleteTree (@iCheckDataID)                                    
-- TRIG tri_METAB_CheckDataRun ON METAB_CheckDataRun                            
-- VIEW qrCheckDataRun                                                          
-- VIEW qrCheckDataRunSchedule                                                  
-- VIEW qrCheckDataRunUser                                                      
-- VIEW insertCheckData_TAB_CheckDataRunUser        
-- FUNC fncCheckDataLastRun (@iCheckDataID, @sUserOrRoleCode, @sUserName,       
--      @sCheckDataScheduleAnyFlag)                                             
-- FUNC fncCheckDataRunFlag (@dt, @iCheckDataID, @sFrequencyCode,               
--      @sUserOrRoleCode @sUserName, @sCheckDataScheduleAnyFlag)                
-- FUNC fntCheckDataRunSchedule(@sUserName, @dtRunDate)                         
-- PROC insertSchedule_TAB_CheckDataRunUser(@sUserName, @dtRunDate)             
-- FUNC fntCheckDataRunScheduleUser(@sUserName, @dtRunDate)                     
... и так далее


Каждый объект ниже по файлу снабжается описанием:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
-- VIEW qrCheckDataBase
--      Проверочные отчеты+источник данных                                      
--      SELECT ... FROM METAB_CheckData                                         
--      INNER JOIN TAB_DatasourceDescription ON  ... sDatasourceName ...        
--
-- VIEW qrCheckData     
--      Проверочные отчеты+источник данных                                      
--      SELECT ... FROM METAB_CheckData                                         
--      INNER JOIN TAB_DatasourceDescription ON  ... sDatasourceName ...        
--      LEFT OUTER JOIN METAB_SyntaxNode                                        
--          ON iSyntaxNodeParentID = iCheckDataID                               
--          AND sSyntaxNodeRootFlag = 'Y'              
... и так далее


И, наконец, еще ниже код создания объекта
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
GO
--------------------------------------------------------------------------------
IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.VIEWS 
WHERE TABLE_NAME = 'qrCheckDataBase') DROP VIEW dbo.qrCheckDataBase
--------------------------------------------------------------------------------
GO
--------------------------------------------------------------------------------
-- Данные проверочных отчетов и источников данных                               
--------------------------------------------------------------------------------
CREATE VIEW dbo.qrCheckDataBase AS

SELECT

   ch.iCheckDataID,                     -- PK Счетчик                                              
   ch.sCheckDataCode,                   -- Номер (шифр) проверочного отчета                        
   ch.sCheckDataName,                   -- Название проверочного отчета                            
   ch.sCheckDataMessage,                -- Текстовое сообщ.: 'У резидентов должен быть задан ИНН'  
   ch.sCheckDataDescription,            -- Подробное описание проверочного отчета   
   sCheckDataAlias = ISNULL(ch.sCheckDataCode + ' ', '') + ISNULL(ch.sCheckDataName, ''),

   ch.sDatasourceName,                  -- FK Системное имя источника данных (qrInqueryInvestment2)
   ch.iSyntaxNodeRootID,                -- FK Корневой узел выражения проверки                     

   ch.sCheckDataSQL,                    -- Готовое SQL выржение WHERE                     
   ch.sCheckDataOrderBy,                -- Готовое SQL выржение ORDER BY                                                 
   ch.sCheckDataErrorMessage,           -- Расшифовка, какая конкретная причина не удовлетворила условиям отчета
   
   ch.sFormName,                        -- Имя формы для вывода результатов проверки
                                        -- Если имя формы не задано, то используется               
                                        -- имя табличной формы из источника данных                 
   ch.iCheckDataFieldListOption,        -- 1-Из условий проверки | 2-Из источника данных | 3-Из формы
   ch.bCheckDataIncludeAudit,           -- Включать аудирующие поля sUserNameInsert, ...         

   ch.iCheckDataRunID,                  -- FK Последний запуск отчета                              
   ch.dtCheckDataRunDate,               -- Дата и время запуска отчета                             
   ch.sCheckDataRunUserName,            -- Пользователь запустивший отчет                          
   ch.nCheckDataRunRecordCount          -- Число записей, не удовлетворяющих условиям              

FROM 

   METAB_CheckData ch
--------------------------------------------------------------------------------
GO



Как-то так...
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38248910
Изерлонер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
П-Л,

я правильно понимаю что свои запросы (представления) ты создаешь посредством кода, и не используешь соответствующий конструктор?
все мои запросы сделаны в конструкторе. Даже если сам запрос набирался вручную, все равно потом открывал конструктор и вставлял текст запроса. может быть при таком м создании соответствующие файлы генерируются автоматом?
Пока из того что ты описал ухватил простую но ясную мысль. Имя запроса создается на основе сущностей к которым он обращается, дальнейшие доработки — дополнения к этому имени. ...хотя как быть если запрос обращается к двум и более другим запросам созданным ранее.
...
Рейтинг: 0 / 0
Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
    #38249578
Фотография Программист-Любитель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, вручную мне кажется делать запросы гораздо удобнее. Обычно следующие (ниже по тексту) запросы используют части кода расположенных выше, это удобно копипастить. Самый первый запрос получается перетягиванием полей из таблицы на страницу кода. В этот же момент надо не полениться и скопировать со схемы данных описания полей. Тогда при последующем переклеивании описания тоже будут копироваться во вновь создаваемый код. Файл "компилируется", загоняется в сервер командой RUN целиком. Пока идет работа над текстом объекта его куски можно выделять мышкой и тоже прогонять RUN'ом. Между запросами или в конце файла накапливаются полезные тестовые примеры запуска запросов, функций и процедур, обрамленные комментариями.

Это просто одна из возможных практик.
...
Рейтинг: 0 / 0
57 сообщений из 57, показаны все 3 страниц
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Сложный рекурсивный запрос или как получить суммы по разным алгоритмам
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]