Może to jest proste tylko jakoś na to nie wpadłem - proszę o pomoc w
takiej sprawie:
Mam bazę o firmach i ich różnych cechach, z których każda w osobnej
tabeli, najważniejsze z nich to: pracownicy, maszyny i działania
serwisowe (na konkretnej maszynie). Chciałbym stworzyć raport
zawierający to wszystko, ale pogrupowane: firma > jej pracownicy,
firma > jej maszyny > serwisowanie każdej z nich. Nie bardzo wiem,
jak zgrupować raport, żeby w ramach danej firmy najpierw pojawiła mi
się informacja o samej firmie (tj. jej danych ogólnych), w ramach
firmy o jej pracownikach (tu można zrobić zwykłe grupowanie) a potem
(UWAGA UWAGA) w ramach tej samej firmy informacja o jej maszynach a w
ramach każdej maszyny jej serwisowanie. Grupowanie wielostopniowe nie
jest chyba właściwym tropem, bo przecież maszyny nie są cechą
podrzędną pracowników. A problem niestety jest troszkę bardziej nawet
złożony, bo jeszcze mam tabelę "złożone oferty" i "przyjęte
zamówienia".
Czy muszę "pisać" taki raport dynamicznie, z poziomu Visual Basica czy
też da się to zrobić robiąc jakąś sprytną kwerendę (złożoną?) i
ustawiając jakieś cechy raportu?
A może po prostu ukrywać w raporcie pola niepotrzebnie się
powtarzające? Ale wtedy porobią mi się dziury, będę musiał je jakoś
usuwać, uchch, no po prostu nie mam idei, proszę o pomoc.
--
Pozdrowienia
KoJot
> Czołem!
>
> Może to jest proste tylko jakoś na to nie wpadłem - proszę o pomoc w
> takiej sprawie:
>
> Mam bazę o firmach i ich różnych cechach, z których każda w osobnej
[...]
> jak zgrupować raport, żeby w ramach danej firmy najpierw pojawiła mi
> się informacja o samej firmie (tj. jej danych ogólnych), w ramach
> firmy o jej pracownikach (tu można zrobić zwykłe grupowanie) a potem
> (UWAGA UWAGA) w ramach tej samej firmy informacja o jej maszynach a w
> ramach każdej maszyny jej serwisowanie. Grupowanie wielostopniowe nie
> jest chyba właściwym tropem, bo przecież maszyny nie są cechą
> podrzędną pracowników.
Pachnie mi to dwoma albo trzema podraportami. Jeden raport główny z
firmą/firmami oraz dwa podraporty: jeden z pracownikami, drugi z maszynami,
zlinkowane z głównym po polu FIRMA_ID (lub podobnym)
> A problem niestety jest troszkę bardziej nawet
> złożony, bo jeszcze mam tabelę "złożone oferty" i "przyjęte
> zamówienia".
Każdy problem jest zawsze jeszcze trochę bardziej złożony :)
> Czy muszę "pisać" taki raport dynamicznie, z poziomu Visual Basica
Brr, wystrzegam się takich "dynamiczności", sensownym wyjątkiem jest chyba
tylko KaeNowy mde2mdb.
> czy
> też da się to zrobić robiąc jakąś sprytną kwerendę (złożoną?) i
> ustawiając jakieś cechy raportu?
[...]
To też jest dobre podejście. Wszystko zależy od tego jak masz zebrane dane
w tabelach. Podejście "kwerendowe" może nieco uprościć samą strukturę
raportu.
--
PL
> Czołem!
>
> [...]
Ja takie raporty robię na podstawie kwerend składających (np. z takich
mało_ze_sobą_związanych danych jak sprzedaż, wpływy zapłat na konto,
reklamacje, korekty, ...).
Trzeba odpowiednio ustawiać kolumny (pokombinować a raczej komponować różne
dane w te same kolumny). Tam gdzie dziury są nieuniknione pozostawiam puste
lub czasem napis "nie dotyczy", czy coś równie zabawnego.
Trzeba tylko uważać na sumy jeśli w kolumnie są i dane liczbowe i dane
innego typu.
Pozdrawiam.
I tu masz problem. Dlaczego kazda firma w osobnej tabeli? Powinna byc
jedna tabel np. tblFirmy.
BarneyG :o)
Eee, no żartujesz sobie, co nie? W osobnej tabeli są różne cechy.
Tabela "Firmy" to id, nazwa i dane teleadresowe. "Pracownicy"
podobnie, tylko jeszcze id_firmy, maszyny analogicznie (też id_firmy),
serwisowanie maszyn też (tyle że zamiast id_firmy w tabeli
"serwisowanie" jest obok danych o serwisowaniu umieszczony
id_maszyny). Każda firma w osobnej tabeli to przecież koszmar, już
wpaść na taki pomysł to trzeba mieć poczucie humoru albo mieć jakieś
głębsze (np. 40% :)) uzasadnienie.
--
Pozdrowienia
KoJot
> Pachnie mi to dwoma albo trzema podraportami.
O rety - jakie proste. Po prostu czytając guzik "podformularz" jakoś
nigdy nie auważyłem że tam jeszcze jest "/podraport" :) i do tej pory
nie wiedziałem, że takie coś jest. Okazuje się, że można od iluś lat
robić okazjonalnie (w moim przypadku średnio raz na 2 lata) bazy w
accessie i nie wiedzieć o istnieniu podraportów :)
Dzięki bardzo, dzięki serdeczne.
--
Pozdrowienia
KoJot
> Powinna byc jedna tabel np. tblFirmy.
Nie dopisałem poprzednio - tak, tak, tak właśnie mam!
--
Pozdrowienia
KoJot
Barney :D
| Czy muszę "pisać" taki raport dynamicznie, z poziomu Visual Basica czy
| też da się to zrobić robiąc jakąś sprytną kwerendę (złożoną?) i
| ustawiając jakieś cechy raportu?
są dwa podejścia:
1) raport i podraporty
2) sprytna kwerenda UNION
ad 2.
Select
1 as cos
, {inne pola}
, Null as ...
, Null as ...
From
TabelaGlowna
Inner Join
Tabela1
ON
...
UNION ALL
Select
2 as cos
, {inne pola}
(...)
From
TabelaGlowna
Inner Join
Tabela2
ON
...
Inner Join
Tabela3 ...
i w raporcie grupowanie wielopoziomowe, oczywiście m.in. na polu "coś"
Jedyny mankament, że UNION wymaga równej ilości pól (stąd "uzupełniające"
Null'e).
Oraz wypadałoby aby pola z podtabel były jakoś podobne (nazwisko <> nazwa
maszyny, wiek <> numer seryjny, itp.)
(choć w zdarzeniu OnFormat można też dowolnie żonglować pozycjami i
rozmiarami pól, posiłkując się zawatością pola "coś" ...)
Z całą pewnością rozwiązanie z podraportami jest bardziej naturalne, ale w
pewnych sytuacjach rozwiązanie z UNION może być korzystniejsze ...
--
KN
(MVP, M$ Office Access)
archiwum grupy:
http://groups.google.pl/advanced_group_search
(grupa: pl*msaccess)
|| Czy muszę "pisać" taki raport dynamicznie, z poziomu Visual Basica czy
|| też da się to zrobić robiąc jakąś sprytną kwerendę (złożoną?) i
|| ustawiając jakieś cechy raportu?
|
| są dwa podejścia:
| 1) raport i podraporty
| 2) sprytna kwerenda UNION
ops! w zasadzie Przedpiścy napisali to samo ...