VBcode rapport opslaan als PDF

[Bospeen]

De gebruikers zeggen dat ze in die 20 seconden echt helemaal niks anders doen dan wachten op de gereedmelding.

 

[JohanRVT]

Dat is toch een fantastisch lange tijd gezien je zogezegd lokaal afdrukt? Is dat document dan zo zwaar dat er in tussentijd ene time-out optreedt?

 

[Bospeen]

Dat is inderdaad erg lang. Echter... de code slaat het rapport (op basis van één selectiequery) niet op C op, maar op een netwerk-locatie.
Dit vertraagt natuurlijk wel, maar 20 seconden wel érg lang is en wonderlijk genoeg... sommige gebruikers hoeven maar 3 seconden te wachten(!).

NB. het complete pad naar de netwerk-locatie mag ik uit veiligheidsoverwegingen niet vermelden.

Zou het kunnen uitmaken of het rapport is gemaakt op basis van een (opgeslagen) query of een SQL statement?

 

[JohanRVT]

Allez, we weten nu dat je over een netwerk naar ergens een hard gecodeerde C:\ probeert te schrijven. Is dit een intern bekabeld netwerk of komt er wifi of internet aan te pas gezien de wisselende snelheid? Je kan het snelheidsverlies bv ook daar gaan zoeken?

 

[Bospeen]

Excuus Johan, ik ben niet zo duidelijk geweest.
Deze code

DoCmd.OutputTo acOutputReport, "Rapport_1", acFormatPDF, "C:\ARCHIEF\" & etc.

is maar een voorbeeld. In werkelijkheid wordt er niet naar C:\ARCHIEF\ opgeslagen, maar naar een andere netwerk-locatie (die ik uit veiligheidsoverwegingen niet mag vermelden).

Overigens heb ik het acFormatPDF eens vervangen door acFormatRTF en dan werkt de code wel razendsnel. Ik ben erg benieuwd of er nu nog gebruikers zijn die tegen de storing aanlopen.

 

[JohanRVT]

Zomaar iets anders neerzetten als voorbeeld kan je toch niet verwachten dat de groep kan raden wat de fout is. Wat dat RTF formaat betreft,is de lay-out van je rapport niet belabberd en dan kan er met de data in het rapport nog gewerkt worden? Of speelt dat geen rol?

 

[OctaFish]

In werkelijkheid wordt er niet naar C:\ARCHIEF\ opgeslagen, maar naar een andere netwerk-locatie (die ik uit veiligheidsoverwegingen niet mag vermelden).

Dat moet dan een waanzinnig slecht beveiligd netwerk zijn, dat je op basis van een naam al in staat moet worden geacht om de bedrijfsorganisatie te hacken . Of hebben jullie zo'n waanzinnig mooie mappenstructuur bedacht dat jullie daar patent op gaan aanvragen? . Wij zijn echt niet geïnteresseerd in de bedrijfsstructuur, maar dus wél in het correct aanleveren van de werkwijze die van invloed is op je probleem. En dat is hier het geval.

Ik raad je aan, als je PDF-jes wilt maken, om dat te doen op de snelste schijf, en dat zal best wel de C-schijf zijn. Elk rapport is sowieso op te vragen uit een db, en dat net zo vaak als de gebruiker dat wil. En de informatie zal al die keren nog krek hetzelfde zijn ook. Hooguit bewaar je rapporten als je ze wilt versturen naar een klant o.i.d., verder lijkt mij het bewaren van gegenereerde informatie die toch al herhalend opvraagbaar is een beetje onzinnig. En de rapporten die je verstuurt, zitten al in de mails die je verstuurt, dus daar hoeft het ook niet voor. Maar je zou niet bij het eerste bedrijf werken dat geen enkel vertrouwen in zijn eigen organisatie heeft, en dus de duvel en zijn ouwe moer bewaart.

Wat ik dus zou doen, is het rapport genereren op de C-schijf (in een Temp map desnoods, daarna versturen als dat gewenst is, en daarna, als je toch wilt archiveren, kopiëren of verplaatsen van de C-schijf naar die supermooie netwerkschijf. Gaat vast ook een stuk sneller.

 

[Bospeen]

Wáár het Pdf-bestand precies wordt opgeslagen kan niet de oorzaak van de fout zijn en omdat ik nu eenmaal geen enkele bedrijfsinterne informatie mag prijsgeven heb ik de code aldus het voorbeeld aangepast.
De Pdf's opslaan op C is overigens geen optie: het betreft hier een centraal archief, dat voor alle gebruikers benaderbaar moet zijn. Via C opslaan lijkt me wel een goede suggestie, dat had ik nog niet geprobeerd.
Om het rapport fatsoenlijk in RTF te tonen moest ik inderdaad wat aanpassingen doen, maar het gaat hier gelukkig niet zozeer om de layout, slechts de data zelf is belangrijk.
Ik ben het overigens volledig met je eens dat men vaak wel héél veel nodeloos wil bewaren... ook in dit geval is alle data al immers voorhanden in de centrale DB.

 

[JohanRVT]

Wij maken een soort van historiek van onze personeelsbezetting van de instelling aan de hand van een PDF rapport wegschrijven naar een bepaalde locale map van de volledige FTE bezetting op het moment van de eerste maal afsluiten van de database. In de naamgeveing van dat bestand verwerken we de afdrukdatum en zo meer; zo kregen we door de jaren heen een gedetailleerd chronologisch evolutie overzicht.

 

[OctaFish]

@Johan: Lijkt mij een soort overzicht dat je te allen tijde altijd uit de database zou moeten kunnen trekken. In mijn systeem hoef je in ieder geval daar geen rapporten voor te genereren en op te slaan. Kun je die informatie (en heel flexibel uiteraard) gewoon opvragen in de database. Lijkt mij ook dat dat op die manier zou moeten kunnen. Exports voegen daar helemaal niks aan toe.

 

[JohanRVT]

Daar heb je gelijk in maar soms moet je een keuze maken wegens tijdsgebrek; om van een rapport met een 14-tal tabellen in via evenveel subrapporten (ziekte, ouderschapsverlof, moederschapsverlof, tijdskrediet, pensioenen, opleidingen, etc....) de historiek per personeelslid bij te houden dat een hoop extra tabellen en werk vraagt. En ik voer eigenlijk ook maar uit hetgeen de bazen vragen of nodig hebben.

 

[OctaFish]

Dat laatste is wel vaker een bottleneck als het gaat om een rustige werkplek .