Супер вопрос для особо знающих SQL под Access

@AlexV0 · Регистрация: 08.08.2007

Студворк — интернет-сервис помощи студентам

Привет, знаток!

Есть таблицы OU, VidDeyateln, NasPunkts, GroundArea, ObjNedv.
Часть полей выбираются из них, а часть выбираются с суммированием.
Проблема: все поля, которые входят в запрос с Sum или Count, выдают удвоенные значения. Как будто Sum, count выполняются дважды.

Текст запроса такой:

SQL
1
2
3
SELECT DISTINCTROW OU.id, OU.FullName, OU.ShortName, OU.OKPO, OU.INN, NasPunkts.SOATO, NasPunkts.SubjFed, NasPunkts.Rayon, NasPunkts.name, OU.Mail_index, OU.Address, OU.KorpusName, VedomPr.SOOGU, VedomPr.name, OU.Boss, OU.Job, OU.PhoneBoss, SUM(ObjNedv.S_full) AS Sum_s_full, SUM(ObjNedv.S_usefull) AS Sum_UseFull, SUM(GroundArea.RegAreaZU) AS Sum_RegArea_ZU, SUM(ObjNedv.ocen_bal_st) AS Sum_Ocen_bal_st, SUM(ObjNedv.ost_st) AS Sum_ost_st, SUM(ObjNedv.S_All_Bal) AS Sum_S_All_Bal, SUM(ObjNedv.S_Usfull_Ball) AS S_Usfull_Bal, OU.Number_Persons, SUM(ObjNedv.Plan_Remont) AS Sum_Plan_Remont, SUM(ObjNedv.Fact_Remont) AS Sum_Fact_Remont, SUM(ObjNedv.Plan_Buj) AS Sum_Plan_Buj, SUM(ObjNedv.Fact_Buj) AS Sum_Fact_Buj, SUM(ObjNedv.Plan_OutBuj) AS Sum_Plan_OutBuj, SUM(ObjNedv.Fact_OutBuj) AS Sum_Fact_OutBu, VidDeyateln.name, VidDeyateln.OKONH, COUNT(ObjNedv.name) AS CountObj
FROM ((((OU INNER JOIN VedomPr ON OU.VedomPrinad = VedomPr.id) INNER JOIN VidDeyateln ON OU.Vd = VidDeyateln.id) INNER JOIN NasPunkts ON OU.SOATO = NasPunkts.id) INNER JOIN GroundArea ON OU.id = GroundArea.idOU) INNER JOIN ObjNedv ON OU.id = ObjNedv.idOU
GROUP BY OU.id, OU.FullName, OU.ShortName, OU.OKPO, OU.INN, NasPunkts.SOATO, NasPunkts.SubjFed, NasPunkts.Rayon, NasPunkts.name, OU.Mail_index, OU.Address, OU.KorpusName, VedomPr.SOOGU, VedomPr.name, OU.Boss, OU.Job, OU.PhoneBoss, OU.Number_Persons, VidDeyateln.name, VidDeyateln.OKONH;

Ну как, есть идеи ?

@Victor Svetlov · 11.12.2007, 16:54

Безусловно, SUM выполняется для текущей выборки один раз. Вывод: а не дает ли выборка двойной результат? Ежели в результате объединения таблиц получается строк больше, чем хотелось бы. Уберите групповые операции, и просмотрите список. Если строк будет больше, чем нужно, то Вы быстро найдете, какая таблица в этом виновата.

Если не получится (у меня подобное случалось), сделайте так:
1. Создайте запрос без групповых операций, линейный.
2. Постройте к этому запросу второй запрос с групповыми операциями.

@AlexV0 · 11.12.2007, 20:25 **[ТС]**

Убрал я групповые операции и Sum операции, но дублирование строк осталось. Похоже не из-за Sum. Оно и без Sum дублирует строки.
Без таблицы ObjNedv все как надо работает без дублей. Как только я добавляю [ObjNedv].[name] (даже без Sum) и соответственно добавляю
INNER JOIN ObjNedv ON [OU].[id]=[ObjNedv].[idOU] в конце FROM, то появляется дублирование.
Из-за чего это может быть ?

Так с дублированием:

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
SELECT DISTINCT
[OU].[id],
[OU].[FullName],
[OU].[ShortName],
[OU].[OKPO],
[OU].[INN],
[OU].[Mail_index],
[OU].[Address],
[OU].[KorpusName],
[OU].[Boss],
[OU].[Job],
[OU].[PhoneBoss],
[VedomPr].[SOOGU],
[VedomPr].[name], 
[VidDeyateln].[name],
[VidDeyateln].[OKONH],
[NasPunkts].[SOATO],
[NasPunkts].[SubjFed],
[NasPunkts].[Rayon],
[NasPunkts].[name], 
[ObjNedv].[name],
 
SUM([GroundArea].[RegAreaZU]) AS Sum_RegAreaZU
 
FROM ((((OU INNER JOIN VedomPr ON [OU].[VedomPrinad]=[VedomPr].[id])
INNER JOIN VidDeyateln ON [OU].[Vd]=[VidDeyateln].[id])
INNER JOIN NasPunkts ON [OU].[SOATO]=[NasPunkts].[id])
INNER JOIN GroundArea ON [OU].[id]=[GroundArea].[idOU]
) INNER JOIN ObjNedv ON [OU].[id]=[ObjNedv].[idOU]
 
GROUP BY [OU].[id], [OU].[FullName], [OU].[ShortName], [OU].[OKPO], [OU].[INN], [OU].[Mail_index], [OU].[Address], [OU].[KorpusName], [OU].[Boss], [OU].[Job], [OU].[PhoneBoss], [VedomPr].[SOOGU], [VedomPr].[name],  [VidDeyateln].[name], [VidDeyateln].[OKONH], [NasPunkts].[SOATO], [NasPunkts].[SubjFed], [NasPunkts].[Rayon], [NasPunkts].[name],[ObjNedv].[name];

Так правильно (без дублирования):

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
SELECT DISTINCT
[OU].[id],
[OU].[FullName],
[OU].[ShortName],
[OU].[OKPO],
[OU].[INN],
[OU].[Mail_index],
[OU].[Address],
[OU].[KorpusName],
[OU].[Boss],
[OU].[Job],
[OU].[PhoneBoss],
[VedomPr].[SOOGU],
[VedomPr].[name], 
[VidDeyateln].[name],
[VidDeyateln].[OKONH],
[NasPunkts].[SOATO],
[NasPunkts].[SubjFed],
[NasPunkts].[Rayon],
[NasPunkts].[name],
 
SUM([GroundArea].[RegAreaZU]) AS Sum_RegAreaZU
 
FROM (((OU INNER JOIN VedomPr ON [OU].[VedomPrinad]=[VedomPr].[id])
INNER JOIN VidDeyateln ON [OU].[Vd]=[VidDeyateln].[id])
INNER JOIN NasPunkts ON [OU].[SOATO]=[NasPunkts].[id])
INNER JOIN GroundArea ON [OU].[id]=[GroundArea].[idOU]
 
GROUP BY
[OU].[id],
[OU].[FullName],
[OU].[ShortName],
[OU].[OKPO],
[OU].[INN],
[OU].[Mail_index],
[OU].[Address],
[OU].[KorpusName],
[OU].[Boss],
[OU].[Job],
[OU].[PhoneBoss],
[VedomPr].[SOOGU],
[VedomPr].[name],
[VidDeyateln].[name],
[VidDeyateln].[OKONH],
[NasPunkts].[SOATO],
[NasPunkts].[SubjFed],
[NasPunkts].[Rayon],
[NasPunkts].[name];

@Victor Svetlov · 12.12.2007, 15:52

Спасибо за четко выстроенный листинг

У Аксесса на сложных запросах иногда срывает крышу. Выхода два:

1. Замените INNER JOIN на LEFT JOIN (Если в конструкторе, то выбрать все строки из таблицы а и только те строки из таблицы б, которые совпадают. Если в тексте, то просто замените INNER на LEFT и уберите скобки. В первом случае можно также указать, что б.полеХ IS NOT NULL, но в данном случае не нужно.

2. Построить запрос до момента дублирования. Затем построить запрос к получившемуся запросу как объекту БД. Помогает.

@AlexV0 · 12.12.2007, 20:14 **[ТС]**

Спасибо. Ты действительно даешь дельные советы.
LEFT JOIN помогла, но не во всех случаях, но я ее использовал.
Этот запрос еще и разбил на 3 запроса.
После этого заработало.

Премного благодарен.

Тема закрыта!

Новые блоги и статьи Все статьи Все блоги /
Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .
модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .	Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .	Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ

@Victor Svetlov 0 / 0 / 0 Регистрация: 05.12.2007 Сообщений: 56
	11.12.2007, 16:54
	Безусловно, SUM выполняется для текущей выборки один раз. Вывод: а не дает ли выборка двойной результат? Ежели в результате объединения таблиц получается строк больше, чем хотелось бы. Уберите групповые операции, и просмотрите список. Если строк будет больше, чем нужно, то Вы быстро найдете, какая таблица в этом виновата. Если не получится (у меня подобное случалось), сделайте так: 1. Создайте запрос без групповых операций, линейный. 2. Постройте к этому запросу второй запрос с групповыми операциями. 0

@Victor Svetlov 0 / 0 / 0 Регистрация: 05.12.2007 Сообщений: 56
	12.12.2007, 15:52
	Спасибо за четко выстроенный листинг У Аксесса на сложных запросах иногда срывает крышу. Выхода два: 1. Замените INNER JOIN на LEFT JOIN (Если в конструкторе, то выбрать все строки из таблицы а и только те строки из таблицы б, которые совпадают. Если в тексте, то просто замените INNER на LEFT и уберите скобки. В первом случае можно также указать, что б.полеХ IS NOT NULL, но в данном случае не нужно. 2. Построить запрос до момента дублирования. Затем построить запрос к получившемуся запросу как объекту БД. Помогает. 0

@AlexV0 0 / 0 / 0 Регистрация: 08.08.2007 Сообщений: 184
	12.12.2007, 20:14 [ТС]
	Спасибо. Ты действительно даешь дельные советы. LEFT JOIN помогла, но не во всех случаях, но я ее использовал. Этот запрос еще и разбил на 3 запроса. После этого заработало. Премного благодарен. Тема закрыта! 0