een selectiecriteria met de tabelnaam in een variabele

Status
Niet open voor verdere reacties.
Sytse1

Sytse1

Gebruiker
Lid geworden
9 aug 2007
Berichten
584
Office versie
miDer
De naam van de tabel is variabel vandaar ik deze naam uit het form haal.
De naam wordt keurig in de de variabele NmTbl gezet.
De volgende selectie query geeft de foutmelding dat de tabelnaam in de variabele niet gevonden wordt?
Wie kan miij vertellen wat er fout aan is.
Code: 
Dim dbs As Database, rst As Recordset
Dim strCriteria As String
Dim NmTbl As String
NmTbl = Forms!F_mj1!IdMw 'Hier staat de tabelnaam 
Set dbs = CurrentDb
Set rst = dbs.OpenRecordset("SELECT NmTbl.Idmw, NmTbl.DatumenDag, NmTbl.Jaar, NmTbl.SoortVerlof, NmTbl.Uren FROM NmTbl" & _
" WHERE NmTbl.IdMw =" & [Forms]![F_mj1]![IdMw] & " And " & "NmTbl.Jaar = " & [Forms]![F_mj1]![Jaar] & " ORDER BY NmTbl.SoortVerlof", dbOpenDynaset)
 
Ik vraag me af of je de code wel goed hebt overgenomen, want ik zie vermoedelijk wel een foutje: je vult de variabele NmTbl (die je overigens niet nodig hebt) met het veld IdMw, en je gebruikt hetzelfde veld als filter voor het veld IdMw. Mij lijkt het niet logisch dat een tabelnaam hetzelfde is als de waarde van het sleutelveld. Maar goed, er vanuit gaande dat het wel zal kloppen, ziet de code er zo uit. Een stuk simpeler...
Code: 
Dim rst As DAO.Recordset
Dim strSQL As String
    strSQL = "SELECT Idmw, DatumenDag, Jaar, SoortVerlof, Uren FROM " & Me.Tabelnaam & " WHERE IdMw = " & Me.IdMw & " AND " & "Jaar = " & Me.Jaar & " ORDER BY SoortVerlof"
    Set rst = CurrentDb.OpenRecordset(strSQL, dbOpenDynaset)
Meer als dit heb je niet nodig. Sowieso is het volslagen overbodig om in een query de tabelnaam op te nemen, en al helemaal als je query maar uit één tabel bestaat. Dan gebiedt de logica dat per definitie alle velden uit die tabel komen. Je moet alleen tabelnamen gebruiken in het geval je meerdere tabellen gebruikt, waarin dan ook nog eens identieke tabelnamen voorkomen. In een query van 6 tabellen waarin 6 keer het veld ID voorkomt, moet je in de query wel aangeven uit welke tabel je een ID pakt. Maar daar is hier dus geen sprake van. Kortom: laat weg wat je weg kan laten, en maak het jezelf niet nodeloos ingewikkeld.

Wat je nooit kan doen, is de naam van een variabele in een string gebruiken. Zoals je nu dus deed. Je moet altijd de waarde van de variabele gebruiken, nooit de naam[/I. ]Waar je de tabelnaam dus los moet halen van de string, is in de FROM sectie, want daar stel je de query samen op basis van de tabelnaam. En dat gebeurt nu dus ook, en dat stuk had je zelf ook al min of meer correct gebruikt. Dat principe had je dus ook moeten toepassen voor de veldnamen.
 
Beste Octafish,
Bedankt voor je uitgebreide antwoord.
Wellicht ter verduidelijking.
Op basis van het id van een (nieuwe) medewerker wordt een nieuwe tabel gemaakt.
Deze tabel heeft dus dezelfde naam, in dit geval een nummer, als het id van de medewerker.
De query is dan ook een overzicht van de betreffende medewerker.
Om de query voor elke medewerker te gebruiken, wil ik de naam(nummer) van de tabel in de variabele zetten.
Zodat van uit een function deze query steeds gebruikt kan worden. Wellicht heb ik het te ver gezocht. Ik begrijp je stelling. De tabel en mederwerker zijn al aanwezig dus waarom die nogmaals aanroepen middels de selectie.
Ik ga jou oplossing straks in de functie zetten.
Nogmaals bedankt,
Sytse
 
Laatst bewerkt:
Sytse1 zei:
Op basis van het id van een (nieuwe) medewerker wordt een nieuwe tabel gemaakt.
Klik om te vergroten...
Wat lijkt mij dat een ongelooflijk slecht idee! Ik kan mij geen enkele situatie voorstellen waarin je per medewerker een eigen tabel nodig hebt. Dat moet een heel bijzonder bedrijf zijn :).
 
Je hebt ongetwijfeld gelijk.
Ik weet echter geen betere oplossing.
Ik heb een tabel die een loopt tot 2030.
Start op zondag 1 januari 2017 en vervolgens is elke dag 1 REC. Verder heeft dit REC een paar velden velden. 1 waar de soort afwezigheid wordt in gezet bv V van verlof het aantal uren en een omschrijving. Nu zou het zo kunnen zijn dat bij de invulling door de medewerker zijn id bij dit record wordt gezet. Maar er kunnen bij deze datum natuurlijk meerdere mederwerkers hunafwezigheid registreren. Het totaal overzicht blijft voor het jaar zichtbaar. Vandaar dat ik gekozen heb om per medewerkers ieder een eigen tabel toemaken. Deze tabel wordt dan bij de registratie van de medewerker gemaakt.
Het aantal medewerkers kan variabel zijn afhankelijk van het bedrijf. Als aantal medewerkers vastgelegd zou zijn zou ik wellicht met 1 tabel toekunnen. Voor elke medewerker een veld waar zijn Id in vastgelegd kan worden. Maar nu ik dit zo schrijf is dit het overwegen waard. Verder sta ik open voor elke andere oplossing.
 
En nu val ik nog verder van mijn stoel.... Je wilt blijkbaar de aan- en afwezigheid van een werknemer registreren. Prima, is simpel te doen, heb ik regelmatig gemaakt. Maar ik heb aan één tabel meer dan voldoende, waarin ik alleen de aanwezigheid/afwezigheid vastleg. Dus de dagen dat de werknemer aanwezig is )werkt en niet aanwezig is (verlof/ziekte/vakantie etc). Dat is meer dan voldoende, want doorgaans leg je óók het werkschema van een werknemer vast. En als dat een wisselend schema is, heb je altijd nog de contracturen. Kortom: een database gebruik je om data vast te leggen, niet om er een soort excelletje van te maken waarin je maar alvast 30000 records vult voor het geval de wereld n íet voor 2030 is vergaan :).
Ik zou jouw database niet graag overnemen, kan ik je zeggen :D
 
En dan krijg je wat andere programma's ook doen. De medewerker vult in van tot of een of enkele dagen. Ik wilde iets totaal anders. En dat is inderdaad niet echt op z'n db's. Het zal wel vloeken in de kerk zijn
En inderdaad lijkt het een beetje Exeliaans
Ik probeer vanuit een gebruiker te redeneren en voor die het zo simpel mogelijk te maken.
 
Sytse1 zei:
Ik probeer vanuit een gebruiker te redeneren en voor die het zo simpel mogelijk te maken.
Klik om te vergroten...
Dat is an sich natuurlijk prima, maar bovenal moet je bouwen vanuit de integriteitsregels van de database. Het gaat uiteindelijk om het op correcte wijze vast kunnen leggen van de gegevens en die er vervolgens ook weer uit kunnen halen. Gebruikersgemak heeft alleen te maken met de UI die je bouwt, dus de formulieren en rapporten. Maar gebruikersgemak heeft niets te maken met tabelinrichting.
 
Helemaal met je eens. De integriteitsregels houden volgens mij in: Bij het ontwikkelen van een informatiesysteem voor een organisatie moet er koste wat koste voor gezorgd worden, dat er geen tegenstrijdige gegevens in de database terecht komen. Tevens voorkomen dat dezelfde gegevens meerdere malen wordt vastgelegd. Voor zover mijn kennis reikt probeer ik dit.
Ik probeer het dan ook vanuit verschillende invalshoeken. Als ik weer eens vast loop is jouw hulp dan ook meer dan welkom.
 
Je vergeet de belangrijkste regel: gegevens die bij elkaar horen, staan in één tabel. En laat dàt nou de regel zijn die jij behoorlijk overtreedt nu :). Want volgens mij is de ene werknemer krek gelijk (voor de database) aan de andere werknemer.
 
Alle werknemers staan bij mij in 1 tabel;) maar het zal ongetwijfeld beter kunnen.
 
Hè? Het ging er toch om dat je voor elke werknemer een aparte tabel wil maken? Ik ga effe offline, op zoek naar het draadje; moet hier nog ergens liggen :D
 
Ik heb een tabel met alle werknemers die gekoppeld is aan een tabel met een overzicht van zeg maar een kalendertabel.
Misschien niet zo elegant maar als meerdere medewerkers een datum in de kalendertabel invullen wordt in deze tabel een kopie van het record in de kalendertabel gemaakt.
Dit record krijgt dan het id van de medewerker.
Ik heb in het begin voor elke medewerker een kalendertabel gemaakt dat was teveel van het goede.
Je weet het, beter ten halve gekeerd dan volledig verdwaald.:D
 
Je hebt dus een werknemertabel en een kalendertabel, die je dan vermoed ik met een één-op-veel relatie gekoppeld hebt en waarin je voor elke registratie een apart record aanmaakt? Lijkt mij de enige juiste oplossing :).
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan