Recordset, Query of Filter om

Status
Niet open voor verdere reacties.

DavekeC

Nieuwe gebruiker
Lid geworden
6 jun 2019
Berichten
3
Beste Forumleden. Ik ben naar hier verwezen vanuit een ander forum daar er niet veel leven meer was.

Ik ben uit interesse begonnen aan het ombouwen van een oude MS Works database naar een Acces Database met veel uitgebreidere functionaliteiten.
Het gaat om een database waar momenteel een 50.000 records terug te vinden zijn. Deze database zou een split database worden om meerdere gebruikers simultaan gebruik te laten maken.

Slechts 1 of 2 users zullen echte datainput doen terwijl andere users voornamelijk opzoekingen zullen doen van records en statussen zullen wijzigen.
Omdat ik een grote schrik heb dat vooral het opzoeken van records een bottleneck gaat worden in de vlotheid van de front end wil ik hier even vragen hoe ik hier het best te werk ga voor alles wat met opzoeken van data te maken heeft.
De reden dat ik schrik heb is omdat ik niet goed weet hoe acces omgaat met de resultaten van query's en SQL statements.
Ik werk graag met opzoekvelden die zoeken terwijl je typt. Zolang de data lokaal is werkt dit vlot en zonder problemen zoals een stukje code hieronder:

SQL = "SELECT tblEntityChain.EntityChainID, tblEntityChain.EntityChainName FROM tblEntityChain WHERE " & GCriteria & " ORDER BY tblEntityChain.EntityChainName"
Me.RecordSource = SQL '(Of rowsource als het om een veld gaat, in dit geval gaat het om een continuous form waar alle resultaten onder elkaar geplaatst worden)
Gcriteria update zichzelf bij elke letter die getypt word en dit werkt perfect. Echter vraag ik mezelf af of in een split databse acces voor elke letter deze geupdate query opnieuw op de server gaat zoeken en downloaden of is acces slim genoeg om de vorige query gewoon verder te filteren ?

Zijn er betere manieren om deze zoekmethode te gebruiken (Ik zie op forums vaak het gebruik van DOA en ADO en dan daarin werken ?) een query maken en deze dan op een of andere manier filteren met Me.filter in plaats van de recordset te wijzigen ?

Voor het openen van formulieren gebruik ik zoveel mogelijk directe referenties naar specifieke records dus dat zou geen problemen mogen geven.
Verder heb ik ook een combobox met een lijst van 4000+ mogelijkheden (vandaar de search as you type).

Alvast bedankt voor jullie feedback en input.

Mvg
 
Laatst bewerkt:
Allereerst welkom bij HelpMij! Een heel verhaal, wat eigenlijk overbodig is, omdat je zelf de beste oplossing al geeft:
en deze dan op een of andere manier filteren met Me.filter in plaats van de recordset te wijzigen?
Werken met een FE-BE mag natuurlijk altijd, maar qua snelheid ga je niet veel verschil merken als je toch al niet meer dan 5-10 gebruikers hebt binnen de database. Het grote voordeel van een FE-BE ligt niet zozeer in de snelheid (hoewel je dus wel verschil gaat merken bij grotere aantallen gebruikers) maar in het feit dat je met en FE heel specifiek kan aangeven wat een gebruiker (met zijn/haar eigen FE) wel en niet kan in de db.
Dit:
Of rowsource als het om een veld gaat
Klopt overigens niet: een formulier heeft een Recordbron, en een veld heeft een Besturingselementbron. Aan een veld kan nooit een query hangen. Queries hang je wel aan keuzelijsten (en dus formulieren), maar die keuzelijst heeft, als hij aan een veld is gekoppeld, altijd maar 1 waarde (al kan het natuurlijk tegenwoordig ook een veld met meervoudige waarden zijn).

Ik heb overigens nog weinig problemen met performance gehad binnen mijn databases, al heb je natuurlijk, afhankelijk van het soort query, altijd wel queries die langzamer zijn dan andere queries. Jouw query daarentegen, mag geen enkel probleem zijn qua snelheid. Maar wél dus qua opzet.
Ik werk meestal met niet-gebonden formulieren waarin eerst, m.b.v. keuzelijsten, een selectie wordt gemaakt van hetgeen de gebruiker wil zien of bewerken. Dat levert dan een query op zoals jij min of meer aanlevert. Dan zit er dus een criterium in de Recordbron van het (al dan niet doorlopende, dat maakt totaal niets uit) formulier. Werkt behoorlijk snel, afhankelijk van de complexiteit van het formulier.
Daarnaast kun je een formulier filteren. Dat doe ik bijvoorbeeld op een formulier waar geen criterium op staat. Dan open je dus het formulier met de complete recordset (of uiteraard alvast met een criterium gefilterd) en dan wil je doorselecteren op de recordset. Dat doe ik dus door niet de query aan te passen en opnieuw te laden (veel te traag namelijk) maar door een filter samen te stellen.
Code:
Me.Filter = sFilter
Me.FilterOn = True
Dat filter lijkt dan sterk op het filter dat je nu in de query zet. Ik gebruik voor het filter meestal een niet-gebonden tekstvak in de koptekst van het formulier. De techniek hiervoor heb je blijkbaar al onder de knie, want bij jou wordt er ook ‘live’ gefilterd.
 
Beste OctaFIsh

Dank voor je snelle antwoord. Als ik het dus goed begrijp zou acces bij een wijziging van de recordsource in mijn methode dus opnieuw de BackEnd raadplegen en een nieuwe recordset downloaden bij elke letter die getypt word en die de recordsource dus verder specificeert ?
Best dus een recordset opvragen bij het inladen van het formulier en deze dan verder beperken door filters toe te passen in plaats van telkens de recordsource te wijzigen. (Ookal zou door de beperktheid van het aantal users ik hier geen hinder van mogen ondervinden).

Voor de velden heb ik me inderdaad verkeerd uitgedrukt. Het gaat hier inderdaad om comboboxes die ik gebruik om een formulier in te vullen. Zo heb ik als grootste combobox een lijst van installateurs met 4000+records. Ik wil dat men een bestaande record gebruikt om wildgroei en andere schrijfwijzen te voorkomen.
Is het dus mogelijk om de Rowsource van deze combobox te filteren terwijl men deze invult ? Ik zie nergens een optie om een filter toe te passen op de rowsource van een combobox. Als Acces bij elke wijziging van de Rowsource de BE gaat raadplegen om de combobox te populeren dan zou ik het anders willen doen.
Ik zou dus de combobox wilen populeren met de volledige lijst en dan filteren in plaats van ze telkens te gaan herpopuleren terwijl men typt.

Alvast bedankt voor je antwoord !
 
Het grote voordeel van een FE-BE ligt niet zozeer in de snelheid (hoewel je dus wel verschil gaat merken bij grotere aantallen gebruikers) maar in het feit dat je met en FE heel specifiek kan aangeven wat een gebruiker (met zijn/haar eigen FE) wel en niet kan in de db.

Dat is volstrekt onjuist.
Hier worden de daadwerkelijke voordelen op een rijtje gezet:

http://www.fmsinc.com/microsoftaccess/databasesplitter/

Tardis
 
@tardis: Volstrekt niet onjuist. Kwestie van gebruikservaring. Mijn opmerkingen zijn bedoeld voor de situatie van TS. Theoretische voordelen zijn altijd, gek genoeg, theoretisch. Overigens vind ik in je link net zoveel argumenten voor mijn stellingen, als voor jouw ontkenningen daarvan. Graag een beetje nuanceren als je zo nodig moet hakken.
 
Best dus een recordset opvragen bij het inladen van het formulier en deze dan verder beperken door filters toe te passen in plaats van telkens de recordsource te wijzigen.
Inderdaad wat ik voorstel. Elke keer als je een query aanpast en opnieuw toewijst aan een formulier, wordt die dataset ingelezen op het formulier, en dat kost (nutteloze) tijd. Beter één keer inlezen, en vervolgens doorfilteren.

Is het dus mogelijk om de Rowsource van deze combobox te filteren terwijl men deze invult ? Ik zie nergens een optie om een filter toe te passen op de rowsource van een combobox.
Dat klopt; normaal gesproken gebruik je het teksvak van de Keuzelijst met invoervak (moet je die wel gebruiken natuurlijk) om een item op te zoeken in de lijst door dus de beginletters in te typen. Hoe meer letters je typt, hoe beter de keuzelijst uitkomt bij de gewenste installateur vind. Moeten ze niet allemaal Jansen heten natuurlijk :).
Je filtert de keuzelijst hiermee dus niet, maar je zoekt op de naam. En voor de meeste mensen is dat meer dan genoeg. Als je 3 letters hebt getypt, en je klapt de lijst uit, dan staat de gewenste installateur echt wel in de zichtbare lijst. Zeker als je het aantal uitklaprijen vergroot naar zo'n 20 rijen.

Een keuzelijst filteren kan dus wel, maar dan heb je een vergelijkbaar probleem: je moet de query van de keuzelijst dan aanpassen. En dat heeft eigenlijk alleen dus maar zin als je boven de 65.000 records komt. Meer passen er namelijk niet in de keuzelijst :). Maar 4000 items mag geen enkel probleem zijn, en daar continue de rijbron van aanpassen? Ik zie het voordeel niet. Bovendien heb je dan een extra tekstveld nodig op je formulier (per keuzelijst) om te kunnen filteren.

Kortom: ik zou zeggen: vergeet het laatste deel van je vraag, want je wint er niks mee. Noch aan gebruiksgemak, noch aan snelheid.
 
Hey

Dank voor de uitleg. Ik gebruik nu een combobox met text invoer en ik pas de rowsource aan aan hetgeen ik in het tekstvak typ voor de simpele reden dat als je de normale werking gebruikt hij enkel de records laat zien die exact overeenkomen met hetgeen dat je typt. Als de installateur dus "de klusjesman" noemt en jij typt "klusj" dan zal de normale methode dit record niet mee in de selectie nemen. Of ik zie iets over het hoofd dat je met de gewone combobox ook kan filteren met "*" getypte tekst "*"

Mvg
 
Je hebt dus een apart tekstveld dat je gebruikt om de keuzelijst (met invoervak) te filteren? En dat voor een (redelijk schamele) lijst van 4000 installateurs? Hoeveel bedrijven heb je waarvan de naam met "De " begint dan? Ik zie niet in waarom het makkelijker is om te zoeken met "klus" dan met "de kl". In beide gevallen zullen er bar weinig treffers in de keuzelijst met invoervak zitten met zo'n klein bronbestand. Het gebruikersgemak van jouw werkwijze zie ik ook niet, want terwijl zoeken in de keuzelijst al gelijk het gewenste resultaat laat zien, moet je met het aparte tekstvak nog steeds daarna een extra handeling verrichten: de keuzelijst openen om te zien of er wat in zit. Dat principe (wat zou er in het pakje zitten?) is met Sinterklaas natuurlijk wel plezant, maar in een database? Daarnaast mag je er toch van uitgaan dat de meeste gebruikers wel weten wat de naam van een installateur is, en hem dus correct intypen.

Eén ding in je berichtje klopt: keuzelijsten zijn (in beginsel) níet fuzzy. Maar om daar nu een extra los filter bij te zetten.... Ik heb die vraag nog nooit gehad gelukkig :).
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan