MSaccess probleem met recordsoure subform

[Stefke]

Ik heb een formulier (relatiegegevens) met daarop een subformulier (alleen namen) en een zoekveld, deze layout:

code:

zoekveld:_____
--------------------------------------------------
subform      |
naam1        |    Naam: ----
naam2        |    Adres: ------
naam3        |    Email: ------
naam4        |

Als de gebruiker zoekt in het zoekveld wordt in elk van de relatievelden gezocht naar de waarde en worden de "hits" links in het subform weergegeven in een lijst. In de lijst klikken geeft dan de gegevens van de geselecteerde relatie

In technische zin: Nadat een zoekwaarde wordt ingevoerd stel ik met VBA een SQL-string samen waarmee in elk van de relatievelden gezocht wordt:

code:

SELECT naam FROM relaties WHERE naam="zoek" OR adres="zoek" OR email="zoek"

Deze SQL wordt dan toegekend aan de recordsource van het subformulier, waarna dan alléén overeenkomstige records weergegeven worden in het subform. De gebruiker zoekt in het lijstje met hits zijn record en klikt op de juiste.
De oorspronkelijke recordsource (SELECT naam FROM relaties) wordt tijdelijk in het geheugen opgeslagen, en als de gebruiker het zoekveld leegmaakt wordt de oorspronkelijke recordsource weer toegewezen.

Nu het probleem: ik had dit aan het werk, alleen was het subform een listbox. Door andere redenen (o.a. het aantal records > 65000 - maximaal op een listbox - en snelheid) wil ik hier nu een subform van maken. Als ik echter in de code na het opbouwen de SQL

code:

forms!form!subform.form.recordsource = SQL

toewijs aan het subformulier, blijft het subformulier leeg.

Maak ik de zoekquery leeg (en krijg het subform weer de oorspronkelijke recordsource) dan zie ik maar één record, en die blijkt gekoppeld aan het hoofdformulier: ga ik in het hoofdformulier bladeren, dan "bladert" het subform mee met die ene record.
Het subform is echter niet gekoppeld!


Als ik het subformulier zelf open (dus NIET als subform op een hoofdform) en dan

code:

forms!subform.recordsource = SQL

doe, dan werkt het wel goed (ik zie de gezochte records)


Ik zie vast iets heel simpels over het hoofd, maar ik ben al heel de avond aan het rotzooien. Het lijkt wel of er op de een of andere manier een link ontstaat met de data op het hoofdformulier, of een filter(optie) wordt aangezet. Ik snap er helemaal niks van.

Een klein testje met een simpel form en subform, en dan werkt het toewijzen van een gewijzigde recordset wel.

[Lustucru]

stefijn schreef op donderdag 08 maart 2012 @ 22:20:
Die blijkt gekoppeld aan het hoofdformulier: ga ik in het hoofdformulier bladeren, dan "bladert" het subform mee met die ene record.
Het subform is echter niet gekoppeld!

Zoals je zelf constateert: het subform is gekoppeld aan het hoofdformulier. Dan kun je wel zeggen dat dat niet zo is, maar dan nog blijkt het wel te zijn. Hoe weet je dan zo zeker dat het niet is?

[pedorus]

Bij de properties van de subform op het hoofdformulier staan vast "Link Master Fields" en "Link Child Fields" ingesteld. Maar voor de rest is er vast geen koppeling

MSDN: LinkChildFields, LinkMasterFields Properties

[Stefke]

Ja dat bedoel ik: er is niks ingevuld bij die 2 eigenschappen (dat had ik ook al aangegeven)

edit: nou breekt mijn klomp. Vanmorgen stond er ineens wel een relatieID in die eigenschappen....dus ik denk, hoe the F kan dat nou, maar goed ws. dan toch de oorzaak gevonden. Velden leeggemaakt: maakt niks uit.

Als ik de zoekstring als recordsource opsla in het subform krijg ik de juiste records, dus de SQL is goed opgebouwd. Maar het toewijzen via VBA levert alleen maar een leeg formulier op.

Zelfs als ik de zoekstring als eigenschap opsla in het subform (en dus default al de gezochte records krijg) en dan via VBA nogmaals dezelfde zoekstring toewijs en ik dus exact dezelfde records zou moeten zien wordt het formulier leeg


edit2: als ik de recordsource van het hoofdformulier verwijder (en dus allemaal fouten krijg in de velden die geen koppeling meer hebben) werkt het wel. Het lijkt wel alsof er ergens anders nog een koppeling ontstaat (maar dat is dan iets dat ik niet weet)

Nog maar een edit: Het blijkt dat als ik na het toewijzen van de recordsource aan het subform, en daarna nog eens extra de eigenschappen LinkMasterField en LinkChildField leegmaak dat het dan wel werkt.
BLIJKBAAR worden deze eigenschappen automatisch gevuld na het toewijzen van een recordsource!

Ter controle heb ik nog even een debug.print van deze velden vóór en ná het toewijzen van de recordsource gezet, en inderdaad: voor het toewijzen géén waarde, na het wijzigen van de recordsource hebben deze velden ineens een waarde. Leve de automatisering.

[ Voor 153% gewijzigd door Stefke op 09-03-2012 09:23 ]

[Lustucru]

Weird.

Maar ik kan je verhaal bevestigen: Het zetten van een recordsource voor een subform triggert Access blijkbaar om linkmasterfield en linkchildfield eigenhandig van een waarde te voorzien. Ik zie zo snel twee oplossingen:

1) Maak het direct daarna weer ongedaan:

code:

    Me.foo.Form.RecordSource = bar
    Me.foo.LinkChildFields = ""
    Me.foo.LinkMasterFields = ""

of
2: zorg ervoor dat in je bronnen geen gelijknamige velden voorkomen, bv niet in allebei een numeriek veld 'id'. Access weet dan niet hoe te koppelen en zal het achterwege laten. Maar bemoeiziek is het wel, idd.

of 3: Gebruik niet recordsource maar recordset. Dan toont Access die bemoeizucht niet.

code:

     set rs=db.openrecordset(bar)
     set foo.Form.Recordset = rs

Al zul je dan iets met je screenupdating moeten doen.

[ Voor 15% gewijzigd door Lustucru op 09-03-2012 12:58 ]

[pedorus]

Tsja, subforms zijn nu eenmaal bedoeld om een master-detail-view te maken. Het lijkt er enkel op dat hier de master in de subform staat, in plaats van omgekeerd.

[Lustucru]

Maar weet je wat erg is: zelfs al heb ik een tabel I met id (prim key), attr1,attr2 ...attrN en een tabel II met id(prim key), foreign_key1, attr_1,attr_2, attr_N en ik geef keurig aan in het relatiescherm dat tabelI.id gerelateerd is aan tabelII.foreign_key1, dan nog stelt Access master en linkfield beide in op 'id'.

En dat is behalve bemoeizuchtig ook onlogisch en fout.

[pedorus]

In een goed datamodel gaat een natural join tussen 2 tabellen wel altijd goed natuurlijk. Nu is de grap wel dat Microsoft normaal gesproken niet aan natural joins doet...