huidig record mailen

Status
Niet open voor verdere reacties.
M

moensk

Gebruiker
Lid geworden
23 jun 2013
Berichten
778
Heb een script achter knop hangen om vanuit formulieren een rapport te mailen
doch hij mailt alle records
ik had graag het huidige record laten mailen
HTML: 
Private Sub Mailen_Click()
On Error GoTo Err_Mailen_Click
DoCmd.SendObject acSendReport, "rpt_inslag", acFormatPDF, , , , "testmail"
Exit_Mailen_Click:
    Exit Sub
Err_Mailen_Click:
    MsgBox Err.Description
    Resume Exit_Mailen_Click
End Sub
 
Het script doet precies wat je vraagt: een rapport mailen. Er wordt nergens over een filter in welke vorm dan ook gepraat, dus dan doet-ie dat ook niet. Das logies hè (zoals onze overleden filosoof JC reeds zei) :). Je zult dus het rapport moeten filteren. Veel mensen doen dat (in mijn ogen) veel te omslachtig, door het rapport gefilterd te openen vanuit het formulier en van daaruit af te drukken. Kan verder natuurlijk wel. Ik vind het veel slimmer om, als je het rapport toch vaak gefilterd wilt afdrukken, om de onderliggende query aan te passen met het filter.
Zoek in dit forum maar eens naar de term ‘QueryDef’ waarin ik de techniek uitleg. In essentie komt het hier op neer:

1. Baseer je rapport op een vaste query. (Doe je waarschijnlijk al)
2. Maak op je formulier een query die alle velden voor je rapport bevat (gebruik als basis de query van je rapport)
3. Zet in die query het filter op het gewenste record
4. Definieer een QueryDef die je koppelt aan die query
5. Wijs de nieuwe query uit stap 3 toe aan de eigenschap SQL van de QueryDef

Nu heb je middels VBA de SQL code van de query veranderd, en daar zit dus nu het filter in van je formulier. Als je nu het rapport opent, afdrukt of mailt, krijg je het geselecteerde record.

Om het helemaal af te maken, kun je de oorspronkelijke query nog weer terugzetten op het rapport, als je die ook bewaart. Meestal doe ik dat niet eens, want ik pas de query de volgende keer toch weer aan.
 
Stap 3 is eigenlijk een stap die je doet in de code waarmee je dus de SQL string opbouwt die je wilt gebruiken voor je mailing. Wat ik dus meestal doe:
1. ik maak de query die het rapport nodig heeft, maar nog even zonder filter. Of, als je het jezelf makkelijk wilt maken, zet je daar alvast een criterium in waarmee je een gefilterd rapport kunt maken.
Die query hoef je niet op te slaan, maar je hebt dus wel de SQL daarvan nodig. Die kopieer je dan vanuit het SQL venster van de query.
2. De gekopieerde query plak ik bij de code van de knop. Die query is nu nog niet bruikbaar, omdat er misschien op tekst wordt gefilterd (dan doet-ie het sowieso niet omdat de quoots niet kloppen) en omdat hij is gefilterd op vaste waarden. Die waarden moet je dus vervangen door de bijbehorende formuliervelden.
3. Als de query is aangepast, zet ik hem soms tijdelijk in een Inputbox zodat ik het resultaat kan kopiëren en in een nieuwe query kan plakken om te kijken of hij ook werkt. Als dat zo is, dan volgt stap
4. Wijs de SQL van de aangepaste query toe aan de SQL eigenschap van de QueryDef.

En dat is dan alles; want nu heeft de query die onder het rapport hangt, een nieuwe SQL (filtering) gekregen. En kun je dat rapport dus probleemloos mailen. Ik kijk er zo wel even naar; op een iPad kan ik geen Access draaien.
 
Hoi Octafish,
ik ben leek op vlak van Access...
ik kan delen volgen wat u neerschrijft doch er zitten ook vele chinese zaken bij voor mij :)
hebt gij al de mogelijkheid gehad om er op u pc naar te kijken ?
alvast bedankt
 
Wat is het voordeel van de omschreven methode? Een filter in het rapport op het juiste record (wrs kan dat via Id van de record) is toch al genoeg? Oké, het rapport is dan enkel bruikbaar bij dat ene formulier, maar dat is een klein nadeel en mogelijk zelfs helemaal geen nadeel.
 
Het rapport dient ook enkel gekoppeld te zijn aan dat formulier
hoe kan ik het id van formulier gebruiken binnen rapport omdat record te mailen ?
 
Open het rapport in ontwerpmodus, klik linksboven op het vierkantje met rechtermuisknop en kies eigenschappen, rechts opent een nieuw scherm, kies tabblad gegevens, zoek regel Recordbron en klik op de drie puntjes, je krijg nu een nieuw scherm met in het bovendeel de tabellen/query's die de data bevatten, sleep de gewenste velden naar de balk onderin en vul bij de kolom waar je het filter op wilt baseren de regel criteria in. Makkelijkste is rechtsklikken in het vakje en dan voor opbouwen kiezen. Zoek in de linker onderkolom je formulier en vervolgens het veld op waarop je de record selecteert en klaar. nou ja, paar keer opslaan.
Mogelijk krijg je de vraag of je het rapport wilt baseren op een query, hier moet je dus ja zeggen.
 
Begrijp ik goed dat ik er niet meer naar hoef te kijken? Want ik laat je met alle plezier een slechtere oplossing gebruiken :)
 
Octafish,
graag nog bekijken ... daar ik niks meer vernam van u en ik vast zat was probeerde ik nadere oplossingen...
 
Doe ik :)
 
Vraag (van mij) was eigenlijk wat het nut van die betere oplossing is, die leek mij namelijk nogal omslachtig voor een probleem dat in een minuutje oplosbaar is met een enkel filterregeltje).
Soms kiezen ervaren Access gebruikers omslachtige oplossingen voor een simpel probleem. ;-)
 
@Johgs: mijn oplossing is minstens zo snel in elkaar gezet (zo niet sneller) als de jouwe en zeker niet omslachtiger. Een universele oplossing voor een algemeen probleem verdient in mijn ogen altijd de voorkeur boven een oplossing die a) niet altijd werkt en b) voor elke situatie opnieuw moet worden aangemaakt.
 
@TS: Zullen we eens beginnen bij de opzet van je db? Die klopt m.i. namelijk niet. Zodra ik een tabel zie met velden als [Artikel_1], [Locatie_1], [Lot_1] t/m [Omschrijving_1a], [Artikel_2], [Locatie_2], [Lot_2] t/m [Omschrijving_2a] en zo door tot [Omschrijving_9a] (je bent zelfs nog een hoop velden vergeten op het eind!) weet ik dat je tabel niet genormaliseerd is. En dat betekent ook dat je rapport nooit goed kan zijn. Probeer eerst je db te normaliseren en optimaliseren, voordat je verder gaat met de volgende stap.
 
Je krijgt een leeg rapport (en nu zal Octafish wel lachen) omdat, en nu maak ik een aanname, je het formulier invult en dan de verzend optie gebruikt.
Om de één of andere reden ziet Access dan de record nog niet en toont geen gegevens. Wat ik in mijn begintijd dan als oplossing gebruikte (en nu gaat Octafish gruwen) was de macro aanpassen door de record eerst even op te laten slaan en dan te heropenen (even echo off/on er voor en achter houdt je scherm rustig) en het werkt wel.

Ik heb zo'n vermoeden dat de oplossing van Octafish dit probleem voorkomt. ;-)

Die oplossing ga ik zelf ook nog even nader bekijken want ik heb hier en daar nog wat rapporten die ook eerst opgeslagen moeten worden voor verzending lukt uit mijn beginperiode. Ook een bestaand en werkend systeem kun je altijd nog verbeteren na bijleren. Maar je wilt nu eenmaal zo snel mogelijk een werkend iets krijgen met zo weinig mogelijk studie........
 
Johgs zei:
Ik heb zo'n vermoeden dat de oplossing van Octafish dit probleem voorkomt. ;-)
Klik om te vergroten...
Oh Ja! :).

Johgs zei:
Maar je wilt nu eenmaal zo snel mogelijk een werkend iets krijgen met zo weinig mogelijk studie........ )
Klik om te vergroten...
Ik hoop niet dat je een carriereswitch als hartchirurg overweegt :D.
 
Wil je niet shockeren maar ik mag geheel legaal hartchirurgie uitvoeren. :P

En die QueryDef, heb er eens een Access handboek bijgepakt, die QueryDef wordt pas op pagina 465 voor het eerst vermeld en nogmaals op pagina 754, zonder enige verdere uitleg. (Access 2000 boek).
Maar het lijkt mij dat je die methode van jou voor ieder formulier/rapport moet aapassen en pas voordelen heeft als je een bepaald rapport vanaf verschillende formulieren wilt gebruiken.

Daarnaast vrees ik dat iemand die zichzelf leek noemt al gauw schrikt van termen als SQL string e.d. (en eerlijk gezegd, ik zal dat SQL scherm al vaak gezien hebben, maar als je mij vraagt open het even snel.............) (ik denk dat het het scherm is met die hele lange regel die beschrijft waar de data staat en welke filters je toepast e.d.).
 
@Johgs: dat een techniek pas laat in een boek wordt behandeld, wil natuurlijk niet zeggen dat het geen goede methodiek is. Integendeel zelfs: in de boeken die ik heb staan beginnen ze bij de meest simpele (en snel te vergeten) technieken, om later de betere spullen te behandelen. Ik zie het dus als een extra pluspunt :).

Rapporten vanuit formulieren (gefilterd) openen betekent doorgaans op voorhand al dat je gaat programmeren. Sowieso is programmeren in databases een noodzaak, wil je de handel goed op de rails zetten. Ik denk wel dat TS wellicht nog niet zo ver is, gezien de staat van de db. Die zou eerst goed genormaliseerd moeten worden, wat ook gelijk een veel beter rapport oplevert.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan