[access] Harde return value in query

Pagina: 1
Acties:
  • 364 views sinds 30-01-2008
  • Reageer

  • BovenHond
  • Registratie: Februari 2002
  • Laatst online: 25-05 14:10
Laat ik beginnen te melden dat ik twijfelde tussen dit forum [14] en software algemeen [10] bij het aanmaken van dit topic. Tevens is het jammer dat search niet werkt maar via Google kon ik het niet vinden.

Als je in Visual Basic een harde return wil toevoegen in een waarden doe je dit met VbCrLf. Maar nu heb ik een normale MS-access query. (die je eventueel ook in SQL kan zien)

Daar wil ik voor adreswaarden harde returns in namelijk
code:
1
2
3
[Straat] & " " & [Huisnummer] [HARDE RETURN]
[Postcode] & " " & [Woonplaats] [HARDE RETURN]
[Land]


Deze harde return is te faken door de volgende code
code:
1
2
[Straat] & " " & [Huisnummer] & "
" & [Postcode] ...etc


Echter als ik op opslaan click dan herschrijft hij de gemaakte harde returns om naar spaties en staat er
code:
1
[Straat] & " " &"[Huisnummer] & " "& [Postcode]... etc

Waarschijnlijk heeft dit er iets mee te maken dat er behoorlijk veel IIF statements in staan maar kom er niet uit. Ik ben dus niet op zoek naar het antwoord VbCrLf maar naar een soortgelijk commando voor in de query editor (opbouwen / build)

[ Voor 16% gewijzigd door BovenHond op 09-04-2004 08:48 ]


  • Heras
  • Registratie: December 2001
  • Laatst online: 20-04 13:23
Chr(13)

  • RaZ
  • Registratie: November 2000
  • Niet online

RaZ

Funky Cold Medina

code:
1
[Straat] & " " & [Huisnummer] & chr(13) & chr(10) & Trim(Ucase([Postcode] & "  " & [plaats]))

Als je alleen een 13 doet, krijg je een mooi vierkantje. Dus 13 & 10 gebruiken

Ey!! Macarena \o/


  • BovenHond
  • Registratie: Februari 2002
  • Laatst online: 25-05 14:10
Heras,

Bedankt.. Met Chr(13) kan ik er inderdaad een goede mailmerge mee maken. Het is echter wel jammer dat in de gegevensbladweergave hij [] blokjes laat zien in plaats van returns.

edit:


Wauw, vaak is de oplossing er sneller dan de vraag!! Mijn grote dank voor de snelle reactie. Ik heb er toch 10 uur over lopen prutsen (Dat licht met name aan de complexe query niet aan de returns)

[ Voor 38% gewijzigd door BovenHond op 09-04-2004 09:07 ]


  • Markieman
  • Registratie: December 2001
  • Laatst online: 15-05 12:16
Mag ik vragen waarom je het adres als een geformatteerde string met enters in je DB wilt? Het lijkt mij verstandiger om [adres] [huisnummer] etc als aparte velden op te slaan en deze pas bij het uitlezen de juiste layout te geven voor uitvoer...

Dit maakt je app in de toekomst ook eenvoudig aanpasbaar

You do not fear them? - The Wraith? Naah. Now *clowns*, that's another story.


  • BovenHond
  • Registratie: Februari 2002
  • Laatst online: 25-05 14:10
Markieman schreef op 09 april 2004 @ 09:05:
Mag ik vragen waarom je het adres als een geformatteerde string met enters in je DB wilt? Het lijkt mij verstandiger om [adres] [huisnummer] etc als aparte velden op te slaan en deze pas bij het uitlezen de juiste layout te geven voor uitvoer...

Dit maakt je app in de toekomst ook eenvoudig aanpasbaar
Vragen mag altijd. Deze query wordt vanuit MS-access rechtstreeks geexporteerd naar MS-Excell vanwaaruit een opgemaakte MS-word mailmerge kan worden gemaakt.

Ik heb er een goede reden voor. Ik gebruik voor het maken van dit adres een aantal voorwaardelijke vragen die ik in MS-word of excell achteraf niet meer kan doen.

In woorden
code:
1
2
3
4
5
6
7
8
Geef het bedrijfsadres weer
Geef alleen het land weer als het land <> "Nederland

Geef het bedrijfsadres van de technische contacptersoon weer
   als deze persoon de indicator post naar pive heeft uitstaan. 
Geef het privé adres van de technische contactpersoon weer 
   als deze persoon de indicator post naar prive heeft aantaan
etc..


De reden achter het samenvoegen van deze regels is dat de persoon die de mailmerge moet doen tevens niet veel verstand heeft van mailmerges. Dus hoe minder velden toevoegen (alleen briefhoofd) en (aanhef) maakt het makkelijker dan
(Bedrijfsnaam) (evt. Afdelingsnaam als deze is ingevuld) (Postadres) (Postcode) (Plaats) (evt. Land) (Voornaam of Voorletters afhandenkelijk van welke velden zijn ingevuld) (evt. Tussenvoegsels) (evt. Titalatuur) (achternaam).

etc etc.

[ Voor 27% gewijzigd door BovenHond op 09-04-2004 09:20 ]


  • Markieman
  • Registratie: December 2001
  • Laatst online: 15-05 12:16
Ok, in zo'n geval is het acceptabel =)

Misschien nog een idee als het type van het veld Tekst is:
Je zou kunnen overwegen dit te converteren naar Memo.

Tekst is niet gemaakt voor meerdere regels en heeft ook nog een maximum van 255 tekens...

You do not fear them? - The Wraith? Naah. Now *clowns*, that's another story.


  • BovenHond
  • Registratie: Februari 2002
  • Laatst online: 25-05 14:10
Markieman schreef op 09 april 2004 @ 09:23:
Ok, in zo'n geval is het acceptabel =)

Misschien nog een idee als het type van het veld Tekst is:
Je zou kunnen overwegen dit te converteren naar Memo.

Tekst is niet gemaakt voor meerdere regels en heeft ook nog een maximum van 255 tekens...
De velden in de query worden uit allerlei [tekst] velden geraapt. En de query schrijft deze nergens naar toe behalve naar Excel. Dus er wordt géén access tabel mee gevuld. Ik weet niet hoe je deze conversie naar Excel het veld memo mee kan geven en ook niet of dit wel kan. Ik geloof dat Excell deze beperking in veldlengte niet kent toch?

  • Markieman
  • Registratie: December 2001
  • Laatst online: 15-05 12:16
Matsu_matsu schreef op 09 april 2004 @ 09:38:
[...]
De velden in de query worden uit allerlei [tekst] velden geraapt. En de query schrijft deze nergens naar toe behalve naar Excel. Dus er wordt géén access tabel mee gevuld. Ik weet niet hoe je deze conversie naar Excel het veld memo mee kan geven en ook niet of dit wel kan. Ik geloof dat Excell deze beperking in veldlengte niet kent toch?
Srry, ik had het verkeerd begrepen. Het lijkt mij dat het zo goed moet gaan...

You do not fear them? - The Wraith? Naah. Now *clowns*, that's another story.

Pagina: 1