Access 2016. Index filteren

[KPTPTT]

Hallo allemaal. Er is een Historie-formulier met oa. een knop Status om een bijbehorend Status-formulier te openen. Historie is afgeleid van de tabel Opdrachten met de Key [pdrachten ID] en Status van de tabel Status_Werkorder met het gerelateerde c.q. gekoppelde veld [s_Status_ID].
Als de knop Status wordt geactiveerd, dan moet op basis van [pdracht ID] het juiste Status-formulier worden geopend met de gegevens uit de tabel Status_Werkorder (zie onderstaande code). Ik heb de code geschreven in een ander formulier met een knop voor dezelfde functie en die werkte. In dit formulier wordt de index [pdracht ID] om een andere reden, in een andere fase bepaald en weergegeven door [sOpdracht1].

De waarde van [sOpdracht1] en [pdracht ID] moeten hetzelfde zijn. In de code bevat de variabele sOpdracht1 de waarde van de key [pdracht ID] en dus van het actuele formulier. Dus [pdracht ID] moet de waarde van sOpdracht1 krijgen, maar hoe?

Het blijkt nu dat bij het activeren van de knop de waarde van de index [sOpdracht1} correct is, bv. 24. MIjn idee is om de index [pdracht ID] de waarde van [sOpdracht1] over te laten nemen en daarmee het juiste formulier te openen. Maar [pdracht ID] is altijd bv. 89 (een eerste keer door een andere toepassing geopend formulier?) en opent daarmee een verkeerd Status-formulier. Krijg deze index [pdracht ID] niet naar de juiste waarde (24) aangepast. Ik heb nog geprobeerd met de variabele FilterOpdrachtID nog een verbinding te leggen. Ik kom na lang zoeken er niet uit waarom [pdracht ID] altijd 89 blijft terwijl de tekst van de MsgBox [pdracht ID]=24 aangeeft.

Private Sub Knop376_Click()                                       'Formulier Historie

Dim FilterOpdrachtID As String
MsgBox "sOpdracht1" & "=" & sOpdracht1                          'sOpdracht1=24
On Error Resume Next
    FilterOpdrachtID = "[o_Opdracht ID] = " & sOpdracht1
MsgBox FilterOpdrachtID                                         '[o_Opdracht ID]=24
MsgBox [o_Opdracht ID]                                          '89

    If Nz(DLookup("s_Status_ID", "Status_Werkorders", "[s_Status_ID] = " & Me.[o_Opdracht ID]), 0) = 0 Then
        'DoCmd.OpenForm "Status_Werk", Windowmode:=acDialog, OpenArgs:=Me.[s_Status_ID]
          DoCmd.OpenForm "Status_Werk", , "[s_Status_ID] = " & Me.[o_Opdracht ID], , acFormAdd, acDialog, OpenArgs:=Me.[s_Status_ID]
    Else
        'DoCmd.OpenForm "Status_Werk", Windowmode:=acDialog, OpenArgs:=Me.[s_Status_ID]
          DoCmd.OpenForm "Status_Werk", , , "[s_Status_ID] = " & Me.[o_Opdracht ID], , acDialog, OpenArgs:=Me.[s_Status_ID]
    End If
End Sub

Option Compare Database
Private Sub Form_Load()                                                 'Formulier Status_Werk
    If Not Me.OpenArgs = vbNullString Then Me.[s_Status_ID] = Me.OpenArgs
End Sub

 

[OctaFish]

Ik snap (wederom ) niet wat je aan het doen bent. Je hebt je OpdrachtId blijkbaar al in een public variabele gezet, anders zou die nu leeg zijn. Dat die niet gelijk is aan de [pdracht ID] kán dus normaal gesproken niet; als je een knop op een formulier start, krijg je de ID van het actuele record. Ik zou niet eens weten hoe ik dat niet zou uitlezen . (tuurlijk weet ik dat wel ). Maar de verbazing zit hem dus in het feit dat je vervolgens met beide waarden niks doet, maar je formulier opent op basis van [s_Status_ID]. En daar rep je in je verhaal niet over...

Overigens lopen de koude rillingen (ondanks het weer) mij over de rug als ik lees dat je voor elke status een apart formulier hebt..... Waar is dat voor nodig? Ik zal je eerlijk zeggen dat ík dat dus nog nóóit heb hoeven doen!

 

[KPTPTT]

Dank je wel. Mijn idee en uitvoering is misschien apart maar als je het zou zien en het werkproces kent, lijkt het misschien wel wat. Dat heb je met een forum, de "afstand" is groot. Maar zonder forum zou het er voor mij niet goed uitzien .
Er is sprake van een werkformulier met de opdracht. Van de uitvoerders moet de status van het werk, in een apart formulier, worden bijgehouden. Als de klant belt, dan moet er een Historisch overzicht zijn van alle werkzaamheden van het jaar van het pand, zowel werkoverzicht, opdrachtgever, financiële overzicht en status van de uitvoerders etc. en dat van iedere opdracht in dat jaar apart en dus knoppen met aparte formulieren. Eén adres in een keuzelijst en alle info is onder een aantal knoppen beschikbaar. Het werkt supersnel en overzichtelijk, de gebruikers zijn content.

Ik ben verder gegaan met testen. Van de opdracht is het ID-nummer bekend in de variabele string sOpdracht1. Dit ID komt ook voor in de tabel Status_werkorders. Met dit nummer moet vanuit een tabel Status_Werkorders een formulier worden geopend met de gegevens die uit deze tabel worden getoond.
Het blijkt dat als ik geen OpenArgs toepas, hoe vreemd ook, het juiste formulier wordt geopend. Als OpenArgs wordt ingezet, dan wordt een foutmelding gegeven in de DoCmd.Openform: Kan het veld [1 niet vinden waar naar wordt verwezen in de expressie.

a) Waarom kan ik, zoals gebruikelijk, geen OpenArgs toepassen en wordt een foutmelding gegenereerd? Volgens mij is OpenArgs nodig.

b) Als geen statusrecord wordt gevonden in de tabel Status_Werkorders, omdat die er niet is, dan wordt een foutmelding gegeven in regel NZ(DLookUp . . .: Syntaxfout (Operator ontbreekt) in query expressie [s_Status_ID]=. Wat zou dit kunnen veroorzaken?

Private Sub Knop376_Click() 'Knop Status 1

    If Nz(DLookup("s_Status_ID", "Status_Werkorders", "[s_Status_ID] =" & sOpdracht1), 0) = 0 Then
        Exit Sub
    Else
        DoCmd.OpenForm "Status_Werk", , , "[s_Status_ID] =" & sOpdracht1, , acDialog ', OpenArgs:=Me.[s_Status_ID]
    End If
End Sub

Option Compare Database

Private Sub Form_Load()                    'Formulier Status_Werkorder
    If Not Me.OpenArgs = vbNullString Then Me.[s_Status_ID] = Me.OpenArgs
End Sub

 

[OctaFish]

... en dat van iedere opdracht in dat jaar apart en dus knoppen met aparte formulieren.

Echt, ik heb in mijn leven heel wat databases gebouwd, voor verschillende soorten opdrachtgevers. En dit soort ‘problemen’ dus ook. Nog nooit deze oplossingsvariant nodig gehad, of ook maar overwogen. Het kan echt beter en anders .

Nz is niet bedoeld om fouten af te vangen; daarmee kun je een vervangende waarde genereren als een veld leeg (Null waarde) is. Dat is niet hetzelfde als een fout als een DLOOKUP niet werkt. Ik wil overigens, buiten het forum om natuurlijk, wel naar je echte db kijken, wellicht dat het dan wat duidelijker wordt. Nu krijg ik er maar geen vinger achter wat je aan het doen bent .