Corrupt record ontstaan/verwijdering

Status
Niet open voor verdere reacties.
R

RadboudAKF

Gebruiker
Lid geworden
3 nov 2010
Berichten
219
Goedemorgen.

Wellicht heeft iemand wel eens met dit bijltje gehakt en weet een oplossing.

Ik werk in het UMC St Radboud Nijmegen (Apotheek). We hebben daar (onder meer) een tweetal tabellen die in een "nachtprocedure" worden gesynchroniseerd. Als er in de tabel [Lisa_Artikel] een nieuw record is ontstaan dan wordt dat record ook toegevoegd aan de tabel [LisaPlus].

Nu zit er 'ineens' een corrupt record in de tabel [LisaPlus]. Ik heb tot nu geen idee hoe record is ontstaan. Bovendien kan ik met een querie dit record ook niet vinden (moet ik dan zoeken op "?". Ook als ik laat zoeken op 6* (alle artikelnummers beginnen met een 6) dan wordt ook het corrupte record gevonden terwijl dat toch echt begint met dit [hokje met vraagteken].

Omdat ik niet begrijp hoe dit ontstaat ('s nachts loopt er een toevoegquerie die records toevoegt aan [lisaplus]) en omdat ik niet weet hoe ik die corrupte records makkelijk kan traceren of anderszins kan oplossen heb ik ten einde raad de vraag hier voorgelegd.

Heeft iemand een idee hoe dit kan ontstaan en hoe ik de records zou kunnen herkennen middels een query of anderszins?

Het artikelnummer ziet er nu zo uit: 䃤600230, terwijl het 6002300 moet zijn. Ik zou graag de mdb meesturen maar ik zie dat ik maar 100kb mag uploaden?
(In het "䃤" (hokje) staat een vraagteken!!)

Voorbaat dank,
Jan Stegeman
 
Zijn de overige velden wel te bekijken en te bewerken van dat record? Want dat duidt er meestal op dat het record an sich niet corrupt is. Andere vraag: is het artikelnummer een tekstveld, of een numeriek veld? Je vult het n.a.v. een andere tabel, dus het zal vermoedelijk geen Autonummerveld zijn. Kun je de inhoud van het veld bekijken als je het Zoomvenster opent?
 
Hallo Michel,

Dank voor je antwoord.

Alle gegevens in dit record zijn te raadplegen/benaderen/muteren. Dus het record zal dan inderdaad niet 'corrupt' zijn. Wel het veld [artikelnummer] dat overigens een tekstveld is en maximaal 8 lang is. (Er zijn een paar artikelnummers waar een "Letter" inzit, vandaar dat het niet numeriek kan zijn. Dit is het sleutelveld... Heel vreemd is ook dat ik dit record niet kan vinden als ik een querie draai met beide tabellen (laat zien welk record in de ene tabel zit en niet in de andere).

Als je wilt dan zou ik beide tabellen in een uitgeklede MDB (of accdb) kunnen mailen.

Weet even niet wat je bedoelt met Zoomvenster...
 
Nog een opmerking over bovenstaand probleem. Ik zei dat alle velden te benaderen/muteren/raadplegen zijn. Dat is wel zo op één veld na...datumveld...ontstaat als er een nieuw record ontstaat. Default =Date() Als ik daar nu kijk dan staat daar 30-12-1899 (!!) en dat is NIET te wijzigen. (op een normale manier)

LisaPlus.JPG
 
In je standaardwaarde staat niet de formule Date(), maar Date$(). Ik zou dat dus in ieder geval aanpassen. Het zoomvenster kun je openen door in een veld te gaan staan, en op <Shift>+<F2> te drukken. Ik vraag me af of je de waarde dan wel kunt zien/muteren.
Mocht je de db willen mailen: octafish @ live.nl. Als het een 2003 of oudere db is, kan ik er overdag naar kijken, anders wordt het vanavond.
 
Ik zal de database even sturen (8mb geen bezwaar?) Ik kan geen mdb's mailen...heb even ge-renamed naar .ABC (dus weer renamen naar mdb).

Je ziet een tweetal tabellen waarbij record 6002300 dus fout gaat, evenals het datumveld (dat denkt dat het 1899 is). In een nachtprocedure (macro) draai ik een toevoegquery (SQL-statement) dat records die nog niet in LisaPlus zitten en wel in Lisa_Artikel worden toegevoegd. (waarna men deze tabel kan verrijken met info) Daar lijkt het fout te gaan.

Ik denk niet dat je zou kunnen zien waar het mis gaat, maar misschien krijg je een idee bij het zien van de tabellen. (de inhoud heb ik enigszins moeten wijzigen, want daar staat bedrijfsgevoelige info in)

Voorbaat dank.
 
Ik kon het record inderdaad prima vinden, en aanpassen overigens ook. Zoals ik al zei, met <Shift>+<F2> naar het zoomvenster, en dan het nummer overnieuw intypen. Omdat de macro en/of query er niet bijzit, kan ik verder niet zoveel zeggen over de procedure.
 
Kennelijk gebeurt er iets merkwaardigs in de nachtprocedure (als de nieuwe records worden toegevoegd). Dank dat je er even naar hebt willen kijken. Ik ga verder op zoek naar het WAAROM van dit merkwaardige record. Dit gebeurt nu al voor de derde achtereenvolgende dag.

In ieder geval dank dat je er naar hebt willen kijken.
 
Stuur anders de procedure ook nog een keer op, dan wil ik er wel naar kijken.
 
Michel,

Zeer bedankt. Die procedure voert wellicht wat te ver. Deze tabellen worden op twee afzonderlijke plaatsen in ons netwerk beheerd en in de nachtprocedure 'draait' er dan een toevoegquery die beide tabellen weer één op één laat lopen. Kennelijk gaat daar iets mis.

Gisteren heb ik de procedure een klein beetje aangepast. Voordat de diverse macro's hun werk gaan doen laat ik eerst de database(s) comprimeren...waarna ik vanochtend constateerde dat er geen "merkwaardige" artikelnummers meer ontstaan waren. Nooit een slechte raadgever die compressie, of dat ook de oplossing is moet nog blijken.
 
Merkwaardig record is er weer!!

Nadat ik een aantal weken verschoond bleef van dit probleem is het record er "ineens" weer.

Ziet er nu zo uit: 䃤600232 (daar waar je een blokje ziet staat bij mij een vraagteken in een blokje)

Iemand een idee?

Ik heb met een invoermasker cq validatieregel voor dit veld geprobeerd deze records te voorkomen maar daar trekt dit "teken" zich niets van aan. Dit record heeft ook een datum-veld en daar staat ook weer 30-12-1899 ipv huidige datum.

Wordt hier een beetje moedeloos van.

Jan
 
Het is zo te zien een ander record dan de vorige keer. Een invoermasker en/of standaardwaarde heeft in jouw geval niet zoveel zin, want dat werkt alleen als je zelf nieuwe records aanmaakt. En dat doe je niet met een import. Zonder de procedure kan ik er verder helaas weinig van zeggen...
 
Hallo Michel,

Dank voor je reactie.

Ik ga mij eens bezinnen op de hele procedure: Die komt er op neer dat deze tabel dezelfde [artikelnummers] bevat als een andere tabel [Artikelen] .

Als er in de laatste tabel een nieuw record (nieuw artikelnummer) is ontstaan dan wordt die ook toegevoegd aan de andere tabel (één op één) Ik doe dat in een nachtprocedure met een "toevoegquery" ("voeg toe dat nog niet bekend is in de 'andere' tabel)

Dat lijkt allemaal goed te gaan...maar als ik 's morgens de tabel controleer is daar toch een extra record ontstaan (met dat 'corrupte' teken).

Zou ik een dergelijk record kunnen voorkomen door een één op één relatie te definieren in de database? (ipv een 'toevoegquery" te laten uitvoeren?)

Jan
 
Nog een opmerking:

Omdat ik merk dat (op welk moment dit record ook ontstaat) in het datumveld, dat is gedefiniëerd op DATE() , steeds de datum 30-12-1899 wordt ingevuld.
Ik ga in ieder geval een verwijderquery maken dat alle records jonger dan [01-01-1900] verwijdert in twee stappen. (eerst een toevoegquery aan een corrupt records tabel' en dan een verwijder-query)

Jan
 
Die datum krijg je omdat er in het datumveld een 0 wordt genoteerd. En dat is ook een datum: 30-12-1899 namelijk. Of je het redt met relaties kan ik zo niet zeggen; ik vermoed dat je een Not In criterium gebruikt voor de importquery, wat op zich correct is omdat je dan bestaande artikelen uitsluit. Alleen: omdat er een niet-gedefinieerd teken aan het Artikelnummer wordt toegevoegd, gaat die match niet meer op; het artikelnummer 䃤600232䃤600232 is nu eenmaal niet hetzelfde als 600232. Je zou misschien het criterium nog kunnen verfijnen, en controleren op het eerste karakter van het artikelnummer. Is dat altijd een cijfer, dan is dat simpel te doen, mag het ook een letter zijn, dan is de check iets lastiger, maar ook nog wel te maken. Eventueel kun je dan nog een Boolean functie maken die WAAR of ONWAAR retourneert op die check, en daar kun je dan weer op filteren in de toevoegquery.
 
Michel,

Met deze opmerkingen kom ik weer een stukje verder....

Het is trouwens inderdaad zo dat de eerste positie een "6" moet zijn. Ná de zes kan er ook een "letter" staan, maar de eerste positie MOETeen 6 zijn. Daar is wel een "validatieregel" voor te bouwen...denk ik.
Mijn ervaringen met Access zijn nog redelijk vers (ik heb deze tabellen ook niet zelf gedefinieerd), maar daar moet ik uit zien te komen. (doe je dat met een invoermasker?)

Jan
 
Michel,

Denk je dat Left([artnummer];1)="6" een adequate validatieregel is? Of moet ik dat ergens anders regelen?

Jan
 
Als alle nummers met een 6 beginnen is dat prima. Overigens zou ik het wel als getal behandelen: CInt(Left([artnummer];1))=6
 
Dank voor je hulp...

Ik neem aan dat ik CInt(Left([artnummer];1))=6 altijd kan gebruiken; ook als het (hele) veld een TEKSTVELD is.
Ik ga dit de eerste tijd maar eens als 'wapen' inzetten...

Het ergert me wel dat ik dan nog niet weet waar de fout zit...
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan