records niet geschrapt

Status
Niet open voor verdere reacties.

JEPEDEWE

Terugkerende gebruiker
Lid geworden
14 jun 2006
Berichten
1.680
Bij het doorlopen van volgende code

DoCmd.RunSQL "DELETE DATA.*, DATA.KODE FROM data WHERE DATA.KODE = '" & [Forms]![weergave patiënt]![Kode] & "';"
DoCmd.RunSQL "DELETE VOORSCHR.*, VOORSCHR.KODE FROM VOORSCHR WHERE VOORSCHR.KODE ='" & [Forms]![weergave patiënt]![Kode] & "';"
DoCmd.RunSQL "DELETE VERZEK.*, VERZEK.KODE FROM VERZEK WHERE VERZEK.KODE ='" & [Forms]![weergave patiënt]![Kode] & "';"
DoCmd.RunSQL "DELETE FICHE.*, FICHE.KODE FROM FICHE WHERE FICHE.KODE ='" & [Forms]![weergave patiënt]![Kode] & "';"

krijg ik volgende foutmelding

fout.jpg

geennekel record werd gewist

Wat doe ik fout
Ik ben standalone user dus... koppelvergrendeling?????

Bedankt
JP
 
Bij het verwijderen is het belangrijk dat je de te verwijderen records ook daadwerkelijk mág verwijderen. Je mag doorgaans bijvoorbeeld géén patiënt verwijderen uit je Klantentabel als er nog behandelingen van die patiënt in de tabel Behandelingen staan. Dan zou je behandelingen in je tabel hebben waar geen patiënt aan hangt. Moet je niet willen doorgaans :). Er zijn twee mogelijke werkwijzen:
1. Verwijder de gegevens van de persoon uit alle betrokken tabellen handmatig
2. Geef in de Relaties aan dat gerelateerde records moeten worden verwijderd.

De tweede werkwijze is het makkelijkst, en doorgaans ook het consequents, want je kunt niet vergeten om onderliggende tabellen te verwijderen. De eerste werkwijze (die jij dus zo te zien toepast) werkt in beginsel óók prima, maar vereist dat je de records in de juiste volgorde verwijdert. En dat betekent: van onderen naar boven. Dus eerst de records in BehandelDagen en Factuurregels, dan de records in Behandelingen en Facturen, en dan pas in Patiënten. En heb je nog meer niveau's, dan moet je uiteraard nog lager beginnen. Nou kan ik me voorstellen dat het vanuit juridisch/belastingtechnisch oogpunt niet is toegestaan om facturen etc. te verwijderen, omdat je daarmee je bedrijfsadministratie overhoop haalt. Haal je inkomsten weg uit de db, dan verander je natuurlijk wel het e.e.a.
Maar gesteld dat je alles netjes hebt gearchiveerd, dan zou dat dus op deze manier moeten kunnen.

Wat ik bij jou constateer, is dat je de records allemaal tegelijk afvuurt. En daar zou wel eens een probleem door kunnen komen. Als je iets in een hoger gelegen tabel probeert te verwijderen, terwijl de onderliggende tabel nog data bevat, ja, dan krijg je dus een probleem. Al is je plaatje niet bepaald verhelderend, want ik zie niet bij welke tabel het nu fout gaat.
Ik zou dus ofwel het opschonen onder verschillende knoppen hangen (met een check voordat je de volgende query uitvoert of alles wel is verwijderd) ofwel die check inbouwen in je huidige routine. Daarnaast zou ik de volgorde veranderen, als ik het datamodel van een oudere db nog mag geloven (Data staat daar niet in gekoppeld).

Code:
	With CurrentDB
        .Execute "DELETE * FROM VERZEK WHERE KODE = """ & Me.Kode & """", dbFailOnError
        .Execute "DELETE * FROM VOORSCHR WHERE KODE = """ & Me.Kode & """", dbFailOnError
        .Execute "DELETE * FROM DATA WHERE KODE = """ & Me.Kode & """", dbFailOnError
        .Execute "DELETE * FROM FICHE WHERE KODE = """ & Me.Kode & """", dbFailOnError
	End With
Maar als je in de relatie FICHE --> VOORSCHR de optie <Gerelateerde records trapsgewijs verwijderen> aan zet, en tussen VOORSCHR --> VERZEK óók (alleen de eerste werkt natuurlijk niet, omdat je dan met VERZEK records blijft zitten), dan hoef je alleen de records in FICHE te verwijderen, om daarmee tegelijkertijd dus óók VOORSCH en VERZEK op te schonen.
 
Vind dat allemaal wat ingewikkeld en ook wel raar omdat in geenenkele “delete-lijn” een link tussen tabellen gebruikt wordt...
ik oorsprong waren deze commandos in een query gestoken, zou dat beter zijn? Dacht op die manier het project wat uit te dunnen
 
Je gebruikt queries, alleen stuur je ze vanuit een SQL opdracht aan. Maar elke query die je met de hand maakt, ziet er hetzelfde uit als je de SQL code bekijkt :). De variant die jij gebruikt lijkt ook rechtstreeks gekopieerd te zijn uit het SQL venster van de query. Overigens is dit stuk (DELETE DATA.*, DATA.KODE FROM data) dus niet juist, omdat je met * al alle velden verwijderd. Het heeft dus geen zin om ook nog het veld DATA.KODE apart te verwijderen. Daarom heb ik alleen het asteriksje laten staan. En ik vuur verwijderqueries liever uit vanuit de db met Execute, omdat je de followup beter in de hand hebt (dbFailOnError vind ik altijd wel fijn om te gebruiken).

Maar nogmaals: bij jou is de volgorde denk ik de drempel waarover het struikelt. En wat betreft de links: die zitten niet in de queries, die maak je in je relaties. En het verwijderen wordt dan simpeler, niet ingewikkelder :). De query DELETE * FROM FICHE verwijdert dan óók de gerelateerde records in VERZEK en VOORSCHR, dus dat scheelt twee queries. En één query draaien is, ook in België lijkt mij, simpeler dan drie queries :D. Bovendien ben je dan van het probleem af dat de queries elkaar in de weg zitten.
 
Als ik de foutboodschap bekijk dan zie ik dat er 0 records niet kunnen verwijderd worden vanwege sleutelconflicten, dus volgens mij is hier geen sprake van gerelateerde records (ik gebruik nooit Nederlandstalige software, dus Nederlandse foutmeldingen zijn een beetje onwennig voor mij) die het verwijderen tegenhouden. Blijft het vergrendelingsconflict, dit is meestal het gevolg van het feit dat de gegevens ergens op dat moment gebruikt worden in een formulier, tabel of query die openstaat. Dus check even welke objecten er openstaan op het moment van de verwijdering en welke gegevenslijnen actief zijn.
 
Een vergrendelingsconflict heb je alleen als het record in de bewerkingsmodus staat, en dat is gauw genoeg gecheckt.
 
Dank beide voor de uitleg
Het rare is:
Ik laat het project (met mijn code) lopen op een andere PC en alles verloopt perfect...
Ik heb alles veranderd naar de code van Michel en dat werkt ook perfect dus hanteer ik die code natuurlijk
Vraagje echter:
Waartoe dient "dbFailOnError"
Ik zocht het op en ik las iets van het optimaliseren van je database als er iets fout gaat, maar, ALS er iets fout gaat wordt de record dan toch geschrapt of hoe zit dat met de werking van dit "commando"
Gr
JP
 
dbFailOnError zorgt ervoor dat je query doorloopt. Normaal gesproken stopt de uitvoer als er een fout in een record wordt gevonden, maar nu loopt de query dus wél door.
 
maar weet je dus niet of de query goed gelopen is of niet?
JP
 
Dat weet je wel, want hij loopt dan goed :). Hooguit heb je records die niet zijn verwijderd. Maar dat komt dan doordat het record niet verwijderd kán worden.
 
beste allebei
Ik probeer de code op mijn reguliere PC
bij de lijn:
.Execute "DELETE * FROM FICHE WHERE KODE = """ & Me.Kode & """", dbFailOnError
krijg ik weer de foutmelding 3218
"vergrendeld" Bijwerken is onmogelijk

Als ik de tabel open dan kan ik het betreffende record kiezen en via del, gewoon schrappen zonder enige foutmelding

Op een andere PC werkte alles naar behoren..

Graag jullie licht
JP
 
Laatst bewerkt:
Krijg je deze melding één keer, soms, of altijd? Doe je altijd hetzelfde? En geldt dat ook voor de andere pc? Draait op de andere pc een kopie van de db? Ik neem aan dat beide pc's gebruik maken van dezelfde backend; in dat geval: staat de db op eide pc's wellicht open als je op pc A de actie uitvoert? En andersom als je op pc B werkt?

Je zou eens een apart niet-afhankelijk formuliertje kunnen maken waarin je de Kode selecteert met een keuzelijst, en vervolgens de queries kunnen uitvoeren met een clickactie op die keuzelijst. Als je verder niets open hebt staan als je dat nieuwe formulier gebruikt, zou de code echt moeten werken.
 
Check ook eens de lock settings in je formulier: formuliereigenschappen -> tabblad Data -> record locks. Opties zijn: no locks - edited record - all records. Als deze eigenschap op all records staat zou dat het probleem kunnen veroorzaken.
 
Aanvulling hierop: de setting <Bewerkte record> is de meest handige instelling, zeker in een db die door meerdere personen op verschillende pc's tegelijk gebruikt wordt. Je zou hem tijdelijk even op <Geen vergrendelingen> kunnen zetten om te kijken of dat verschil maakt. Bij een nieuw, niet-afhankelijk formulier dit die eigenschap op een formulier uiteraard helemaal niks :). In dat geval kun je de eigenschappen bij de Opties instellen. Dan heb je ook de in dit bericht gebruikte benamingen, (<Opties>, <Clientinstellingen>, groep <Geavanceerd>, <Standaardrecordvergrendeling>).
 
eigenschappen van het formulier stond op "Bewerkte record"
veranderd naar "Geen"
OPGELOST

hoe zot is dat???

Bedankt
JP
 
Niet zo zot als je beseft dat een database (elke database Oracle, MariaDB, MySQL, … en ook Access) nooit één record lockt, alhoewel sommige instellingen het zo verwoorden. De kleinste lock is een page (8 Kb). Hoeveel records een page kan bevatten hangt af van de grootte van de records. Dus als de optie "Bewerte record' wordt gekozen dan worden alle records op deze page gelocked.
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan