DCount en multivalued fields

[Verwijderd]

Beste tweakers,

Recent ben ik gestart met mijn eerste access 2007 database, ik ben dus een beginner. Ik heb hierbij veel gebruik gemaakt van multivalued lookup fields.

Nu wil ik in een report aantallen berekenen van een specifieke waarde in zo'n multivalue field. Bijvoorbeeld het veld "Ingreep" bevat o.a. de waarden PM de novo, ICD de novo en CRT-D de novo. Ik wil dus bv berekenen hoeveel PM de novo's er zijn. Nu heb ik geprobeerd DCount als volgt te gebruiken:

=DCount("[Ingreep]","[tbl Procedure]","[Ingreep]=PM de novo")

Echter krijg ik een #Error

Op het internet vind ik verschillende adviezen en ook mededelingen dat het niet zou kunnen.

Heeft een van jullie hier ervaring mee?

Bijvoorbaat dank!

[Marko_J]

Voor tekstwaarden heb je quotes nodig, dus het wordt dan;

code:

=DCount("[Ingreep]","[tbl Procedure]","[Ingreep]='PM de novo'")

Het kan ook nog zijn, afhankelijk van je taalinstelling, dat je de parameters met puntkomma ipv komma moet scheiden;

code:

=DCount("[Ingreep]";"[tbl Procedure]";"[Ingreep]='PM de novo'")

[pedorus]

Je krijgt dan iets als:

Visual Basic:

=DCount("*","[tbl Procedure]",
    "[Ingreep].[value]=(select [id] from [ingrepen] where [naam]='PM de novo')")

In een rapport kun je dit waarschijnlijk beter in je query oplossen (count+group by).

Maar liever zou ik een klassiek design gebruiken, zie ook Multivalued datatypes considered harmful.

offtopic:
En de aanduiding "tbl " lijkt mij niet zo nuttig.

[Verwijderd]

Helaas, beide opties werken niet.

De quotes had ik al geprobeerd (de puntkomma's herkent mijn versie niet).

Het volgende werkt wel:
=DCount("[Id]","tbl Procedure")
Maar Id is dan ook geen multivalued field.

Ten aanzien van de multivalue fields kom ik naarmate ik wat dieper zoek inderdaad vaak tegen dat het gebruik afgeraden wordt. Helaas heb ik mijn DB al zo opgezet en gevuld met data.

Ik denk idd dat ik eerst een query zal moeten gebruiken zoals voorgesteld. Toch jammer, je zou denken dat dit toch mogelijk moet zijn.

Bedankt voor de moeite ieg!

ps: wbt "tbl", dit is idd overbodig (al doende leert men!)

[pedorus]

Voor de duidelijkheid: ik weet vrij zeker dat mijn optie werkt, omdat ik het me ook afvroeg en het heb uitgeprobeerd. Ik denk dat je [id] (de id van de lookup-tabel waarin het lijstje staat), [ingrepen] (de naam van de lookup-tabel), en [naam] (de naam van het gekoppelde veld dat je weergeeft in het lijstje) niet in de juiste waardes hebt vervangen. Over het algemeen wil je trouwens in combinatie met een conditie op "*" tellen: het totaal aantal rijen dat matched.

Dat neemt niet weg dat een query handiger/beter kan zijn.

[Verwijderd]

Ok, dan heb ik het inderdaad niet goed gedaan.

Maar, met excuses voor mijn trage uptake, ik begrijp het nog niet goed.

=DCount("*","[tbl Procedure]","[Ingreep].[value]=(select [Id] from [ingrepen] where [naam]='PM de novo')")

Id, ingrepen en naam zijn mij niet duidelijk.

"[id] (de id van de lookup-tabel waarin het lijstje staat)". Ik weet niet wat je hiermee bedoelt.

"[ingrepen] (de naam van de lookup-tabel)". De naam van de lookup tabel zelf is "subtbl Ingreep" (bijvoorbaat excuses voor subtbl . Bedoel je dat?

"[naam] (de naam van het gekoppelde veld dat je weergeeft in het lijstje)". Ik had dit geïnterpreteerd als [name].

ps als je een tip hebt voor een goede uitleg site zou dit erg welkom zijn (tot op heden gebruik ik de MS site en het access voor dummy boek).

Thanks

[Marko_J]

Ik denk dat pedorus het volgende bedoelt; om van multivalued fields af te komen, heb je een aantal nieuwe tabellen nodig. Een kleine tabel met 'ingrepen' bijvoorbeeld. Dat wordt een lookup-tabel genoemd omdat dat z'n enige functie is; om een lijstje te kunnen maken met beschikbare ingrepen.

Het belangrijkste bij het opzetten van een database is het uitwerken van de datastructuur. Een voorbeeld van een verkeerde, niet-relationele structuur:

Tabel "Klanten"
Bedrijfsnaam | Adres | Plaats | Telefoon | Contactpersoon | GSM

Hier kom je in de problemen zodra je meer dan 1 contactpersoon bij een klant wilt kunnen opslaan. Dan moet je of een extra record aanmaken voor de nieuwe persoon - waardoor bedrijfsgegevens dubbel opgeslagen worden, of - nog erger - een nieuw veld Contactpersoon2 toevoegen aan de tabel. Beide zijn niet wenselijk. En de derde optie, om van Contactpersoon een multivalued field te maken, wordt dus afgeraden

De klassieke relationele opzet; je wil gegevens zoveel mogelijk in hun eigen tabellen opslaan, en daar relaties tussen leggen. Daar komen de ID-velden bij kijken. Het is gebruikelijk om in elke tabel een ID veld te hebben. Met de eigenschap autonummering krijgt dit veld vanzelf een unieke waarde, en daarmee kan het gebruikt worden om records te identificeren en aan elkaar te relateren.

Zelfde voorbeeld in relationele opzet:

Tabel "Bedrijven"
ID | Bedrijfsnaam | Adres | Plaats | Telefoon

Tabel "Contactpersonen"
ID | Bedrijf_ID | Naam | GSM

In het veld bedrijf_id wordt dan de waarde van het id-veld van het bijbehorende bedrijf opgeslagen. Via een query zijn deze gegevens dan weer samen te brengen. Dit wordt een 1-op-veel relatie genoemd; 1 bedrijf kan meerdere contactpersonen hebben. Terwijl 1 contactpersoon altijd werkzaam is bij 1 bedrijf.

In jouw voorbeeld; een procedure bestaat uit een x-aantal ingrepen. Waarschijnlijk is het zo dat ingrepen ook bij meerdere procedures terug kunnen keren? Dat is dan een veel-op-veel relatie, en daar komt een derde tabel bij kijken, een koppeltabel.

"Procedures"
ID | procedure_naam | omschrijving | etc

"Ingrepen"
ID | ingreep_naam | omschrijving | etc

"Procedure_ingrepen"
Procedure_id | Ingreep_id

De koppeltabel bevat in essentie maar twee velden; id van procedure en id van ingreep. Zo zijn alle combinaties te maken; een procedure kan uit X ingrepen bestaan, en een ingreep kan voorkomen bij Y procedures. Via queries zijn deze gegevens volgens te combineren en selecteren.

Een nuttige link heb ik verder niet echt, maar met zo'n dummy boek moet je al een eind op weg komen volgens mij.

[Verwijderd]

Dank Marko,

Ik heb inderdaad redundancy geprobeerd te vermijden. Ik heb begrepen dat de multivalue fields in feite ook werken met een koppeltabel, maar dan op de achtergrond. Maar nu begint duidelijk te worden dat, om technische redenen die ik nog niet helemaal begrijp, dit niet exact klopt (zie link pedorus). Dit geeft dan weer problemen met het querieen.

Toch heb ik het idee dat pedorus niet het omgooien van mijn huidige DB bedoelde.

Maar, in mijn volgende DB zal ik zeker 'old fashioned' gaan.

Grt

[pedorus]

Verwijderd schreef op zondag 16 mei 2010 @ 09:05:
=DCount("*","[tbl Procedure]","[Ingreep].[value]=(select [Id] from [ingrepen] where [naam]='PM de novo')")

Id, ingrepen en naam zijn mij niet duidelijk.

Als je een lookup maakt dan krijg je in de wizard op het eerste scherm twee opties. Waarschijnlijk heb je voor "I will type in the values that I want" gekozen, in plaats van voor een tabel. Dit heeft als nadeel dat dezelfde string/tekenreeks meerdere keren in de database komt te staan, wat meer opslag kost en lastiger is te wijzigen/indexeren. Je hebt echter geen aparte tabel nodig, en DCount is ook een stuk makkelijker:

Visual Basic:

=DCount("*","[tbl Procedure]","[Ingreep].[value]='PM de novo'")

Verwijderd schreef op zondag 16 mei 2010 @ 19:00:
Toch heb ik het idee dat pedorus niet het omgooien van mijn huidige DB bedoelde.

Dat klopt. In principe is trouwens de koppeltabel die je niet ziet onderhuids wel degelijk aanwezig in access. In die zin maakt het dus vooral verschil als je de boel ooit wil overzetten (dat zal lastiger zijn) naar zeg SQL Server. Voor queries kun je desnoods een view maken die die koppeltabel beschikbaar maakt (query definiëren als "select id, ingreep.value from [tbl Procedure]"), hoe efficiënt dit is weet ik enkel niet.

[Verwijderd]

@pedorus

Doorbraak, die laatste optie van je werkte als een charm!

Overigens heb ik juist wel gebruik gemaakt van lookup tabellen. Mijn inziens waren de voordelen hiervan groot, namelijk geen typefouten en de mogelijkheid om de opties later aan te passen.

Maar super, ontzettend bedankt voor de hulp, ik kan nu voort.

Groet!