[Visual Basic] zoekcode binnen een file*

[Verwijderd]

Ik heb een tekstbestand wat er als volgt uitziet:

0010, "Amstelveen"
0080, "Leeuwarden"
0082, "'s Gravenhage"
....
1000, "Pieterburen"
1700, "Rotterdam"
..etc..

Nou wil ik deze tabel opnemen in een module functie.

De bedoeling is simpelgezegd een gebruiker typed in een formulier de code "0080" en dan moet de code ff snel in die array / of type / functie zoeken naar de bijbehorende gemeentenaam in dit geval.

De codes lopen niet mooi van 1,2,3,4 etc. maar er zitten soms flinke gaten tussen. De laagste waarde is 3 en de hoogste waarde is trouwens rond de 1700.

Hoe plaats ik nou die tabel in een module functie. Als Type definitie? Een array ? Ik moet er dus snel ik kunnen zoeken op code... en t moet ook een beetje onderhoudbaar zijn dat er dus codes bijkomen of veranderen dat dan niet al te veel moeite is.

Ik ben een beetje uit VB om eerlijk te zijn. Jaren niks meer meegedaan. Wie kan ff de richting aangeven hoe ik het het beste kan doen.

[urk_forever]

Kan je niet beter die waardes in een simpele database gooien en daar dan met vb in gaan zoeken?

[Dido]

Twee suboptimale oplossingen:
Definieer de arry gewoon met 1700 elementen en laat er een zooi leeg (kost geheugen)
of
Doorzoek bij ieder request de hele array lineair (kost tijd)

Voordeel tweede methode: het lijkt me makkelijker om fouten (foute invoer) af te vangen.

Betere oplossingen:
Gebruik een database... of COBOL (Die kent het commando SEARCH om een waarde uit een array te halen)

[Verwijderd]

Gebruik een geindexeerde array wellicht ?!
Text bestand aanpassen lijkt me..

[DigiK-oz]

De plaatsnamen in een (eventueel hidden) listbox stoppen, de codes per naam in de .itemdata van deze entry ?

Zoeken gaat dan vrij vlot, je kan eventueel ook precies andersom zoeken (naam bekend, code gevraagd) en je kan zonder problemen een dikke 32000 namen er in kwijt.

[Verwijderd]

Op donderdag 11 april 2002 17:42 schreef sjis het volgende:
De plaatsnamen in een (eventueel hidden) listbox stoppen, de codes per naam in de .itemdata van deze entry ?

Zoeken gaat dan vrij vlot, je kan eventueel ook precies andersom zoeken (naam bekend, code gevraagd) en je kan zonder problemen een dikke 32000 namen er in kwijt.

Allemaal bedankt voor jullie reakties. Ik denk dat ik de suggestie van Sjis overneem want dat is wel zo gemakkelijk te maken. In reaktie op alle anderen:

aparte database: heb ik aan gedacht maar dan komt er weer een file bij en ik houd liever 1 clean .exe file voor distributie. k heb ook gedacht aan een type definitie en die dan vullen met waarden x 1700 en dat opslaan in een .dat file maar dat vond ik eigenlijk ook niet mooi.

cobol o.id.: Nah t moet in VB, bovendien heb ik die applicatie al helemaal klaar en is die tabel alleen nog maar franje want zonder tabel werkt t ook wel.

Dido had ook een goed idee:

Definieer de arry gewoon met 1700 elementen en laat er een zooi leeg (kost geheugen)
of
Doorzoek bij ieder request de hele array lineair (kost tijd)

Aan dat eerste heb ik ook gedacht, die methode heeft ook nogal wat voordelen want als een gebruiker dan een waarde intyped kun je 1 op 1 over in je functie naar de bijbehorende gemeente naam. Dus geen zoekfunctie nodig eigenlijk. De 2 e methode. Hmm heeft ook wel wat.

Ik ga eerst dat van Sjis proberen en als alternatief optie 2 van Dido.

Tnanks all !

[Lister]

Voor zoiets gebruik ik altijd een collectie in VB, dat werkt perfect.

De elementen voeg je dan in een loop als volgt aan je collectie toe:
colGemeentes.Add <gemeentenaam>, "KEY_" & <gemeentenummer>

Met colGemeentes("KEY_" & <gemeentenummer>) kan je dan direct de gemeentenaam opvragen zonder te zoeken.
Als het gemeentenummer niet voorkomt krijg je wel een foutmelding die je moet afvangen.

De key moet altijd een string zijn, daarom zet ik er "KEY_" voor zodat je geen fouten kan maken bij het opvragen.
colGemeentes(1) levert namelijk het eerste element van de collectie op, terwijl colGemeentes(CStr(1)) het element oplevert dat de key "1" heeft!

Ik hoop dat het een beetje duidelijk is.

[PdeHoog]

Een mogelijkheid is natuurlijk ook om de data gewoon in het tekstbestandje te laten staan en dan met een FSO (FileSystemObject) en TextStreaming het bestand uit te lezen en zoeken op de eerste posities van een string.

FSO is tenslotte razendsnel.

[Verwijderd]

Ik heb helaas even niet de tijd om het na te zoeken, maar volgens mij kan je via ODBC ook tekstbestanden koppelen aan je VB.

Op die manier maakt het niet uit of het nu een textbestand of bv. een sql database is waarin je gegevens staan.

[PdeHoog]

Op vrijdag 12 april 2002 09:09 schreef Popi het volgende:
Ik heb helaas even niet de tijd om het na te zoeken, maar volgens mij kan je via ODBC ook tekstbestanden koppelen aan je VB.

Op die manier maakt het niet uit of het nu een textbestand of bv. een sql database is waarin je gegevens staan.

Waarom zou je in vredesnaam een tekstbestandje via ODBC willen gaan benaderen als je textstreaming hebt?

[stylee]

Omdat je dan SQL en ADO erop kan loslaten?

[PdeHoog]

Op vrijdag 12 april 2002 16:38 schreef stylee het volgende:
Omdat je dan SQL en ADO erop kan loslaten?

Daar zit wat in . Effe niet aan gedacht!

[johnwoo]

Je kan er ook n mooie hash table van bakken, met, pak em beet, 50 entries ofzo... Daarmee kan je ook lekker snel zoeken (sneller dan een DB)