Temat: Raport na Commandzie odczytuje wiecej rekordow niz sam...

Mam raport na Commandzie podczas generowania odczytuje znacznie wiecej rekordow niz dostaje w wyniku SELECTa bezposrednio na bazie, np. Select do bazy zwraca 463 rekordy, raport odczytuje ponad 10 000 rekorodw. Z tym ze zawartosc raportu, wczytanych danych jest poprawna.

W raporcie mam 3 poziomy grupowania.

Poziom 1 - grupowanie po pole1_ID rekordu.
Na tym poziomie w oddzielnych sekcjach Group Headera (Group Header 1a, Group Header 1b...) wyswietlam dane zwiazane z polem pole1_ID

Poziom 2 - sztuczna grupa na potrzeby wyswietlania headerow tabeli na kazdej stronie jesli sa potrzebne
WhileReadingRecords;
true

Poziom 3 - grupowanie po pole2_ID rekordu.
W tej grupie w Group Headerze wyswietlane sa dane w kolumnach dla pole2_ID.
Wrzucenie tego do Details powoduje duplikacje rekordow na poziomie pole2_ID.

pole1_ID moze miec wiecej niz jedno pole2_ID.
Glowny Select/Command ma wstawione warunki dla dwoch parametrow (stringi).
W raporcie mam drugi Command (nie jest polaczony z glownym Commandem), do ktorego przyrownuje wartosci w/w parametrow.

Bede wdzieczny za pomysly, sugestie.Ten post został edytowany przez Autora dnia 16.12.13 o godzinie 14:46

Temat: Raport na Commandzie odczytuje wiecej rekordow niz sam...

Jeśli masz 2 commandy, które nie są ze sobą połączone to prawdopodobnie powstaje iloczyn kartezjański.

Temat: Raport na Commandzie odczytuje wiecej rekordow niz sam...

Odpowiadam z opoznieniem.

Powodem zaczytywania za duzej liczby rekordow bylo odwolanie sie do parametrow w dwoch miejscach:
1. W Commandzie
2. W Selection formula z przyrownaniem do pola z drugiego Commanda.

Parametry sa w kaskadzie z dynamiczna lista wartosci przechowywana w repozytorium.

Usuniecie odwolania z Selection formula rozwiazalo problem.

Temat: Raport na Commandzie odczytuje wiecej rekordow niz sam...

Kilka dobrych rad przy stosowaniu Command:

1. Nie należy łączyć ze sobą kilku Command lub Command z tabelą/widokiem bezpośrednio crystalu.
Zamiast tego należy przepisać zapytanie ze złączenia do jednego command. Dzięki temu zapytaniem zajmie się motor bazy danych i prześle tylko wynikowe dane. W przeciwnym razie to Crystal Reports pobiera dane z poszczególnych źródeł i ostro walczy na komputerze klienta co objawia się bardzo wolnym generowaniem raportu.

2. Nie filtrować command za pomocą standardowej opcji Selection Formula.
Zamiast tego należy dodać where do zapytania SQL w Command. Dzięki temu filtrowanie będzie po stronie bazy danych z użyciem indeksów (jeśli istnieją). W przeciwnym Crystal Reports pobiera wszystkie dane z Command i filtruje lokalnie, co najczęściej prowadzi do bardzo wolnego generowania raportu i zapychania łączą.

3. Nie używać standardowych parametrów do filtrowania Command.
W Command jest osobna opcja do tworzenia parametru. Wartość tego parametru będzie doklejona do zapytania SQL i przetworzona po stronie bazy danych. To również przyspieszy przetwarzanie raportu.
Niestety parametry typu command są uboższe od standardowych, ale w większości przypadków wystarczają.

4. Zastąpić Command procedurą składowaną (o ile mamy takie uprawnienia i umiejętności)
Źródłem raportu może być procedura składowana (stored procedure). Jeśli procedura posiada jakieś parametry to Crystal Reports utworzy na ich podstawie standardowe parametry w raporcie.

Procedura składowana będzie wydajniejsza niż Command, gdyż plan wykonania oraz jej kompilacja będzie odkładana w cache'u bazy danych. Kolejne wywołania będą szybsze niż poprzednie, czego nie można uzyskać przy command, bo są to dla bazy danych, kolejne nowe zapytania SQL i musi je za każdym na nowo przetwarzać.Ten post został edytowany przez Autora dnia 09.01.14 o godzinie 18:37

Temat: Raport na Commandzie odczytuje wiecej rekordow niz sam...

Rady przydatne, thx, pozwole sobie dopisac komentarze.

Marcin S.:
Kilka dobrych rad przy stosowaniu Command:

1. Nie należy łączyć ze sobą kilku Command lub Command z tabelą/widokiem bezpośrednio crystalu.
Zamiast tego należy przepisać zapytanie ze złączenia do jednego command. Dzięki temu zapytaniem zajmie się motor bazy danych i prześle tylko wynikowe dane. W przeciwnym razie to Crystal Reports pobiera dane z poszczególnych źródeł i ostro walczy na komputerze klienta co objawia się bardzo wolnym generowaniem raportu.

Co jesli interfejsem do odpalania raportu jest platforma Bussiness Objects i user generuje raport via Internet Explorer ? Gdzie wowczas odbywa sie wspomniana 'walka' ?

2. Nie filtrować command za pomocą standardowej opcji Selection Formula.
Zamiast tego należy dodać where do zapytania SQL w Command. Dzięki temu filtrowanie będzie po stronie bazy danych z użyciem indeksów (jeśli istnieją). W przeciwnym Crystal Reports pobiera wszystkie dane z Command i filtruje lokalnie, co najczęściej prowadzi do bardzo wolnego generowania raportu i zapychania łączą.

Aktualnie mam raporty na Commandach z opcjonalnymi parametrami - stringi, liczby, daty z wartosciami wpisywanymi z palca. 'Opcjonalnosc' wymaga wowczas obsluzenia/przypisania jakies wartosci dla null-i

3. Nie używać standardowych parametrów do filtrowania Command.
W Command jest osobna opcja do tworzenia parametru. Wartość tego parametru będzie doklejona do zapytania SQL i przetworzona po stronie bazy danych. To również przyspieszy przetwarzanie raportu.
Niestety parametry typu command są uboższe od standardowych, ale w większości przypadków wystarczają.

W raportach wykorzystuje LOVy (kaskadowe) tworzone w Business View Managerze i w raporcie najpierw tworze 'standardowo parametr i podpinam sie do utworzonego LOVa. Nastepnie w Commandzie majac paramatery w SELECT-cie, tworze parametry o tej samej nazwie co wczesniej utworzone parametry z LOVa - jezeli najpierw utworze parametry w Commandzie, wowczas nie bede w stanie podpiac sie do LOVa w standardowej edycji parametru.

Natomiast pytanie - dlaczego nie nalezy uzywac standardowych parametrow nietworzonych w Commandzie?

4. Zastąpić Command procedurą składowaną (o ile mamy takie uprawnienia i umiejętności)
Źródłem raportu może być procedura składowana (stored procedure). Jeśli procedura posiada jakieś parametry to Crystal Reports utworzy na ich podstawie standardowe parametry w raporcie.

Procedura składowana będzie wydajniejsza niż Command, gdyż plan wykonania oraz jej kompilacja będzie odkładana w cache'u bazy danych. Kolejne wywołania będą szybsze niż poprzednie, czego nie można uzyskać przy command, bo są to dla bazy danych, kolejne nowe zapytania SQL i musi je za każdym na nowo przetwarzać.

Tak procedury i funkcje bardzo pomocne, jednak nie zawsze jest 'polityczna' mozliwosc ich utworzenia/stosowania ;) nawet jesli raport generuje sie 30+ minut.