Snelheid rapport

Jopje

Beste forummensen,

hetgeen is aan de hand:

omdat het aanschaffen van Table Designer vanaf mijn kant niet is doorgegaan. Moest ik een andere manier vinden om rapporten te genereren.

Nu ben ik al zover dat ik een omzetoverzicht van 1 jaar kan weergeven en het weergeven van een vergelijkingsperiode zal ook niet al te moeilijk zijn.

ECHTER... duurt het eeuwen (langer dan 20min) voordat het rapportje eindelijk klaar is met genereren.
Heb waarschijnlijk ergens een fout gemaakt (anders duurde het niet zo lang) en nu vraag ik mij af waar die fout ergens kan zitten. Ennuh aan mijn laptop ligt het niet O:)



_ = indent.

Gen. Business Posting Group

_Gen. Product Posting Group
SETFILTER("Gen. Product Posting Group".Code, '> 1000');

__Sales Invoice Header
RESET;
SETRANGE("Gen. Bus. Posting Group", "Gen. Business Posting Group".Code);
SETFILTER("Posting Date", Filter_String);


___Sales Invoice Line
DataItemLink > Document No.=FIELD(No.)
SETRANGE("Gen. Prod. Posting Group", "Gen. Product Posting Group".Code);
SETFILTER(Amount, '<> 0');

Mocht het niet duidelijk zijn, wil ik de .fob altijd opsturen.

VOORBEELD UITVOER:

Bakkerij grossier < Bus. Group

(1)BAK GROSS_ACTIES_-5_-33,63 (Bus. Group./Prod.Group/Sales Invoice Header (totaal van alle lines die voldoen aan BAK GROSS_ACTIES)
-5,00_-33,63

(2)BAK GROSS_ACTIES_-1_-628,58
-6,00__-662,21

(3)BAK GROSS_ACTIES_-1_-1.991,68
-7,00__-2.653,89 <=- Totaal van 1 , 2 , 3

et.

Marije_Brummel

Hoi Remco,

Heb je bij je dataitems ook sleutels opgegeven die de velden bevatten waarop je filtert?

Als je dit niet doet ben ik bang dat het lastig wordt om het rapport sneller te maken.

jhoek

Zonder inhoudelijk op je rapport in te gaan: zet de Client Monitor aan, run het rapport, en zet de Client Monitor aan. Rapporten zijn namelijk (bijna?) nooit traag, maar sommige rapporten laten de server een enorme bak werk verzetten - en dat kost gewoon wat tijd!

Bekijk na afloop de resultaten van de Client Monitor. Worden voor bepaalde akties te veel records gelezen? Kan, met toepassing van de juiste sleutels, het aantal te lezen records worden verkleind? Worden sommige records >1 keer gelezen (in dat geval kan locaal bufferen uitkomst bieden)? Duren bepaalde akties langer dan ~ 10 ms?

Jopje

Die heb ik zeker.

Gen. Business Posting Group
SORTING(Code) ORDER(Ascending)

Gen. Product Posting Group
SORTING(Code) ORDER(Ascending)

Sales Invoice Header
SORTING(No.) ORDER(Ascending)

Sales Invoice Line
SORTING(Document No.,Line No.) ORDER(Ascending)
met dataitemlink Document No.=FIELD(No.)


Clientmonitor, weer iets nieuws voor mij.. nog niet mee gewerkt want ben nog geen performance-issues tegen gekomen. Is disabled (licht grijs)

Ps. Voor elke klantengroep een productgroep. Ongeveer 12 * 20.
Dan elke 'factuur' (aardig wat dus) en daarvan de lijnen... enorm veel dus, filter al op klantengroep, productgroep en boekingsdatum.

Marije_Brummel

Je sorteert de verkoopfactuur op nummer terwijl je op boekingsgoeps filtert :?

Voor de client monitor heb je een licentie nodig

Jopje

Er zijn hier bij mij maar een beperkt aantal mogelijkheden om te sorteren:

Sales Invoice Header:
No.
Order no.
Pre-Assigned No.
Service Mgt. Document
Sell To Customer, Ext. Document No.
Sell To Customer, Order Date
Sell To Customer, No.
Bill-to Customer No.
Posting Date

Sales Invoice Line
Document No, Line No.
etc..
Gen. Bus. Posting Group

De reden dat ik heb gefilterd op Document No. is omdat ik eerst filter op de header (productgroep) en dan moet ie gelijk de lijnen in dat document vinden voor optelling.
Dit heb ik tevens nodig om te kunnen filteren op Boekingsdatum..
Dimensies zijn niet ingericht om hierop een rapportageschema te maken..

Marije_Brummel

Aangezien je ook op boekingsdatum filtert zou je kunnen proberen of deze sleutel sneller is...

Anders moet je ff de afd. support van je solution center bellen om een sleutel op boekingsgroep/boekingsdatum te maken.
8)

Of ff pb-tje sturen

Succes...

Jopje

Zal ik morgen, als ik dus niet thuiswerk, even een mailtje sturen.
Hoop niet dat er kosten aan verbonden zijn, want dan moeten we dit weer in overleg gooien, wat weer een aantal dagen wachttijd kan kosten

Kan gelukkig altijd nog wel vooruit met het werk wat ik hier heb liggen.

DenSter

Filteren op velden die niet in de sleutel zitten is vragen om snelheids problemen, zeker als de tabellen veel records bevatten. Je zal waarschijnlijk een nieuwe sleutel moeten aanmaken.

Ik denk dat ik de business group en product group weg zou laten, en het zou oplossen door sales header te groeperen op business groep, and de line op product group.

Jopje

Okeej, maar als ik dat doe, dan verminder ik inderdaad het aantal doorzochte records...

Echter.. hoe krijg ik de uitvoer dan net zoals in het voorbeeldje hier:

http://members.home.nl/jopje/navision/uitvoer_rapport.gif

Met grouptotal en dan met groupfooter.. neem ik aan...
want de volgende stap is het genereren van een voorgaande periode en dan een vergelijking (verschil, marge, groei etc..).

DenSter

Mmmmmmmm vlaai........... :shock:

Sorry, wat zei je ook alweer? 8)

Marije_Brummel

Vlaai.. Heb je dat ook in de USA? Of alleen donuts. O:)

Daar gaat weer een topic....

DenSter

Je kan dat rapport maken met alleen maar een Sales Line dataitem, die tabel heeft allebei de posting groups.

Maak een sleutel aan met die twee velden. Maak een nieuw rapport aan met de Sales Line, en gebruik de wizard. In de wizard geef je vervolgens je totaalvelden en je groepvelden aan, en als het goed is doet Navision de rest voor je. Op dat moment hoef je alleen maar je sections bij te werken.

Jopje

Maar helaas bevatten die lijnen geen Boekingsdatum
Die staat weer in de header ervan #-o

Mark Brummel: Het moest nog even geheim blijven, maar ik wilde tegen het eind van mijn stage een vlaai richting Apeldoorn sturen. (of een quiche) als dank voor de hulp, maaruh.. niet verder vertellen :-$

Sleutels aanmaken? SETCURRENTKEY of is het met 'Table Designer', want die hebben we toch maar niet aangeschaft...

62.000+ records aan factuurregels O:)

Marije_Brummel

Ik heb niets gehoord :whistle: maar ga naast de brievenbus zitten programmeren denk ik

Marije_Brummel

O, ja. Om sleutels aan te maken heb je inderdaad tabledesigner nodig.

Waarom koop je die niet? Hij kost niets. Evenveel als 10 tabellen en die krijg je er gratis bij.

Dus

(10 tabellen) = evenduur als (10 tabellen + tabledesigner) 8)

Jopje

Table Designer neemt ook een grote verantwoordelijkheid met zich mee, zoals eerder is gezegd. Echter heb ik wel vertrouwen in mijzelf, maar weet niet hoe toekomstige stagiaires ermee om gaan...

Daarnaast is er een groot risico dat performance teruggaat mocht er een verkeerde koppeling zijn.

Zie topic

goldeneye

Zonder Table Designer kun je inderdaad geen sleutel aanmaken. En dat is juist wat je nodig hebt...

Ik zou in jouw plaats een "bold new strategy" aannemen:
- In een apart Dataitem de Sales Lines al zoveel mogelijk filteren op sleutel
- In dat dataitem de data overzetten in een temp-tabel voor zoverre de boekingsdatum van de header binnen de range ligt. Dit zal inderdaad vereisen dat je ALLE lijnen overloopt --> best een progressbar op programmeren.
- Dan daarNA geneste dataitems voor produkt en bedrijfsboekingsgroepen
- In het diepste dataitem filter je je temp-tabel op de twee groepen en kopieer je alles naar een 2e temp
- In dat dataitem steek je nog een dataitem van type Integerwaarmee je je tweede temp overloopt en op secties zet.

De snelheid zit hem in het feit dat je je data cached in RAM-geheugen (je PC moet dus wel een jaar aan regels in RAM kunnen houden) en daar dan de bewerkingen op doet. Dit zou VEEL sneller moeten gaan. De enige wachttijd zit hem dan in het eerste stuk waar de lijnen ingeladen moeten worden.

Jouw eerste algoritme is een licht n^4-algoritme. Dit is een zwaar n-algoritme. Voor "voldoende" gegevens is een n-algoritme sneller dan een n^2-algoritme. Laat staan een n^4 !!