Alternatief voor dlookup

Status
Niet open voor verdere reacties.
De hoogte instellen met .listrows lukt niet met een keuzelijst met invoervak.
Heb wel me.keuzelijst.height gevonden, alleen moet ik nog ff zoeken hoe ik dan
Klik om te vergroten...
Dat zou ik niet doen; daarmee verander je de fysieke hoogte van de keuzelijst, en dat ziet er doorgaans nogal knullig uit. Je kunt beter de eigenschap ListRows aanpassen; het aantal rijen dat je te zien krijgt als je de keuzelijst opent. En die kun je net zo goed een vaste hoogte geven, van bijvoorbeeld 30; langer heeft nauwelijks zijn, omdat de lijst dan meestal van het scherm af loopt, en bij minder items past de lijst zich toch wel aan.
 
Sorry OctaFish.

Ik bedoelde bij een keuzelijst zonder invoervak heb je niet te beschikking tot .listrows.


Zag je nog iets raars aan de requery die ik gebruik?
 
Op zich niet; let er wel op dat je zeker weet dat er spaties zitten tussen de WHERE en ORDER BY en het filter; als de tekst tegen elkaar wordt geplakt, doet-ie het niet... En de hoogte aanpassen van een keuzelijst lukt zo prima; ik gebruik de techniek zelf ook. En wel zo:

Code: 
    If iAantal > iRijHoog Then
        Me.lstCat2.Height = iHoog * 25 + iHoog
    Else
        Me.lstCat2.Height = iHoog * iAantal + iHoog
    End If
 
Ik kom er niet uit.

Open ik de query staat alle criteria netjes ingevuld, alleen wordt de requery niet uitgevoerd.
En de knop verversen helpt ook niet.

Kan jij in mijn voorbeeld kijken waarom het niet werkt. Werk zelf met versie 2007.
Het is formulier fDoorlopendFormulier.
 

Bijlagen

Laatst bewerkt:
Zal er vanavond naar kijken...
 
Beste OctaFish, als je tijd heb wil je hier nog even naar kijken.
Alvast bedankt voor je inzet.
 
Ik heb er naar gekeken, en 't aan de praat op de volgende twee manieren (ja twee: zowel met filter als met aanpassing van de query).

Methode 1: aanpassen via een filter.
Code: 
    Me!fDoorlopendFormulierSub.Form.Filter = sFilter
    Me!fDoorlopendFormulierSub.Form.FilterOn = True
    Me!fDoorlopendFormulierSub.Form.Requery

Methode 2: aanpassen via een query.
Code: 
    strSQL = "SELECT ID, Factuurdatum, Klantnr, Bedrag, Kleur FROM tblBedragen "
    If Not sFilter & "" = "" Then strSQL = strSQL & "Where" & sFilter & " "
    strSQL = strSQL & "ORDER BY Klantnr, Factuurdatum"

    Set qDF = CurrentDb.QueryDefs("qDoorlopendFormulier")
    qDF.SQL = strSQL

    Me!fDoorlopendFormulierSub.Form.RecordSource = "qDoorlopendFormulier"
    Me!fDoorlopendFormulierSub.Form.Requery
 
Uiteraard werkt het! Bedankt!

Wil In mijn database het liefst 1 manier van werken gaan gebruiken.
Het filter zal dan worden gebuikt voor formulieren, rapporten die gebasseerd zijn op een normale of kruistabelquery.

Is er nog verschil in snelheid/performance tussen het gebruik van een filter of het gebruik van set qDF?

Zie jij problemen bij 1 van deze 2 methodes in rapporten, formulieren bijvoorbeeld?
 
Ik merk zelf weinig snelheidsverschillen, maar ik werk ook zelden met grote volumes. Bij beveiligde frontend-backend oplossingen is het filter vermoedelijk de beste oplossing, omdat er niks hoeft te worden gesleuteld aan de bronobjecten; dat gebeurt uiteraard wel met de query-aanpassing. Overigens heb ik daar ook weinig ervaring mee, dus ik kan niet goed inschatten of de tweede oplossing een hindering kan zijn in de db.
 
Heb om mijn rapport te openen 2 knoppen: Afdrukken en afdrukvoorbeeld

Heb nu het volgende onder mijn knop staan voor het afdrukvoorbeeld.

Code: 
Private Sub cmdAfdrukvoorbeeld_Click()
Dim strReportname As String
Dim sfilter As String

strReportname = "rpt_test"
    
Call Filteren
DoCmd.OpenReport strReportname, acViewPreview, , sfilter
End Sub

Alleen bij het openen van het rapport wordt het filter niet mee gegeven.
Kan natuurlijk docmd.openreport enz. onderaan bij het filter zetten, maar krijg dan
dezelfde code voor het filter bij adrukken en afdrukvoorbeeld.

Houdt in bij iets wijzigen moet je dit 2 maal doorvoeren.

Volgens mij kan dit efficienter.
 
Je kunt het filter meegeven bij het OpenArgs argument, en op het rapport bij de gebeurtenis <Bij openen> weer uitlezen, of zo:

Code: 
        DoCmd.OpenReport "rpt_test", acViewPreview
        DoCmd.Maximize
        Reports![rpt_test].Filter = strSQL
        Reports![rpt_test].FilterOn = True
 
Volgens mij zelf opgelost door
Code: 
Dim sFilter as string

Weg te halen bij het filter
Code: 
Private Sub Filteren()

en hieronder neer te zetten
Code: 
Option Compare Database
Option Explicit
Dim sfilter As String
 
Laatst bewerkt:
Nog een probleempje met een rapport die op een kruistabelquery gebasseerd is.

In mijn kruistabelquery staan de volgende velden:
Debiteurid--tDebiteuren--Groupby--Rijkop
Month([Factuurdatum])-- (leeg) -- Groupby--Kolomkop
Bedrag--tFactuur--Som--Waarde

Nu wil ik een periode op kunnen geven van 01-01-2011 t/m 25-03-2011.
Ik open het rapport en geef het filter mee.
Code: 
If IsDate(txtDatumvan) And IsDate(txtDatumtm) Then
        If sfilter <> "" Then sfilter = sfilter & " AND "
        sfilter = sfilter & "[Factuurdatum] Between " & Format(txtDatumvan, strcJetDate) & " And " & Format(txtDatumtm, strcJetDate)
    End If

Alleen als ik het rapport open krijg ik de melding:
Code: 
Fout 3070 tijdens uitvoering
De Microsoft Access database engine kan [Factuurdatum] niet
herkennen als geldige veldnaam of expressie.

Als ik vervolgens het veld Factuurdatum aan mijn query toevoeg met als Totaal Waar en
als kruistabel (niet weergeven) en opsla en vervolgens de query weer opent is het veld
factuurdatum verdwenen uit de query.

Is er een manier om het veld factuurdatum toch toe te voegen, zonder dat access het veld zelf uit de query verwijderd?
 
Laatst bewerkt:
Je gebruikt het veld Factuurdatum als Criterium zonder een criterium te gebruiken.... In essentie filter je dus niks, en daarom slaat Access het veld ook niet op. De enige manier om het filter dynamisch op te slaan in de kruistabel, is als je de SQL voor de kruistabel via VBA opbouwt en opslaat.
 
Dus in dit geval gebruik maken van SetqDF, zoals hieronder het voorbeeld.

Code: 
strSQL = "SELECT tblBedragen.ID, tblBedragen.Factuurdatum, tblBedragen.Klantnr, tblBedragen.Bedrag, tblBedragen.Kleur " _
            & "FROM tblBedragen " _
            & "Where" & sFilter _
            & "ORDER BY tblBedragen.Factuurdatum, tblBedragen.Klantnr "
    
    Set qDF = CurrentDb.QueryDefs("qDoorlopendFormulier")
    qDF.SQL = strSQL
 
Denk ik wel... waarbij sFilter dus je datumselectie is op Factuurdatum. Ik zou geen andere manier weten om op een enigszins makkelijke manier een kruistabel te filteren.
 
Krijg weer een melding van Access:
Krijg er onderhand wel wat hoofdpijn van.

Code: 
Fout tijdens  uitvoering
Het opgegeven veld DebiteurID kan naar meer dan een tabel verwijzen in de
compnent FROM  van uw  SQL -instructie

Gebruik deze SQL string
Code: 
strSQLfilter = "SELECT tblDebiteuren.DebiteurID, tblDebiteuren.Debiteurnaam, tblFactuur.Factuurnummer, tblFactuur.Factuurdatum, tblFactuur.Omschrijving, tblFactuur.BedragExcl, tblFactuur.BTW, tblFactuur.BedragIncl " _
                    & "FROM tblDebiteuren INNER JOIN tblFactuur ON tblDebiteuren.DebiteurID = tblFactuur.DebiteurID " _
                    & "Where" & sFilter

En dit is het stukje filter voor het debiteur nr.
Code: 
 x = 0
    iSel = Nz(Me.lstDebiteur.ItemsSelected.Count, 0)
    If iSel > 0 Then
        If sFilter <> "" Then
            sFilter = sFilter & " And " & "(DebiteurID In("
        Else
            sFilter = sFilter & "(DebiteurID In("
    End If
        For Each itm In Me.lstDebiteur.ItemsSelected
            x = x + 1
            tmp = Me.lstDebiteur.ItemData(itm)
            If Not IsNumeric(tmp) Then tmp = "'" & tmp & "'"
            sFilter = sFilter & CStr(tmp)
            If x < iSel Then sFilter = sFilter & ","
        Next itm
        sFilter = sFilter & "))"
    End If

Wat ik ervan begrijp is dat hij het veld DebiteurID niet kan plaatsen.
Of het bij tblDebiteuren of tblFactuur hoort.

Verander ik het veld debiteurID in de tblFactuur in debiteurnr werkt het wel.
Is dit dan de oplossing of kan je op een 1 of andere manier de juiste tabel aan het filter meegeven?
 
In je filtercriterium moet je ook aangeven uit welke tabel het veld moet worden gehaald. Dat komt doordat je twee tabellen hebt met een identiek veld. Door de naam van het veld in één tabel te veranderen, zijn de namen uniek en kan Access de velden wel plaatsen. En hoeft de tabelnaam er dus niet meer bij. Je oplossing om de naam in één tabel te veranderen is dus een prima oplossing!
Overigens heeft het gebruik van identieke veldnamen in tabellen in een query ook een voordeel: Access koppelt namelijk automatisch identieke veldnamen aan elkaar. Dus een veld PersoonID uit de tabel Personen wordt in een query automatisch aan het veld PersoonID uit de tabel Bestellingen gekoppeld, ook al heb je geen relatie tussen de tabellen gemaakt. Heet het veld in de tabel Bestellingen echter Persoon_ID, dan wordt de koppeling niet gemaakt. Identieke veldnamen hebben dus voor- en nadelen. Persoonlijk vind ik de nadelen de voordelen overstijgen, dus ik probeer ze zoveel mogelijk te vermijden.
 
Door hem voor de veldnaam te zetten met een punt. Zoals hij ook in de Select string staat. Omdat je een Inner Join gebruikt maakt het vermoedelijk niet eens uit naar welke tabel je verwijst, maar ik zou de tabel nemen waar je het veld ook uit haalt. Zit je altijd goed.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan