Jeg får en underlig fejl ved brug af .Update kommandoen:
Microsoft JET Database Engine error '80040e21' The changes you requested to the table were not successful because they would create duplicate values in the index, primary key, or relationship. Change the data in the field or fields that contain duplicate data, remove the index, or redefine the index to permit duplicate entries and try again. /xxxxxx.asp, line 159
MEN, jeg forstå det bare ikke, for tabellen der skrives i har kun eet unikt indeks og det er det primære autonummererede felt, hvorfor det aldrig burde være muligt at komme i en situation med dublikerede værdier!
Jeg har nu downloadet databasen og prøvet at indsætte en ny post manuelt. HER kommer det underlige, men som bekræfter fejlen:
Jeg har i forvejen 6333 poster i tabellen, men idet jeg indsætter ny post, så giver den autoincrement feltet værdien 6323! Altså helt forkert! Den skal jo automatisk give det næste nummer i rækkefølgen, dvs. 6334! Hmm..
Jeg har tidligere været ude for det samme og så har jeg slettet indholdet i min tabel. Det er næsten som om det sker når tabellen når en hvis størrelse..
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
En god ting at forsøge i sådanne situationer er at reparere/komprimere databasen.
Jeg har før oplevet at Access begynder at sætte nogle helt vanvittige tal ind i auto felter. Men det har indtil nu kunnet løses ved at komprimere/reparere db
Problemet kan nogle gange ostå, hvis man indsætter poster hva en Insert-query (dette er den eneste måde at overrule' autonummereringen.
Så hvis du igen prøver at lave en tilføjelsesforespørgsel, som indsætter en ny post med det rigtige nummer, så kan du være heldig at den tæller rigtigt derfra:
Noget i retning af: Insert Into Dintabel ( ID ) Select 6334
Og det er i .Update kommandoen at den fejler. Men det er jo kun en sjælden gang imellem og tilsyneladende KUN når tabellen bliver forholdsvis stor. Skulle man ikke tro at der var en patch fra Microsoft e.lign.?
Hvordan kan jeg implementere din kode i min kode? Kan man lave et check på om .update kommandoen går godt, og hvis den ikke gør, så checke om det er en fejl 80040e21 og så lave din insert på en eller anden måde?
JO, det BURDE være ideen med et AUTOINCREMENT felt *s*, meeen man har jo hørt om fejl i databaser før *s*. Specielt Paradox er MEGET ustabil. Access håbede jeg var mere stabil end som det her er tilfældet. Den eneste rigtig stabile database jeg har oplevet er faktisk Progress, men den er desværre ikke så meget udbredt, måske fordi de ikke har så mange reklamekroner *s*
Og nej, jeg har ikke prøvet at kopiere dataene over i en ny tabel, da jeg jo ikke kan rende rundt & tage kopier med jævne mellemrum for at rette Microsoft-fejl. Men det ville sikkert hjælpe på den akutte situation! ;o) Men det jeg har gjort (indtil videre) det er at slette posterne fra 6322 til 6333 og så virkede det igen! MEN senere på dagen så kom fejlen desværre igen! *suk* Så det ville være rart at finde selve årsagen samt en mere permanent løsning! ;o)
Angående Paradox, så synes jeg da ikke jeg har oplevet de store problemer da jeg brugte den for snart en menneskealder siden. Progress kender jeg desværre ikke, men DataEase har jeg også arnejde en del med for mange år siden - det var også godt. Nu bruger jeg kun Access som backend hvis 'kunden' insisterer, ellers hedder det SQL Server 2000 - og der er ikke de store problemer ( læg mærke til at jeg ikke sider 'ingen' :-) )
Jeg mener heller ikke det er meningen at man skal gå og lave nye tabeller, men som nævnt tidligere har jeg oplevet sjove ting med autoincrement som har krævet radikale tiltag for at blive løst, som f.eks. at kopiere data til en ny tabel.
Paradox lavede altid corrupted tabeller, hvor man skulle bruge et tabelrepareringsværktøj kaldet TUTILITY. Det er alment kendt af de fleste softwarehuse & konsulenter der brugte det dengang. Det var nok årsagen til at alle gik væk fra den igen, det var ellers ærgeligt, for ellers var det jo en god database & et veludviklet programmeringssprog ObjectPAL.
Hehe.. jaa, det er nok svært at sige at INGEN har fejl, såå det gælder vel om at finde en der er rimeligt stabil. *s*
Ved du ellers om det er nemt & migrere fra Access til MS SQL Server, når vi snakker web? Jeg tænker specielt på, er det de samme datatyper, indekser, date & time & autoincrement typer & formater & SQL strenge?
Så snart du snakker web og SQL, så snakker vi også mange dyrt :-) Man skal købe en eller anden hundedyr licens til SQL Serveren før man må/kan bruge den på webbet.
Det er vel også derfor at mange vælger at bruge MySql på webbet :-)
Min udbyder siger at der ligger den nyeste udgave på deres servere. Og mht. cursortypen, så har sitet sådan set virket i årevis med den cursortype. Det er kun en sjælden gang imellem at den laver det her ballade..
mvh. Martin
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
