[Access] Toevoegen van records lukt vaak wel, maar soms niet

[Warbringer]

Hoi,

Volgens mij mijn 2e post in 3 jaar in het P&W forum maar ok

Ik heb een database in MS access waarmee via een formulier NAWT gegevens (Naam, Adres, Woonplaats, Telefoonnummer etc.) in een tabel gezet kunnen worden.

De gegevens zijn van sollicitanten voor een functie.

Het formulier bestaat uit 5 tabbladen, op het 1e tabblad worden de persoonlijke gegevens toegevoegd, op het 2e scherm de locaties waar de persoon beschikbaar is, op het 3r scherm de werktijden, en als laatste op het 4e scherm voor welke functie(s) de persoon solliciteert.

vanaf het 5e tabblad is het mogelijk standaard brieven te laten samenstellen. geen probleem verder.

Elke sollicitanten krijgt een ID waarmee deze te identificeren is en wat de verschillende records 1-op-1 koppelt.

dus in tabel1 staat

code:

ID     voornaam     achternaam     etc..
1      Piet         Jansen

tabel2 houd de locaties bij waar deze persoon zou willen werken dus
Alle waardes behavle de ID zijn Ja/nee, booleans dus.

code:

ID     Eindhoven     someren     etc.
1      ja            nee

hetzelfde idee voor tabel 3 en tabel 4, het idee is wel duidelijk.

select * from tabel1, tabel2, tabel3, tabel4 where ID ='1';

geeft me dus alle gegevens van sollicitant met ID 1.
geweldig tot zover.

Nou is het via dat formulier mogelijk sollicitanten toe te voegen, gegevens aan te passen, sollicitanten te verwijderen en al.

In de primaire tabel (de tabel sollicitanten met de NAWT gegevens) krijgen sollicitanten een ID door de autonumber functie van Access. Dit getal heeft verder geen betekenis voor de gebruiker, het is gewoon een manier om ervoor te zorgen dat een primary key is die uniek is.

Op dat formulier staan dus een hoop textboxes waar gegevens ingevuld kunnen worden, met een druk op de knop "toevoegen" wordt de volgende code gelanceerd.

code:

If MsgBox("Zijn alle velden ingevoerd?", vbYesNo) = vbYes Then
msgbox("sollicitant toegevoegd")
  Dim Db As Database
  Dim rst, rst2, rst3, rst4 As Recordset
  Set Db = CurrentDb()
  Set rst = Db.OpenRecordset("sollicitanten", dbOpenDynaset)
  rst.AddNew
  rst!voorletters = voorletters.Value
  rst!Roepnaam = Roepnaam.Value
  rst!meisjesnaam = meisjesnaam.Value
  rst!achternaam = achternaam.Value
/*en zo verder dus*/
rst.update
rst.close
db.close

Dit werkt dus. maar SOMS niet.
Er komt dan wel te staan "zijn alle gegevens ingevuld?" en dan kies je "JA" en dan krijg je de melding "Sollicitant toegevoegd" en dan druk je op ok.

De resterende code dan de de record toe moeten voegen, de textboxen leeg maken en weer locken en dit gebeurd NIET.

Net alsof er halverwege gestopt wordt met het uitvoeren van de code.
Het gebeurd als er 1 iemand aan het invullen is, ook als er meerdere zijn.

Vaak is het dat als ik dan kom kijken naar het probleem, en ik annuleer het toevoegen en alle velden worden leeg gemaakt, en locked, en ik ga dan opnieuw invoeren dat het dan wel werkt. Dus het is geen persistent probleem.

Soms wel, soms niet.

Ik dacht eerst dat het lag aan het feit dat er soms meerdere mensen tegelijk aan het invullen waren en dat access per ongeluk 2 keer hetzelfde ID uitdeelde.

De client met formulieren, queries, rapporten en modules staan op de PC zelf.
Via "Tabellen koppelen" wijzen ze naar een Access MDB file die op het netwerk staat.

Ik heb een aantal kleine aanpassingen gemaakt in de code, en ik laat ze er nu mee testen om te kijken of er weer problemen zijn maar het kan soms wel eens een dag duren voordat het probleem zich voordoet.

maar misschien iemand die dit herkent? een bekend probleem bij iemand?
Als iemand dit herkent of nog een andere hoek weet waar ik kan zoeken voor een oplossing dan ben ik een en al oor.

De search leverder geen topics op jonger dan 2 weken, ik heb wel wat gezocht, en er was 1 topic wat semi-interresant leek, helaas had dit topic maar 1 reply en daar had ik niks aan

andere topics gingen eigenlijk net naast dit probleem af, en boden ook geen nieuwe informatie...

Iig bedankt voor het lezen en hopelijk kun je iets zinnigs zeggen over dit probleem, als er nog meer info nodig is dan zal ik deze ASAP posten.

alvast mijn dank!

[curry684]

offtopic:
Je post ook wel in 1 keer genoeg om die 3 jaar goed te maken

[Verwijderd]

Tsja, het is zo moeilijk te zeggen waar het aan ligt.
Het kan bijvoorbeeld zijn dat sommige ingevulde gegevens niet goed zijn, of juist ontbreken, terwijl ze wel 'required' zijn. (Dat staat dan in de eigenschappen van het betreffende veld in het tabelontwerp.)
Als je geen foutmeldingen krijgt bij het toevoegen komt dat waarschijnlijk omdat er bovenaan je code "On Error Resume Next" staat... Haal dat eens weg, dan zul je waarschijnlijk een foutmelding krijgen met info waarom het toevoegen niet goed gaat.
Succes!

[Warbringer]

Verwijderd schreef op 30 July 2003 @ 16:59:
Tsja, het is zo moeilijk te zeggen waar het aan ligt.
Het kan bijvoorbeeld zijn dat sommige ingevulde gegevens niet goed zijn, of juist ontbreken, terwijl ze wel 'required' zijn. (Dat staat dan in de eigenschappen van het betreffende veld in het tabelontwerp.)
Als je geen foutmeldingen krijgt bij het toevoegen komt dat waarschijnlijk omdat er bovenaan je code "On Error Resume Next" staat... Haal dat eens weg, dan zul je waarschijnlijk een foutmelding krijgen met info waarom het toevoegen niet goed gaat.
Succes!

Alle velden worden ingevuld, maar dan ook echt ALLE. dus een required field dat niet ingevuld is kan het niet zijn.

On error heb ik er niet boven staan. Ik heb de code niet laten genereren door access, zelf geklopt.

Ik maak wel gebruik van invoer maskers (bijv. postcode moet 4 cijfers en 2 letters zijn) maar dit is al meteen afgevangen bij het invullen van de textbox zelf.

ik heb de messagebox "sollicitant toegevoegd" nu helemaal onderaan gezet.
Dan weet ik in ieder geval dat als ik wel "zijn alle gegevens goed ingevuld?" krijg, en niet "Sollicitant toegevoegd" dat ergens tussenin de code stopt.

In totaal worden er 5 recordsets aangemaakt, en ook alle 5 ge-update en gesloten.

Ze worden alle 5 aangemaakt, en als ze alle 5 open zijn worden ze achtereenvolgens, 1 voor 1 gesloten.

offtopic:
Voor curry: Ik had de FAQ gelezen, en daar stond dat ik uitgebreid moest zijn

[ Voor 6% gewijzigd door Warbringer op 30-07-2003 19:06 ]

[farlane]

Gebruik gewoon een insert query. Dat werkt beter, want ADO heeft een hoop buffering etc ertussen zitten.

( En ook de events die aan een recordset hangen bij inserten / editen etc kloppen niet altijd )

[OZ-Gump]

Tipje: Zet in je procedure wel een On Error, maar bouw deze zo op dat de gebruiker een (leesbare!) melding op het scherm krijgt, met daarbij het verzoek het foutnummer en de melding door te geven aan de applicatiebeheerder (dat ben jij ).
Je zou dat als volgt aan kunnen pakken:

code:

Private Sub Opslaan_Click()
On Error GoTo ErrorHandler

If MsgBox("Zijn alle velden ingevoerd?", vbYesNo) = vbYes Then
  Dim Db As Database
  Dim rst, rst2, rst3, rst4 As Recordset
  Set Db = CurrentDb()
  Set rst = Db.OpenRecordset("sollicitanten", dbOpenDynaset)
  rst.AddNew
  rst!voorletters = voorletters.Value
  rst!Roepnaam = Roepnaam.Value
  rst!meisjesnaam = meisjesnaam.Value
  rst!achternaam = achternaam.Value
/*en zo verder dus*/
  rst.update
  msgbox("sollicitant toegevoegd")

ErrorHandler_Exit:
  rst.Close
  db.Close
  Set rst = Nothing
  Set db = Nothing
  Exit Sub

ErrorHandler
  MsgBox "Er is een fout opgetreden. Geef de volgende" & Chr(13) & _
         "info door aan de ApplicatieBeheerder: " & Chr(13) &  _
         "Foutcode: " & Err.Number & Chr(13) & _
         "Foutmelding: " & Err.Description
  Resume ErrorHandler_Exit

Je krijgt dan een nette melding met foutnummer en foutmelding. Die kun je opzoeken (op MSDN, in de help etc) en die kan je waarschijnlijk een stuk de goeie richting in helpen met het lokaliseren van het probleem.

[ Voor 5% gewijzigd door OZ-Gump op 30-07-2003 19:10 . Reden: layout f*cker ]

[Warbringer]

OZ-Gump schreef op 30 July 2003 @ 19:09:
..
some helpfull stuff
..

Thnx! ga ik morgen zeker proberen!

[Lister]

Wat er misschien ook nog fout kan gaan is dat men tekst in numerieke velden invult, bijvoorbeeld "42a" voor een numeriek huisnummer of zo.
En het kan ook fout gaan dat een ingevulde waarde te groot is voor het databaseveld, een uitzonderlijk lange naam of zo.

Met die foutafhandeling van OZ-Gump zou je daar wel achter moeten kunnen komen.

[JeroenE]

Warbringer schreef op 30 July 2003 @ 16:42:
Elke sollicitanten krijgt een ID waarmee deze te identificeren is en wat de verschillende records 1-op-1 koppelt.

Dit heeft verder niet zo veel met je probleem te maken, maar waarom heb je aparte tabellen gemaakt als je de gegevens toch 1-op-1 aan elkaar koppelt? Dan kan je het toch veel beter in 1 grote tabel laten staan? Dat scheelt weer zoeken in verschillende tabellen.

Als je nu een aparte tabel had gemaakt voor de "wil werken in locatie" gegevens dan had ik dat nog wel begrepen.

code:

If MsgBox("Zijn alle velden ingevoerd?", vbYesNo) = vbYes Then
msgbox("sollicitant toegevoegd")
  Dim Db As Database
  Dim rst, rst2, rst3, rst4 As Recordset
  Set Db = CurrentDb()
  Set rst = Db.OpenRecordset("sollicitanten", dbOpenDynaset)
  rst.AddNew
  rst!voorletters = voorletters.Value
  rst!Roepnaam = Roepnaam.Value
  rst!meisjesnaam = meisjesnaam.Value
  rst!achternaam = achternaam.Value
/*en zo verder dus*/
rst.update
rst.close
db.close

In een latere post schrijf je dat alle velden altijd ingevuld worden. Nu weet ik niet zeker of je dat ook echt zo bedoelde te schrijven, maar normaal gesproken hebben jongens geen 'meisjesnaam'. Ja, ik weet dat dat tegenwoordig wel mag en kan En als iemand nog geen relatie heeft dan is er sowieso maar sprake van 1 achternaam en geen gecombineerde. Dat lijkt mij dus al 1 veld (van de 4 die je laat zien) wat best wel eens leeg kan zijn.

Anyway, persoonlijk zou ik niet aan de gebruiker vragen of hij/zij alles wel goed heeft ingevuld. Tip: vertrouw nooit gebruikers!

Waarom controleer je niet zelf of men wel 'alle' velden heeft ingevuld?

code:

if achternaam.value = "" then msgbox('He ei, je moet wel een achternaam invullen!')

Nouja, iets in die richting dan
Je kan beter eerst alle foutmelding verzamelen en dan in 1 keer laten zien dan mensen 40 keer op OK te laten klikken, natuurlijk.

[Warbringer]

afgesproken is met de gebruikers dat in het geval dat alleen de meisjesnaam of achternaam ingevuld zou worden dat beide textboxen gevulde worden met dezelfde waarde.

Dus Mevrouw Janssen komt solliciteren, is niet getrouwd dus alleen een meisjesnaam.
Afgesproken is dus dat "janssen" OOK ingevuld wordt bij achternaam.

Het was niet mijn idee, maar de gruikers wouden het zo, was voor mij verder geen probleem.
Oh, en natuurlijk controleer ik zelf if blabla = null then msgbox('veld moet ingevuld worden') en alle required fields hebben een mooi kleurtje zodat ze goed opvallen.

Daar zit het probleem ook niet want als het record niet wil toevoegen en ik doe het opnieuw (of laat hun het opnieuw doen war ik bij sta) dan dan lukt het ineens wel.

En waarom ik niet 1 grote tabel had gemaakt..
Mainly, overzichtelijkheid.. Alle gegevens waren af te splitsen, en apart onder te verdelen in categorieën.

De persoonsgegevens, de locatiegegevens, de werktijden (en contract gegegvens), de functie gegevens, allemaal opgedeeld in tabellen.

Zo is het dus ook mogelijk om specifieke gegevens op te vragen zonder weer een tabel van 500+ records en 60+ fields aan te spreken, maar eentje van 500+ records en 15 fields.

Wat trouwens WEL apart is is volgens mij het volgende.

Aan de autonumber functie van accees kun je zien dat er "gaten vallen".
Dus zeg, er word een sollicitant toegevoegd, die krijgt ID 88 mee.
Dan gaat sollicitant 89 ineens de mist in, er wordt een aantal malen geprobeerd. werkt niet.
Ze gaan dan uit het scherm, terug het scherm in en vullen alles opnieuw in en dan lukt het toevoegen wel!

de volgende sollicitant heeft ineens ID 96 !!

now what? Hij maakt dus wel verbinding, reserveert een ID maar verder niets

[JeroenE]

Het was niet mijn idee, maar de gruikers wouden het zo, was voor mij verder geen probleem.

Ik weet niet wat voor invloed jij hebt op het ontwerp, maar ik vind het maar niks. Hoe kan jij nu weten wat voor naam je in je brief moet afdrukken? Wat als er op een gegeven moment een Mevrouw J. Jansen-Jansen komt solliciteren?

Oh, en natuurlijk controleer ik zelf if blabla = null then msgbox('veld moet ingevuld worden') en alle required fields hebben een mooi kleurtje zodat ze goed opvallen.

Da's mooi. Maar dan hoef je toch niet meer aan de gebruiker te vragen of alles is ingevuld?

En waarom ik niet 1 grote tabel had gemaakt..
Mainly, overzichtelijkheid.. Alle gegevens waren af te splitsen, en apart onder te verdelen in categorieën.

Ik kan me er wel iets bij voorstellen, maar ik blijf het toch een beetje vreemd vinden. Als je bepaalde gegevens 'bij elkaar' wil hebben kan je dat doen door de velden in de juiste 'volgorde' te zetten, lijkt mij.

Zo is het dus ook mogelijk om specifieke gegevens op te vragen zonder weer een tabel van 500+ records en 60+ fields aan te spreken, maar eentje van 500+ records en 15 fields.

Het enige wat ik me daarbij kan bedenken is dat je nu "seelct * from tabel3" kan gebruiken als je alleen de gegevens van tabel3 wil hebben; je hoeft dan niet de velden die je wil hebben apart op te noemen wat wel zou moeten als je alle velden in 1 grote tabel hebt zitten.

Maar ik vind iets als

code:

SELECT naam, functie FROM sollicitant WHERE salaris < 20000;

toch handiger dan

code:

SELECT naam, functie FROM tabel1, tabel4 WHERE tabel1.id = tabel4.id
                                           AND salaris < 20000;

Ik heb ook niet gezegd dat ik helemaal niets zou afsplitsen. Ik weet niet wat er allemaal precies bewaard moet worden en wat de bedoeling is. Van wat ik begrepen heb uit jouw verhaal zou ik in ieder geval een tabel Locaties hebben gemaakt en een koppeltabel om de locaties aan de sollicitanten te koppelen. Een voordeel hiervan is ook dat je makkelijk een locatie kan toevoegen zonder dat het database schema aangepast moet worden.

Maar als ze later een locatie extra krijgen kan jij wel geld vragen om het in te bouwen

Als er maar relatief weinig functies zijn die door meerdere mensen vervuld kunnen worden (lees: niet iedereen heeft een aparte functieomschrijving) zou ik daar ook een aparte tabel van maken. Dan voorkom je ook tikfouten als "adminstratief mewederker". De werktijden klinkt ook als een kandidaat, maar daarvan is mij niet veel van bekend.

Anyway, misschien heb je al iets gemaakt dat men functies uit een lijstje moet selecten in plaats van intikken; bovendien was het niet je bedoeling om je database ontwerp te laten bekijke, neem ik aan. Ik was gewoon benieuwd waarom je het zo had gedaan. Het blijft jouw databse natuurlijk dus als jij het zo handig vindt dan moet je het blijven gebruiken natuurlijk!

Aan de autonumber functie van accees kun je zien dat er "gaten vallen".
Dus zeg, er word een sollicitant toegevoegd, die krijgt ID 88 mee.
Dan gaat sollicitant 89 ineens de mist in, er wordt een aantal malen geprobeerd. werkt niet.
Ze gaan dan uit het scherm, terug het scherm in en vullen alles opnieuw in en dan lukt het toevoegen wel!

de volgende sollicitant heeft ineens ID 96 !!

now what? Hij maakt dus wel verbinding, reserveert een ID maar verder niets

Je probleem is toch dat de gegevens niet opgeslagen worden? Dan lijkt dit me juist zoals het hoort. Je wil toch hopelijk niet dat Access een uniek ID dubbel gaat uitgeven?
Als jij 5 keer iets opnieuw probeert op te slaan (wat niet lukt) dan is je ID dus 5 keer opgehoogd. Als het dan de 6e keer wel lukt heb je een 'gat'.

Waarschijnlijk gaat er toch ergens iets de mist in bij het opslaan; zoals al iemand eerder aangaf, probeer eens wat meer errors te voor schijn te halen.
Of zet hier en daar wat debug messages; ik weet niet of het haalbaar is met je gebruikers maar nu werkt het toch ook niet handig. Doe eens na iedere record een message: "Persoonsgegevens opgeslagen!", "Locaties opgeslagen!", "Functiegegevens opgeslagen" enzo. Als dat niet handig is kan je natuurlijk ook een (lokaal) logfiletje maken. Daarin zet je de gegevens die je wil gaan opslaan en meldingen per record of het gelukt is.

Het is al weer lang geleden dat ik iets met Access moest doen, maar er staat me bij dat je ook forms had die "automatisch" nieuwe records opsloegen, zonder dat je dat expliciet moest opgeven. Als je maar van het record af ging (met die blader knopjes) dan wilde Access het gelijk opslaan. Ik neem aan dat je niet zo iets hebt gebruikt?

[Warbringer]

jeroene schreef op 31 juli 2003 @ 10:16:
[...]
Ik weet niet wat voor invloed jij hebt op het ontwerp, maar ik vind het maar niks. Hoe kan jij nu weten wat voor naam je in je brief moet afdrukken? Wat als er op een gegeven moment een Mevrouw J. Jansen-Jansen komt solliciteren?

Eerlijk gezegd is het niet mijn probleem. Ik heb aangeboden om ze gewoon 1 waarde in te laten vullen. Desnoods te checken of meisjesnaam <> achternaam, of wat dan ook. Maar de gebruikers wouden in een dergelijk geval gewoon 2 keer hetzelfde invullen. Ik vond het ook raar en heb ze uitgelegd wat de consequenties waren maar uiteindelijk is de klant koning. Als ze het later toch anders willen kost ze dan gewoon weer poen

[...]
Da's mooi. Maar dan hoef je toch niet meer aan de gebruiker te vragen of alles is ingevuld?

Ik wil dat ze zich bewust zijn van de keuzes die ze maken. Het gemiddeld niveau van de gebruikers daar qua computer is niet bijster hoog. Een van de gebruikers noemt zijn PC nog steeds een "duivels-apparaat". Nuff said


[...]
Ik kan me er wel iets bij voorstellen, maar ik blijf het toch een beetje vreemd vinden. Als je bepaalde gegevens 'bij elkaar' wil hebben kan je dat doen door de velden in de juiste 'volgorde' te zetten, lijkt mij.

Het is vaak dat ik alleen locaties nodig heb, of werktijden, of net wat dan ook. 1 hele grote database is in een dergelijk opzich "trager" dan een die per tabel gegevens afgesplitst heeft (zo niet, dan moet ik dadelijk als de Fontys weer begint een hartig woordje spreken met mijn oude leraar DBS)

[...]
Het enige wat ik me daarbij kan bedenken is dat je nu "select * from tabel3" kan gebruiken als je alleen de gegevens van tabel3 wil hebben; je hoeft dan niet de velden die je wil hebben apart op te noemen wat wel zou moeten als je alle velden in 1 grote tabel hebt zitten.

Maar ik vind iets als

code:

SELECT naam, functie FROM sollicitant WHERE salaris < 20000;

toch handiger dan

code:

SELECT naam, functie FROM tabel1, tabel4 WHERE tabel1.id = tabel4.id
                                           AND salaris < 20000;

Ik heb ook niet gezegd dat ik helemaal niets zou afsplitsen. Ik weet niet wat er allemaal precies bewaard moet worden en wat de bedoeling is. Van wat ik begrepen heb uit jouw verhaal zou ik in ieder geval een tabel Locaties hebben gemaakt en een koppeltabel om de locaties aan de sollicitanten te koppelen. Een voordeel hiervan is ook dat je makkelijk een locatie kan toevoegen zonder dat het database schema aangepast moet worden.

Take it from me, in dit geval zou je de aparte gegvens gewoon willen splitsen. Maar het opvragen van gegevens is het probleem niet, maar het opslaan juist

Maar als ze later een locatie extra krijgen kan jij wel geld vragen om het in te bouwen

Exactly en nieuwe locaties komen er zeker..

Als er maar relatief weinig functies zijn die door meerdere mensen vervuld kunnen worden (lees: niet iedereen heeft een aparte functieomschrijving) zou ik daar ook een aparte tabel van maken. Dan voorkom je ook tikfouten als "adminstratief mewederker". De werktijden klinkt ook als een kandidaat, maar daarvan is mij niet veel van bekend.

Functies zijn inderdaad selecteerbaar, werktijden niet. dat werkt anders dan dat je je inbeeld. het gaat hier om begintijden, en eindtijden, dagen die gewerkt worden, eventuele avond/weekend diensten en minimale/maximale uren. Alle is zo dichtgemetseld dat er geen foute invoer mogelijk is. Dit is echt dummyproof gemaakt

Anyway, misschien heb je al iets gemaakt dat men functies uit een lijstje moet selecten in plaats van intikken; bovendien was het niet je bedoeling om je database ontwerp te laten bekijke, neem ik aan. Ik was gewoon benieuwd waarom je het zo had gedaan. Het blijft jouw databse natuurlijk dus als jij het zo handig vindt dan moet je het blijven gebruiken natuurlijk!

Idd, de database is genormaliseerd dus het zou werkbaar moeten zijn en dat is het op zich ook gewoon

[...]
Je probleem is toch dat de gegevens niet opgeslagen worden? Dan lijkt dit me juist zoals het hoort. Je wil toch hopelijk niet dat Access een uniek ID dubbel gaat uitgeven?

Tuurlijk moet Access geen dubbele ID's uitgeven. Maar het feit dat er een gat ontstaat wil wel zeggen dat access probeert de gegevens op te slaan maar niet lukt oid en dat de autonumber toch 1 opwaardeerd. de vraag WAAROM worden die gegevens niet opgeslagen is de vraag hier...

Als jij 5 keer iets opnieuw probeert op te slaan (wat niet lukt) dan is je ID dus 5 keer opgehoogd. Als het dan de 6e keer wel lukt heb je een 'gat'.

De Xe keer (X = any number) lukt het pas als je uit het scherm gaat, en er weer terug in gaat (dus niet uit het programma, maar alleen het invoer verscherm verlaten, terug naar hoofdscherm en dan weer naar invoerscherm)

Waarschijnlijk gaat er toch ergens iets de mist in bij het opslaan; zoals al iemand eerder aangaf, probeer eens wat meer errors te voor schijn te halen.
Of zet hier en daar wat debug messages; ik weet niet of het haalbaar is met je gebruikers maar nu werkt het toch ook niet handig. Doe eens na iedere record een message: "Persoonsgegevens opgeslagen!", "Locaties opgeslagen!", "Functiegegevens opgeslagen" enzo. Als dat niet handig is kan je natuurlijk ook een (lokaal) logfiletje maken. Daarin zet je de gegevens die je wil gaan opslaan en meldingen per record of het gelukt is.

Dit ga ik inderdaad testen

Het is al weer lang geleden dat ik iets met Access moest doen, maar er staat me bij dat je ook forms had die "automatisch" nieuwe records opsloegen, zonder dat je dat expliciet moest opgeven. Als je maar van het record af ging (met die blader knopjes) dan wilde Access het gelijk opslaan. Ik neem aan dat je niet zo iets hebt gebruikt?

Nee, dat was het eerste wat ik uit gezet had. Die record zoekers etc wil ik echt niet hebben. Ik laat niks over aan access. De enige reden dat het in access gebeurd is omdat dat een vereiste was (geen oracle server daar oid)

mocht je nog vragen hebben dan hoor ik het wel

[JeroenE]

De volgende keer kan je beter de quote aflsuiten en opnieuw openen ipv met bold jouw antwoord aan te geven. Nu kan ik alles erin gaan knippen en plakken...


Als het niveau niet super hoog is dan probeert men vaak de traditionele werkwijze te imiteren op de computer. Of dat handig is is natuurlijk een tweede. Ik ben wel eens bij een bedrijf geweest waar overal supersnelle desktops stonden die met glasvezel (!) aan elkaar waren verbonden. En wat draaide ze? Een database pakketje van 30 jaar oud wat dus nog een echte namaak-kaartenbak was waar je in kon bladeren. Zelfs datgane wat ooit in mijn MSX zat (Sony HitBit, met ingebakken MicroSoft programma's) was nog geavanceerder... Gelukkig hoefde ik me niet met de IT te bemoeien

Als de opdrachtgever iets per se wil en ze willen niet luisteren naar argumenten om het niet te doen, dan kan ik me wel voorstellen dat je het toch zo doet

Het is vaak dat ik alleen locaties nodig heb, of werktijden, of net wat dan ook. 1 hele grote database is in een dergelijk opzich "trager" dan een die per tabel gegevens afgesplitst heeft (zo niet, dan moet ik dadelijk als de Fontys weer begint een hartig woordje spreken met mijn oude leraar DBS)

Hm, ik ben niet goed genoeg bekend met Access om daar een uitspraak over te doen, maar het lijkt me wel vreemd. Ik snap best dat "select * from tabelmetveelvelden;" zorgt voor onnodig dataverkeer als je maar twee velden wil laten zien. Maar dan moet je gewoon beter selecteren. Ik zie zo snel niet in waarom "select naam from tabelmetweinigvelden;" sneller zou gaan dan "select naam from tabelmetveelvelden;".

En als je gesplitst hebt moet je in het algemeen juist meer queries doen. Een combinatie van naam en functie laten zien zijn in jouw geval al twee queries.

Misschien te ver doorgetrokken, maar volgens de redenatie van je leraar is het dus het beste om alle velden in een apate tabel te stoppen. Stel je voor, een tabel met maar twee velden, dat moet wel zes keer zo snel zijn als een tabel met twaalf velden!

Idd, de database is genormaliseerd dus het zou werkbaar moeten zijn en dat is het op zich ook gewoon

nofi, maar daar geloof ik dus niets van. Volgens welke normalisatie regel moet je gegevens met een 1-op-1 relatie in aparte tabellen stoppen?
Voor iedere locatie een veld ipv een tabel met locaties druist ook tegen heel wat regels in. Jajaja, ik weet waarom het zo is, maar daar wordt je database niet genormaliseerd van.

Dit ga ik inderdaad testen

Mooi, dan horen we wel als je wat hebt ontdekt

Nee, dat was het eerste wat ik uit gezet had. Die record zoekers etc wil ik echt niet hebben. Ik laat niks over aan access. De enige reden dat het in access gebeurd is omdat dat een vereiste was (geen oracle server daar oid)

Er is meer in het leven dan Access en Oracle

Je hebt ook geen "private sub form_beforeupdate()" of zulk soort dingen gebruikt waar wellicht e.e.a. niet goed gaat bij het openen/afsluiten van een recordset?

Trouwens, ik neem aan dat je het autoincrement veld maar in 1 tabel zit en dat je de waarde overneemt in je andere tabellen (dus geen autoincrement in tabel2 etc). Je hebt ook geen validaties van de ene tabel op de andere enzo?

[Warbringer]

De volgende keer kan je beter de quote aflsuiten en opnieuw openen ipv met bold jouw antwoord aan te geven. Nu kan ik alles erin gaan knippen en plakken...

Ok, here we go then

Als het niveau niet super hoog is dan probeert men vaak de traditionele werkwijze te imiteren op de computer. Of dat handig is is natuurlijk een tweede. Ik ben wel eens bij een bedrijf geweest waar overal supersnelle desktops stonden die met glasvezel (!) aan elkaar waren verbonden. En wat draaide ze? Een database pakketje van 30 jaar oud wat dus nog een echte namaak-kaartenbak was waar je in kon bladeren. Zelfs datgane wat ooit in mijn MSX zat (Sony HitBit, met ingebakken MicroSoft programma's) was nog geavanceerder... Gelukkig hoefde ik me niet met de IT te bemoeien


Als de opdrachtgever iets per se wil en ze willen niet luisteren naar argumenten om het niet te doen, dan kan ik me wel voorstellen dat je het toch zo doet

Ik heb geprobeerd ze te overtuigen maar ze wilde het gewoon zo hebben.
Tja, waar blijf je dan met je argumenten? Maar ze komen er wel op terug.. don't worry..

Hm, ik ben niet goed genoeg bekend met Access om daar een uitspraak over te doen, maar het lijkt me wel vreemd. Ik snap best dat "select * from tabelmetveelvelden;" zorgt voor onnodig dataverkeer als je maar twee velden wil laten zien. Maar dan moet je gewoon beter selecteren. Ik zie zo snel niet in waarom "select naam from tabelmetweinigvelden;" sneller zou gaan dan "select naam from tabelmetveelvelden;".

Die beredenering volg ik ook.

En als je gesplitst hebt moet je in het algemeen juist meer queries doen. Een combinatie van naam en functie laten zien zijn in jouw geval al twee queries.

Inderdaad, maar in dit geval is 2 "kleine" queries tegenover 1 "grote" query een klein probleem. Het gaat om relatief weinig gegevens die binnengehaald worden (het zijn geen honderden attributes oid), dus de druk op het netwerk valt wel mee.
(ik ben tegelijkertijd systeem & netwerk beheerder bij hetzelfde bedrijf als waar deze applicatie voor is)

daarintegen het feit dat het gewoon overzichtelijk blijft omdat alles een beetje gescheiden en "opgeruimd" staat.

Even voor de duidelijkheid, er zijn 3 tabellen die dus een 1-op-1 relatie hebben met elkaar, de rest van de tabellen onderling zijn 1-op-veel relaties. Denk nu niet dat het samen te voegen was op 1 grote hoop omdat toch alles 1-op-1 is.
Er zitten ook tabellen bij die wel 1-op-veel zijn, een paar tabellen zouden inderdaad samen te voegen zijn maar omdat deze gegevens in een soort van aparte categorie vallen hebben ik ervoor gekozen om ze apart op te slaan (in ruil voor wat performance dus). Andere tabellen zijn dus gedwongen afgescheiden omdat het dus 1-op-veel is en omdat het afsplitsbare en repeterende gegevens zijn.

Misschien te ver doorgetrokken, maar volgens de redenatie van je leraar is het dus het beste om alle velden in een apate tabel te stoppen. Stel je voor, een tabel met maar twee velden, dat moet wel zes keer zo snel zijn als een tabel met twaalf velden!

Nee tuurlijk niet dat is inderdaad te ver doorgetrokken.
Maar zoals je zelf al aangaf is een select op een tabel van 20 velden sneller dan op een van 60 velden (niet heel veel, maar een beetje dan ). Om voor elke waarde een aparte tabel te maken zou een beetje het principe van een database verslaan.

But could we drop the database analyse, ik zit nog steeds met een probleem waarom dat ding die gegevens niet op wil slaan

nofi, maar daar geloof ik dus niets van. Volgens welke normalisatie regel moet je gegevens met een 1-op-1 relatie in aparte tabellen stoppen?
Voor iedere locatie een veld ipv een tabel met locaties druist ook tegen heel wat regels in. Jajaja, ik weet waarom het zo is, maar daar wordt je database niet genormaliseerd van.

de 1-op-1 relaties zijn inderdaad niet nodig omdat het ook in 1 tabel kan, ik heb dit voor lief genomen om alles een beetje gesorteerd te houden.
Andere tabellen (die voor dit hele verhaal niet van toepassing zijn) zijn wel genormaliseerd volgens de BCNV zoals ik die geleerd heb.

Mooi, dan horen we wel als je wat hebt ontdekt

Morgen een uitgebreid verslag

Er is meer in het leven dan Access en Oracle

Ik noem maar even wat joh

Je hebt ook geen "private sub form_beforeupdate()" of zulk soort dingen gebruikt waar wellicht e.e.a. niet goed gaat bij het openen/afsluiten van een recordset?

simpel antwoord : nope

Trouwens, ik neem aan dat je het autoincrement veld maar in 1 tabel zit en dat je de waarde overneemt in je andere tabellen (dus geen autoincrement in tabel2 etc). Je hebt ook geen validaties van de ene tabel op de andere enzo?

De enige autonumber die erin staat is dus deze. De rest van de ID waardes worden overgenomen van die autonumber.

Nergens, in geen enkele andere tabel komt een autonumber voor behalve bij deze ene tabel dus.

ps. is de layout so beter?

[Warbringer]

Waarschijnlijk is het probleem gevonden.
Het zat hem in de lengte van somme tabelvelden en de lengte van textboxen.

max length voor de voorletters was gecapped op 7 maar in het textveld niet, en als er 8 tekens ingevuld werden en ze probeerde dan de record toe te voegen dan lukte dit niet.

Ik heb sommige max lengths aangepast, en sommige caps op de textboxes gezet en tot zover geen klachten gehad.

iedereen bedankt voor de geleverde ideeën !

[farlane]

Warbringer schreef op 02 August 2003 @ 10:45:
Het zat hem in de lengte van somme tabelvelden en de lengte van textboxen.

Daar had je dus echt wel een foutmelding op moeten krijgen.

Is het niet zo dat je misschien in de callstack naar de functie waarin de fout optrad een On Error Goto / Resume Next had staan?

Het is namelijk zo dat een exception altijd moet worden opgevangen, of je krijgt een runtime error. Als jij die runtime error niet krijgt, moet er bijna wel ergens een exception handler staan.

[Warbringer]

farlane schreef op 02 August 2003 @ 11:35:
[...]


Daar had je dus echt wel een foutmelding op moeten krijgen.

Is het niet zo dat je misschien in de callstack naar de functie waarin de fout optrad een On Error Goto / Resume Next had staan?

Het is namelijk zo dat een exception altijd moet worden opgevangen, of je krijgt een runtime error. Als jij die runtime error niet krijgt, moet er bijna wel ergens een exception handler staan.

wat stom was van mezelf was, dat ik in de client versie zat te werken en de meeste access foutmelding onderdrukt had.

Nu ik die errorhandler gebruikte kwam de foutmelding wel boven water.