Afhankelijke valdiatie en ADODB Recordset

Afhankelijke validatie en ADODB Recordset

Werd er in het verleden nog wel eens geklaagd over de traagheid van draaitabellen voor het gebruik bij afhankelijke validatie, bij de ADODB recordset kan ik me dat nauwelijks voorstellen.
Op mijn systeem met Offie 2010 loopt het nl. als een zonnetje.

In de bijlage het bestand.
De afhankelijke validatie vindt plaats in het werkblad én er is een toepassing in een userform.

Als je de validatielijst gesorteerd wil hebben dien je de ADODB recordset anders te bouwen dan wanneer sortering niet van belang is.
Daarom heeft het werkblad nu een checkbox om aan te geven of de validatielijsten gesorteerd moeten zijn.
Voor de Userform illustratie is er een Userform zonder sortering (Userform1) en een Userform met sortering (Userform2).

Bij de werkbladvalidatie blijft het lastig dat de opslagcapaciteit van validatieregels, als die niet bestaan uit verwijzingen naar een gebied in een werkblad, veel te beperkt is. Dat leidt tot onnodige foutmeldingen van Excel als je het bestand hebt opgeslagen en opnieuw opent.
Daarom heb ik alleen gebruik gemaakt van verwijzingen in validatieregels.

De oorspronkelijke bijlage bij deze post heb ik vervangen door een nieuwere versie.
Daarin is de sorteeroptie in zowel het werkblad als het Userform geïmplementeerd.

Leuk idee om dat zo te doen. Bijgevoegd een aangepaste versie. Daarbij is het niet nodig om voor de sortering een andere opbouw van de recordset te kiezen. Ook heb ik de code op diverse plekken aangepast waardoor het naar mijn idee stabieler werkt. Ik heb trouwens alleen de code achter het werkblad aangepast. De code achter de formulieren heb ik dus ongemoeid gelaten.

@Rebmog

Dat is mooi !

Wie kon nu bedenken, dat cursorlocation (als je het letterlijk neemt) iets te maken zou kunnen hebben met wel of niet gekoppelde gegevens kunnen sorteren.

Ik ga er verder induiken. Bedankt.

De verbeterde versie is aardig eenvoudiger geworden.

Ik had mijn versie uit post 2 gebaseerd op het selection_change-event ipv het change-event. Ik vond dat wat stabieler omdat dan min of meer wordt afgedwongen dat de invoer op de juiste volgorde plaatsvindt. Op het moment dat je dan een cel selecteert uit een kolom waarbij de voorgaande kolom nog niet is ingevuld, dan is deze keuzelijst leeg. In jouw versie zijn, op het moment dat kolom B wordt ingevuld, de keuzelijsten voor zowel C als D gelijk. D kan dus al ingevuld worden (met verkeerde waarden) voordat C is ingevuld.

Ik had in die versie de cursorlocation toegevoegd. Ik had dat voor de duidelijkheid op een aparte regel gezet. Maar je kunt dit ook toevoegen aan rst.Open. Het wordt dan:

De variabele x0 bij het vullen van de dictionary is volgens mij ook niet nodig. Dit zou je volgens mij kunnen vervangen door:

Die 3 als argumnet heeft bij mij niet het gewense effekt.
Ik zie bij de cursorlocation andere waarden dan bij de argumenten van .Open, cursortype, locktype.
Cursortype en Locktype zijn andere eigenschappen dan CursorLocation.

De x0= methode bij dictionary is functioneel identiek aan = empty.

Werken in een werkblad vind ik contrair aan een werkwijze 'afdwingen'. Daarvoor gebruik ik dan liever een Userform.
Overigens is het werkboek slechts bedoeld als illustratie van het gebruik van de ADODB recordset: niks meeer, niks minder.
Als iemand wil stoeien is mij om het even.

Bij nader inziek lijkt mij het gebruik van de dictionary om unieke items te genereren overbodig.
De ADODB.Recordset bevat nl. een ingebouwde methode de resultaten als unieke, gesorteerde items te produceren.
In de SQL-opdracht kun je dat doen met de instructie 'DISTINCT'.

In de bijlage kun je zien hoe het gebruik daarvan de code aanzienlijk versimpelt.
Mijn indruk is, dat de snelheid hiermee ook verbetert.