Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Postcodeveld in rapport

Pagina: 1
Acties:

  • Onedayflyer682
  • Registratie: Augustus 2004
  • Laatst online: 25-11 21:39
Ik zit met het volgende probleem. Ik heb een Access database gebruikt voor de ledenadministratie. Dit bestaat feitelijk uit 2 onderdelen, 1 invoer en 2 printen van adresstickers. In principe werkt dit alleen wanneer ik het rapport wil printen heb ik niet de postcode '1234 AB' maar '1234 Ab' kortom de laatste letter is niet een hoofdletter.

Bij de invoer in het formulier maak ik gebruik van een functie om de postcode 'uppercase' te maken.
Private Sub txtLid_pc_AfterUpdate()
If Not IsNull(txtLid_pc) Then
txtLid_pc = ToUpper(txtLid_pc)
End If
End Sub
Dit werkt prima. In de tabel staan alle postcodes met hoofdletters geregistreerd.

Voor het maken van de adresstickers maak ik gebruik van een query om de gegevens 'samen' te voegen.
SELECT Leden.lid_nr, Leden.lid_vnaam, Leden.lid_anaam, Leden.lid_straat, Leden.lid_huisnr, Leden.lid_pc, Leden.lid_plaats, Leden.lid_telefoonnummer, Leden.lid_email, Lidstatus.Status

FROM Lidstatus INNER JOIN Leden ON Lidstatus.Id = Leden.lid_status

WHERE (((Lidstatus.Status)="Lid" Or (Lidstatus.Status)="Oud-lid" Or (Lidstatus.Status)="Ere-lid" Or (Lidstatus.Status)="Begunstiger"))
ORDER BY Leden.lid_anaam, Lidstatus.Status;
Wanneer ik deze query uitvoer komt er nog steeds een goede postcode uit. Het rapport wat ik voor deze stickers gebruik maakt gebruik van bovenstaande query.

De adresstickers zien er als volgt uit, trim functie wordt gebruikt voor de spaties.
=Trim([lid_vnaam] & " " & [lid_anaam])
=Trim([lid_straat] & " " & [lid_huisnr])
=Trim([lid_pc] & " " & [lid_plaats])
Bij het uitvoeren van dit rapport gaat het fout, alle adressen die worden ingevoerd na de import (eerste versie)
geven bij de postcode een Hoofdletter en een kleine letter. De adressen die zijn geïmporteerd uit Excel worden wel gewoon goed weergegeven.

Het vreemde is dat ze in de tabellen wel goed staan. Enig idee waar dit aan kan liggen? Ik maak gebruik van Access 2009.

  • pedorus
  • Registratie: Januari 2008
  • Niet online
Vaag verhaal. Het lijkt me dat je geen Access 2009 gebruikt, die bestaat namelijk niet... ;)
Onedayflyer682 schreef op zaterdag 07 november 2009 @ 16:34:
Bij de invoer in het formulier maak ik gebruik van een functie om de postcode 'uppercase' te maken.


[...]


Dit werkt prima. In de tabel staan alle postcodes met hoofdletters geregistreerd.
Nee, dit is foute boel. :p Dit kan namelijk prima met een InputMask (iets als ">0000\ LL"). Er is een BeforeUpdate en een AfterUpdate, waarom erna? Daarnaast lijkt het mij dat je ook nog een validation rule wilt hebben die afdwingt dat het 1e cijfer geen 1 is.
De adresstickers zien er als volgt uit, trim functie wordt gebruikt voor de spaties.
Na een berekening zoals Trim worden dingen als Format en InputMask niet meer doorgegeven, en moet je die misschien even goed zetten?

En je kan prima iets uitvoeren om alles uppercase te maken als overgangsmaatregel omdat InputMask en validatie niet goed stonden:
SQL:
1
update Leden set lid_pc=ucase(lid_pc)

Disclaimer: maak voor zo'n update altijd een backup natuurlijk ;)

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten


  • Onedayflyer682
  • Registratie: Augustus 2004
  • Laatst online: 25-11 21:39
We leven inderdaad in 2009 en ik werk met Access 2007 :)

De check op postcode was inderdaad zinloos, ik had bij elk veld de 'touppercase' aan staan maar nu voor postcode weg gehaald. Validatie wordt gewoon in formulier gedaan.

Wat bedoel je precies met 'moet je die misschien even goed zetten'? Ik heb de validatie middels code eraf gehaald maar ik heb nog steeds hetzelfde probleem. De inputmask staat overigens op de 'standaard' postcode variant.

Edit: Bedankt overigens voor de update-query, mocht ik het niet kunnen oplossen kan ik deze altijd nog uitvoeren voordat de stickers worden geprint.

Edit2: Ik heb het invoermasker er nog eens bijgepakt en ik had een andere notatie dan de notatie hoorde te zijn. Ik had namelijk:

0000" ">L>L;0;_

Terwijl het waarschijnlijk deze moest zijn:

0000\ >LL;0;_

Een kleine test leerde mij dat het op dit moment werkt! Wel vreemd aangezien de functie van beide notaties wel hetzelfde lijkt.

Naja, in ieder geval bedankt!

[ Voor 37% gewijzigd door Onedayflyer682 op 07-11-2009 21:25 ]


  • sam.vimes
  • Registratie: Januari 2007
  • Laatst online: 08-06 08:44
pedorus schreef op zaterdag 07 november 2009 @ 20:48:
Daarnaast lijkt het mij dat je ook nog een validation rule wilt hebben die afdwingt dat het 1e cijfer geen 1 is.
Kleine correctie: volgens mij bedoelt pedorus:

Daarnaast lijkt het mij dat je ook nog een validation rule wilt hebben die afdwingt dat het 1e cijfer geen 0 is.

Postcodes die met een 1 beginnen bestaan wel degelijk (A'dam e.o.).

Verder kun je een aantal letters ook wel schrappen; volgens mij worden de letters FIOQUY niet gebruikt in postcodes. (Is er iemand die dat kan bevestigen of ontkrachten?)

  • pedorus
  • Registratie: Januari 2008
  • Niet online
Die 1 had een 0 moeten zijn idd (uitgegaan van alleen Nederlandse postcodes). :)
De lettercombinaties 'SA', 'SD' en 'SS' worden niet gebruikt. In de loop van 2005 zijn nieuwe postcodecombinaties geïntroduceerd, waarbij ook de eerder niet gebruikte letters F, I, O, Q, U en Y gebruikt worden. Voorheen werden deze letters niet gebruikt omdat er voldoende combinaties te maken waren en vanwege mogelijke verwarring met andere letters. In 2005 waren alle beschikbare combinaties echter op, en het gebruik van extra letters was daarom noodzakelijk.
Ik zou die details gewoon negeren, straks voeren ze ze alsnog in ('secure digital')...

Vitamine D tekorten in Nederland | Dodelijk coronaforum gesloten