Rekenen

Status
Niet open voor verdere reacties.
Debuggen is ook een kunst :D

Om je probleem te tackelen heb ik het direct window in de VB editor gebruikt (wordt zichtbaar middels CTRL+G. Als er een code regel geel is kun je daar heel veel informatie mee boven tafel krijgen. Jou WHERE clausule zag er zo uit:

Soortbewerking =9 and Categorie-id = 2and Oppervlakte-id =9

Hier kun je al twee fouten in zien: Soortbewerking is een veld dat niet in je tabel prijzen voorkomt en voor de tweede and moet nog een spatie komen.
Verder is een streepje ( - ) een beschermd karakter. Als je beschermde karakters in veldnamen gebruikt dan moet je daar extra moeite voor doen in je code. In dit geval zul je de veldnamen met beschermde karakters tussen vierkante haken moeten plaatsen. Om die rede noem ik foreignkeys meestal CategorieID of OpperlakteID, dan heb je daar geen last van.

Je complete statement zou er dus als volgt uit mpoeten zien:

dblPrijs = DFirst("Prijzen", "prijzen", "[Soortbewerking-id] =" & CStr(Me.cmbBewerking) & " and [Categorie-id] = " & CStr(Me.cmbCategorie) & " and [Oppervlakte-id] =" & CStr(intOpp))
 
Dank je. Is het misschien verstandig om het streepje gewoon weg te laten dan? Of maakt het verder niet zoveel uit?
 
Ja, dat is wel verstandig, maarrrrrrr..........

In je tabel Prijzen staat het streepje ook in de veldnamen.
Als je het daar wijzigt zul je het ook op ALLE plaatsen moeten wijzigen waar de betreffende velden gebruikt worden, dat gaat namelijk niet automatisch. Houd daar dus rekening mee.
 
Dat zijn er zoveel toch niet. Alleen drie in de code en drie in de tabel. Of zit ik er dan langs.
 
Wat dacht je van de comboboxes op je formulieren?
Of in queries?
Of in rapporten?
 
Rapporten heb ik nog niet gemaakt. En in de query's veranderd Access dat bij mij wel automatisch. En voor de combobox gebruik ik toch de query's. Volgens mij gaat het gewoon goed.
 
OK. Ik hoop dat je het nog niet vervelend vind. Ik houd graag discussies omdat ik er dan meestal wel wat van kan leren. Daarom vraag ik ook zo veel. Als je het moe bent moet je het gewoon zeggen.

Wederom bedankt,
Bart
 
Ach ik help je graag omdat je dezelfde voornaam hebt als ik :cool:
 
Haha dat is mooi. Mijn volgende vraag is:
Ik zit op stage en heb een grote database in mijn handen geschoven gekregen. Mijn baas heeft deze zelf gemaakt en alles werkt redelijk. Maar er zitten heel veel fouten in. Veel redundantie enzovoort. Nu is mijn vraag, waar kan ik zien hoe ik moet beginnen met normaliseren. Is daar een cursus of zo voor want ik kan niet zo snel iets vinden. Mijn leraar had het ook over DFD's maken om te beginnen, dan is alles duidelijk zegt hij.
 
Jullie zetten met z'n tweeen een lekkere boom op!:D

Om in te gaan op je vraag:
Wat ik altijd doe is alle velden opschrijven en aan de hand van onderlinge afhankelijkheden de velden groeperen. Dit werkt voor mij al 15 jaar. Ik heb wel eens case tools gebruikt enzo maar die gaven altijd verkeerde informatie. Houdt de normaliserings regels in gedachten, normaliseer tot en met de BCNF (Boyce-Codd normal form) en in 90% van de gevallen komt het wel goed.

Heb je echter te maken met een dynamische database waarbij veel parent child relaties worden gebruikt dan zal je het een en ander anders moeten doen. Dan worden de onderlinge relatie ook dynamisch en dat moet je weer anders oplossen.

Weest gegroet,
guus
 
Hoi Guus,

bedankt voor je antwoord.
Ik moet een offertedatabase gaan maken. Dwz er worden nu op een omslachtige manier offertes gemaakt, via excel en word. Deze dBase moet worden toegevoegd aan de huidige database, die nog up-to-date gemaakt moet worden. Maar het probleem is dat mijn baas iedere keer wat erbij verzonnen heeft, en maar weer een tabelletje heeft gemaakt om alles simpel op te lossen. Ik wil nu eigenlijk alles opnieuw gaan maken en meteen goed, er moet straks door mij of een volgende stagair ook een internetkoppeling gemaakt worden. klanten moeten dan de huidige status van hun order te zien krijgen. Maar afijn, ik wil op 0 beginnen. Dus alles opnieuw opzetten. Moet ik dan beginnen met tabellen te maken of echt alles op papier zetten. Denk wel meer als 100 verschillende veldjes nodig. Adviseer je toch om alle veldjes uit te schrijven? En hoe deel ik die dan in daarna?
 
Volgens mij betreft het inderdaad een normale database. Die normaliseer je met de normaal vormen. Ik kreeg de indruk dat je wist hoe dat werkte. Op deze link http://home.student.utwente.nl/s.p.ekkebus/portfolio/files/Paper_DB_normalisation.pdf vind je in ieder geval een beetje uitleg. 100 velden is niet veel.:D Je begint bij de eerste en je eindigd bij 100. Handig hulpmiddel is Excel. Slepen met veldjes gaat daarin een stuk makkelijker dan steeds alle honderd opschrijven.

Succes!
HTH
Weest gegroet,
Guus
 
Bart, Guus,

Een bestaande database normaliseren is bijna niet te doen.
Wat je bij normaliseren doet is het wijzigen van de inhoud en de structuur van de tabellen waaruit de database bestaat.
Dit zal tot gevolg hebben dat de queries, formulieren, macros, rapporten en modules in de toepassing niet meer zullen werken en dus ook aangepast moeten worden. Dat is bijna niet te doen (geloof me, ik spreek uit ervaring).

De beste manier om dit soort dingen aan te pakken is in mijn ogen uithuilen en opnieuw beginnen.

Begin met een goede informatie analyse. Hierbij gebruik je access helemaal NIET!
Ga na wat voor informatie er nodig is. Ga na wat voor rapporten er nodig zijn. Ga na wie wanneer welke informatie tot zijn of haar beschikbaar krijgt en in welke vorm die informatie beschikbaar gesteld wordt.
Deze zaken bij elkaar bepalen wat er opgslagen moet worden, wanneer er zaken opgeslagen moeten worden en wat de handigste manier is om die zaken op te slaan.
Dit alles bij elkaar vormt je database ontwerp, pas als dat compleet is begin je in access.
Je begint dan met het opzetten van je tabellen en de relaties daartussen.
Vervolgens maak je de formulieren om de tabellen te vullen en daarna maak je de rapporten.

Oude databases, die historisch (en vaak ook histerisch) gegroeid zijn, zijn in de loop van de tijd meestal moeilijk onderhoudbaar geworden. Het is meestal het beste gewoon iets nieuws te maken.
Een grote uitdaging is die je dan ook nog te gaan hebt is de gegevens uit de oude database naar de nieuwe database over te brengen (conversie).


Bart,

Begin de volgende keer even een nieuwe thread als je een nieuwe vraag hebt.
Dan horen de antwoorden een beetje bij de titel van een thread dat zoekt makkelijker voor mensen met soortgelijke problemen.
 
In het verleden heb ik diverse databases geconverteerd m.b.v. Access. In Access is het mgelijk snel en eenvoudig queries te maken en uit te voeren. Dit heb ik diverse keren gedaan op verschillende soorten databases. Dit is niet het probleem. Het probleem is dat je te maken krijgt met gegevens in je database die er niet thuishoort. Zo kan het gebeuren dat je records over het hoofd ziet omdat deze niet worden geselecteerd omdat er bijvoorbeeld een sleutel instaat die niet meer gebruikt wordt of dat het brontype niet overeen komt met het doeltype. Als je die fout niet maakt, maar pas later eventueel verkeerd gekozen typen converteerd, zal je veel minder fouten tegenkomen. Wat ook helpt is dat je je database opschoont. Dus alle oude gegevens die je niet meer gebruikt eruit gooien.

Alle queries die uitgevoerd moeten worden, stopte ik dan onder een knop. Op het moment dat er dan geconverteerd kon worden hoefde ik dan alleen op die knop te drukken.

Ik heb Access niet alleen gebruikt om Access databases te converteren maar ook van Access naar MSSQL of van MSSQL naar MSSQL.

Je ziet alles is mogelijk. Je moet wel je hoofd erbij houden.

HTH
Weest gegroet,
Guus
 
Laatst bewerkt:
Guus,

Ook ik gebruik Access al vanaf versie 2.0.
Ik heb in access links gemaakt naar MS SQL server, Oracle, INGRES, SYBASE, Excel, tekstbestanden met ODBC, OLEDB, ADO etc.
De akties die je uitvoerd zijn correct, alleen wel voor mensen die behoorlijk wat ervaring hebben met verschillende soorten databases en de problemen die bij conversies van de ene database naar de andere voorkomen. Dan heb ik het nog niet eens over het feit dat de gegevenstypen niet altijd even goed overkomen van de ene naar de andere database (vooral datums zijn meestal een uitdaging).
Dit zijn echter zaken voor gevorderden. Bart is daar voorlopig nog niet aan toe. Ik probeer bij het beantwoorden van vragen altijd rekening te houden met het feit dat niet iedereen professioneel werkzaam is met dit soort zaken. Dat betekent dat je niet altijd het onderste uit de kan moet halen, maar een voor de vraagsteller behapbare oplossing moet bieden.
Vandaar de richting van mijn antwoorden.

Groet,

Bart
 
Bart(uls),

Het niveau ligt inderdaad niet zo hoog op het helpmij forum. Ik probeer de mensen een stapje verder te helpen. Soms door een direct antwoord op de vraag en soms door een beetje educatie. Vandaar de links. Datums zijn inderdaad de grootste uitdaging. De oplossing die voor mij het beste werkte was de interne integer notatie van de datum. Die kan je converteren naar welk format je maar wilt. Maar dat even terzijde. Ik ga ervan uit dat Bart een automatiseerder op stage is en dat hij wel eens een database heeft genormaliseerd. Als dit niet zo is, Bart, luister dan naar Bart(uls) en begin er niet aan. Als je van puzzelen houdt, kan je hier je vragen kwijt!

HTH
Weest gegroet,
Guus
 
Haha leuk dat jullie zo'n zorgen maken. Ik studeer informatica, maar heb tot 4 weken geleden nog nooit serieus met access gewerkt. Ik heb het gevoel dat ik steeds meer begin te leren en dat dank ik met name aan dit forum (vooral Bartuls). Waarschijnlijk stel ik regelmatig te simpele vragen, maar dan kom ik er niet uit. Ik vind het wel fijn dat er altijd snel gereageerd wordt. En al heb je moeilijke uitleg, dan vraag ik nog wel eens als ik het niet begrijp.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan