[VB] Access

[ocke]

Ik heb een formulier gemaakt dat gebruik moet maken van verschillende tabellen. Ik bedoel daarmee:

Ik heb de tabellen: uren 2000, uren 2001, uren 2002. Daar komen ieder jaar natuurlijk steeds eentje bij. Nu wil ik het als volgt. Je vult in een onvoerschermpje het jaartal in, en aan de hand daarvan opent hij de goede tabel.

Nu heb ik in VB een public variable gemaakt die "uren" heet, en hij vult die variable met: uren = "uren" & jaar. Jaar = de value van het tekstvak waar je het jaar tal invoert. De variable uren krijgt dan dus de waare "uren 2002", als je bv 2002 invoert in het tekstvak "jaar". Nu moet ik die variable gebruiken in een sql query. Dus de regel FROM uren 2002, moet vervangen worden door FROM uren (waarbij uren de variable is uit mijn vb code).

Zo (hoop ik) krijg je een dynamsich formulier, en aan de hand van welk jaar tal je invoert in het tesktvak "jaar", gebruikt de sql die tabel.

[Verwijderd]

Maar is nu concreet je probleem/vraag

[ocke]

nou euh.. et werkt niet .
Ik krijg de hele tijd foutmeldingen. Dus ik zal wel iets fouts hebben geproged, en et zal zo blijkbaar niet werken. Dus hoe moet het wel ? Kan ik wel vb variable gebruiken in sql, enzo jah hoe roep ik die aan?

[Verwijderd]

zet eens blokhaken om je tabelnaam heen!?

en nog beter gebruik geen spaties in tabelnamen.

verder zal je huidige code ook foutlopen, omdat je een statement maakt ala Select * from uren2002 i.p.v. uren 2002 . wat dus ook fout is, want dat gaat SQL niet snappen. Je VB zou iig uren = "uren " & jaar

[Sponge]

Spaties in tabelnamen is dodelijk.. gebruik dan een underscore (_) oid, denk dat dat het probleem kan zijn

[whoami]

Misschien iets heel anders, maar ik denk niet dat het zo'n goed idee is om voor ieder jaar een tabel bij te maken. Dit getuigt niet echt van een goed datamodel.
Het is beter dat je de uren in 1 tabel opslaat en op een andere manier bijhoudt op welk jaar die uren slaan. (Bv een extra veldje waar het jaartal in staat).

[Crazy D]

whoami schreef op 28 augustus 2002 @ 09:26:
maar ik denk niet dat het zo'n goed idee is

Ik denk dat je het wel rustig als feit kunt brengen, aangezien een tabel per jaar geen goed idee is.
En daarnaast maak je je het onnodig lastig. Niet alleen voor je selectie, maar ook voor bv reportjes, of als je eens wilt weten hoeveel uur er de afgelopen 3 jaar is gemaakt, of weet ik wat voor dingen je nog meer kunt willen weten En erg flexibel ben je imho ook niet (wat nou als er een veld wordt toegevoegt, dan moet je of in al je voorgaande-jaren tabellen dat veld toevoegen, of niet maar dan moet je weer bijhouden tot welk jaar dat veld er nog niet in zit). En, tenzij je miljoenen records per jaar moet toevoegen, zal het de gemiddelde database een zorg zijn die kan het toch wel aan (naja miljoenen records ook wel maar je snapt me wel dan zou je altijd nog een archief-tabel kunnen overwegen).

[ocke]

whoami schreef op 28 augustus 2002 @ 09:26:
Misschien iets heel anders, maar ik denk niet dat het zo'n goed idee is om voor ieder jaar een tabel bij te maken. Dit getuigt niet echt van een goed datamodel.
Het is beter dat je de uren in 1 tabel opslaat en op een andere manier bijhoudt op welk jaar die uren slaan. (Bv een extra veldje waar het jaartal in staat).

Jah wat moet ik daar tegenin brengen .

Dit was eerst het geval, maar heb ik ervoor gekozen om dit te splitsen vanwege een paar redenen. Ten eerste wou niemand eigenlijk de data langer als 3 maanden bewaren, maar alleen de baas wou eigenlijk het liever niet verwijderen: voor als ie het toch nog een x nodig had. MAar waarom dan gewoon geen grote tabel? Omdat dat SOOOOOO fucking langzaam is. Een jaar geeft toch gauw 50.000 record, en die allemaal met sql doorzoeken durde toch wel 20 sec PER invoerschermpje !!! En geloof me als je ff snel info wilt zien over een jaar (hoeveel er bv in een bepaald maand is gewerkt) wil je niet telkens 20 sec w88 voordat je een maand kan selecteren.

Daarom heb ik maar voor een tabel per jaar gekozen. Zo gaat het nml STUKKEN sneller. Want moet jij eens opletten wat sql het uitmaakt of ie 50.000 record moet doorzoeken of 300.000 (en daar komen er iedere dag een 140bij (ongeveer))

En die tabellen (van vorige jaren) benader je toch niet (want eigenlijk vond de rest van het bedrijf onzin als je ze langer bewaarde als 3 maanden, mar jah de baas is de baas ).

Maar iig thx voor de tips. Ik ben er btw al uit, het werkt nou

[Verwijderd]

neem aan dat je dan iig indexes heb gelegd op jaar en maand... maar iets anders.... Access gebruiken voor ZO"N grote database is niet echt verstandig. geen mogelijkheid om er een SQL Servertje achter te hangen?!

[Gerco]

Ik heb hier ook een Access database met zo'n 50.000 records in 1 tabel, maar een zoek-en-selecteer actie van zo'n 200 records uit die 50k, neemt toch echt niet meer dan een halve seconde in beslag (hooguit 1) op een P166(!).

Als je zoekacties op 50K records zo lang duren, doe je toch echt wat verkeerd met je indexen.

[whoami]

Als je in een database al zou moeten gaan beperken op het aantal records per tabel, dan zou het wel mooi worden. Zoals reeds gezegd werd, als je goede indexen legt op de tables, dan maakt het niet uit of je nu zoekt in een tabel van 100 records of een tabel van 10.000 records.

[Crazy D]

Als bij normaal gebruik enkel de laatste x-maanden van belang zijn, en de voorgaande jaren enkel voor de baas aanwezig zijn, zou je dus nog kunnen overwegen een archief-tabel te gebruiken, en eens in de zoveel tijd even een "verplaats naar archief" query te runnen. Maar qua database kan Access zoveel records wel aan, dus daar hoef je het op zich niet voor te doen. Kijk wel (zoals al gezegt) even naar je indexen (indices ) die dingen kunnen wonderen doen

[ocke]

hmmz.. idd indexen stond op nee. Ik heb het ff uitgeprobeert en idd is het nu nog geen sec kwestie thx.

[ocke]

whoami ff tussen door. Jij sloot mijn andere topic omdat ik blijkbaar niet ff iets opzoek. Maar als je goed leest zul je zien dat ik de help file heb zitten lezen. En die help gaf zelf aan dat het jjjj moetst zijn. Ik heb de hele help file nog eens doorgekeken, maar hij zegt nergens iets over yyyy, sterker nog de help geeft zelf in de voorbeelden aan dat het jjjj moet zijn.

Dus euh... ik kan goed begrijpen dat jij zoiets hebt van lees eerst ff de help door... die help had het zelf mis. Even goede vrienden, en thx voor beantwoorden van me vraag.

[n0kn0k]

ocke schreef op 28 augustus 2002 @ 11:47:
whoami ff tussen door. Jij sloot mijn andere topic omdat ik blijkbaar niet ff iets opzoek. Maar als je goed leest zul je zien dat ik de help file heb zitten lezen. En die help gaf zelf aan dat het jjjj moetst zijn. Ik heb de hele help file nog eens doorgekeken, maar hij zegt nergens iets over yyyy, sterker nog de help geeft zelf in de voorbeelden aan dat het jjjj moet zijn.

Dus euh... ik kan goed begrijpen dat jij zoiets hebt van lees eerst ff de help door... die help had het zelf mis. Even goede vrienden, en thx voor beantwoorden van me vraag.

jjjj=jaarjaarjaarjaar
yyyy=yearyearyearyear

is hetzelfde hoor ligt eraan met welke taalversie van access je werkt

[ocke]

met de nederlandse.... Daarom vind ik het zo raar dat er 1 in de help over j wordt gesproken, en dat y werkt (EN J NIET).

[Verwijderd]

Vanaf versie 2000 zijn alle VBA code voor zowel de nederlandse als de engelstalige versie verandern naar (standaard) de engelstalige. Dit heeft mij behoorlijk wat werk opgeleverd aan vertalen. kan dus zijn dat je help files misschien nog verouderd zijn

[ocke]

Ze hebben hier 97 draaien jah MAar ach, nu weet ik het, nu kan ik er rekening mee houden