LOVR > 2GB

[dirkjan]

Bij ons is de LOVR circa 2 GB.

Dit betekend dat hij de maximale grote bereikt heeft. Is er een beter oplossing dan de functie 3.6.5
Het is niet alleen een probleem dat de LOVR zijn maximale capaciteit heeft bereikt, maar ook overzichten draaien met behulp van 8.3.2.1 en je gaat echt op artikel niveau kijken dan duurt dit al snel een drie kwartier, Oke doe dit met behulp van een batch-opdracht 's avonds zou je kunnen zeggen, maar het ius niet echt handig.
Echter reorganiseren van de LOVR, 15 indexen die ieder circa 4 minuten duurt. Dat is echt lachen op een maandag ochtend tijdens orderpick.

Ik zelf zit te denken aan zoiets als een jaar afsluiting in te bouwen in Heart-Profit als dat mogelijk is.

Sta open voor vele suggesties en/of oplossingen. 

Dirk-Jan Gloudemans
LA

[Peter Stordiau]

De helft van de problemen die je aantoont kreëer je ook zelf. Immers, als je vindt dat je op een maandagochten moet reorganiseren ... tja.

Dàt het ding die grootte aan het krijgen is zie je aankomen, en dus kun je het "eeuwig" tijdig voor zijn.

De echte oplossing is natuurlijk een SQL/Server database. Dan heb je van dit soort zaken geen last.

[Peter Stordiau]

... maar ook overzichten draaien met behulp van 8.3.2.1 en je gaat echt op artikel niveau kijken dan duurt dit al snel een drie kwartier, Oke doe dit met behulp van een batch-opdracht 's avonds zou je kunnen zeggen, maar het ius niet echt handig.

Deze vergat ik nog : Als het goed is (!) duurt een Statistiek (e.d.) niet langer als een tabel groter is. Ja, natuurlijk wèl als de periode waarover je opvraagt ook groter is. Dan moet er immers domweg meer worden opgehoest.

Duurt het wèl langer bij een grotere tabel, maar vraag je steeds op over bijvoorbeeld de afgelopen maand, dan is er iets niet goed ...

[dirkjan]

Vaak willen we weten wat een winkel ten opzicht van het vorige jaar gedaan heeft.

Draai je dan een overzicht bijvoorbeeld relatie-groep/artikel-groep/ artikel kost circa 35 minuten.

Voor ons betekend het draaien van een jaaroverzichten altijd eerst enkele dagen en naar het scherm zettten.
Ten eerste om te voorkomen dat je een print krijg na veertig minuten van geen gegevens gevonden.
Maar nog veel erger :unsure:je hebt per ongeluk in getypt
artikel/ relatie-groep/artikelgroep en je gaat vervolgens koffie drinken. Reken maar dat je printer overuren gaat maken. Dit kost bomen en is dus slecht voor de natuur iets wat automatisering altijd pijn doet.

Dirk-Jan Gloudemans
LA

[Peter Stordiau]

Het spijt me werkelijk, maar ik kan niet zien op welke manier je inhaakt op mijn laatste post. Zo te zien "niet". 

[Johan]

Probeer het eens met MS Access. voeg LOSU en / of LOST (Even afhankelijk van het type statistiek) toe als tabel aan MsAccess en ga er naar hartelust mee stoeien. Hint: zet die tabellen apart neer, want binnen de kortste keren is die tabel weer verdwenen als je een andere functie in Heart start.

In MS Access kun je met behulp van queries precies datgene opvragen wat je wilt. Dat scheelt je heel wat pakken papier, want ik kan me niet voorstellen dat je al die blaadjes stuk voor stuk doorneemt. Overigens geldt dit niet alleen voor MS Access, ook andere programma's zijn daarvoor beschikbaar.

[mdekraa]

Voor dat bomen verhaal is toch print to scherm en export naar excel voor uitgevonden.

Maar ff serieus, als je elke week die overzichten draait moet je misschien toch een met Peter kijken naar de batch functionaliteit en alle zware overzichten op zondag laten genereren. (ik ga ervan uit dat jullie dan meestal dicht zijn)

Het probleem is niet echt database gerelateerd. Hoewel "nieuwe" databases zoals oracle en zo wel een "geheugen" hebben mbt de opgevraagde data en die wat langer bufferen om de performance te verbeteren. Wat wel heel veel scheelt is het uitvoeren op een zware machine met veel intern geheugen en een GB lijntje naar de server...)

Access is inderdaad soms een oplossing. Maar als je niet echt handig bent kun je beter de Office 97 versie gebruiken wantr die ondersteunt nog direct de Foxpro tabellen. In de nieuwe versie moet je met ODBC drivers dat soort zaken oplossen...

[dirkjan]

Hallo Mdekraa

Het problemen van de bomen ontstaat als je perongeluk zoals ik al eerder aangaf omzet op
debiteur-rubriek/debiteur/ artikel/  dit is niet echt groot

Type je nu bijvoorbeeld

debiteur-rubriek/artikel/debiteur/ dan ontstaat een bestand dat volgens mij ook niet te exporteren is naar excell. bere groot. En alleen omdat je een type fout maakt in het slectie menu.

Je ander opmerking het gebruik van access95 gaat perfect alleen als je de LOVR wilt bekijken of er een overzicht uit wilt halen wat ze hier in het verleden nogal wart deden dan duurt dat ook al gauw een kwartier tot 20 minuten. Want nu komt het probleem van ontbrekende indexen.

Al met al resulteerde het bovenstaande dat we wat minder willen weten, inderdaad wat overzichten maken in het weekend. En daar kunnen we prima mee leven.

Groetjes Dirk-Jan Gloudemans
LA