12. december 2003 - 10:26Der er
33 kommentarer og 1 løsning
Skrivekonflikt i SQL Server
Under en brugers opdatering af en given post, har jeg oplevet en konflikt som jeg ikke har set før i forbindelse med SQL Serveren:
Skrivekonflikt Denne post er blevet ændret af en anden bruger, efter du begyndte at redigere den. Hvis du gemmer posten nu, overskriver du den anden brugers ændringer. Hvis du kopierer ændringerne til udklipsholder, kan du bagefter se, hvad den anden bruger har indtastet og evt. indsætte dine egne ændringer, hvis du vil foretage ændringer.
Knappen Gem post er nedtonet, Kopier til udklipsholder og Annuller ændringer er aktive.
Da vedkommende var ved at indtaste data, havde jeg tabellen åben i MMC, i designvisning, for at ændre et felts egenskaber (allow null). Anden gang vedkommende fik samme fejlmeddelelse, havde jeg igen åbnet tabellen i MMC, men havde IKKE foretaget nogle ændringer. Er det sådan i SQL Server, at man ikke kan foretage ændringer til tabelstrukturen, uden at brugernes indtastninger bliver "fucked up"?
I dette særtema om aspekter af AI ser vi på skiftet fra sprogmodeller til AI-agenter, og hvordan virksomheder kan navigere i spændet mellem teknologisk hastighed og behovet for menneskelig kontrol.
Det der sker er, at din klientapplikation opdager, at der er sket en ændring i den post som er i databasen siden den blev læst. Det kaldes "Lost update" - og det er det den forsøger at undgå.
Lost update er et velkendt "problem" i flerbruger-systemer - en nem løsning er at bruge MTS'en. Den tillader dig at designe systemet som et enkeltbrugersystem - men det kører som flerbruger. Men da du - så vidt jeg husker - bruger Access som frontend, så hjælper det sikkert ikke.
Jeg mener at huske, at når Access læser data i en linked tabel, så overfører den faktisk samtlige rækker til sin egen "buffer". Muligvis så slipper den derefter sin share-lås på tabellen (det kan undersøges via sp_who2 og sp_lock).
Når access-brugeren så vil gemme sine ændringer, så checker access at data "før" ændringen matcher dem der er i tabellen - netop for at undgå lost update - gør de ikke det, så gives en fejl.
Selve matchningen behøves ikke at foretages med data, men kan ske internt på rowversion der blot fortæller om en række er opdateret.
Du vil nok også komme ud for det mellem brugere - specielt hvis de ikke bruger samme access mdb-fil.
Det var godt nok en ordentlig omgang, men........hvad er løsningen på mit problem? Jeg KAN #%¤# ikke være den eneste som vil køre 5-10 brugere på 3 Access XP fronts opmod en SQL Server?!?!?! :(
Det med linked tables i Access; jeg har p.t. én Access frontend og én Access backend, 5-6 brugere bruger den samme frontend (i "gamle dage" havde hver bruger deres egen kopi af frontend'en), uden problemer....så hvorfor viser problemet sig så først med SQL Server backend'en (linked)?
Hmm... hvad har du af indeks på tabellen? Og hvor stor er den ca. i KB?
Endnu en lang omgang; Når SQL Server skal opdatere, så sætter den en lås i tabellen. Den vil forsøge at låse på rækkeniveau, men kan vælge at låse på page (8 KB), ekstent (64kb) niveau eller helt op på tabel-niveau i stedet. Det afhænger af antal rækker opdateret og indeks.
Ved små tabeller er indeks ikke altid en fordel, SQL Server vil fravælge at bruge indeks på tabeller < 64Kb.
Jeg går ud fra, at du har defineret en primær nøgle - ellers vil access nemlig ikke uden videre tillade opdateringer - men hvis du har en where betingelse når du læser data ud - så prøv at lægge et indeks på samtlige kolonner der indgår i where betingelsen. Og sørg for, at den kolonne med størst spredning (flest forskellige værdier ifht antal rækker) står først i indekset.
Der er et "autonummeringsfelt", ID, som vist ikke er indekseret (du mener Full-text indexing, ikke også? det er der ingen af felterne der er). Størrelsen på tabellen, hvor ser jeg det? Der er 340 poster, med 15 felter, kun en enkelt er på 255 characters.
Full-text indeksing er noget helt andet (faktisk en delvist integreret søgemaskine som med mellemrum bygger et katalog op - lidt alle en websøgemaskine).
Det jeg mener er helt almindelige indeks. Du tager properties på tabellen, og sørger for at lægge indeks på - der er en speciel fane til det.
Du bør have angivet et primary key indeks på den kolonne der er din unikke nøgle (kolonnen må ikke indeholde NULL værdier) - og så et andet indeks som beskrevet.
Muligvis skal du relinke Access tabellen for at Access kan have glæde af indekset. Du vil i øvrigt så også slippe for at skulle fortælle Access hvilket felt der er nøglefeltet - det kan den selv "se".
Uden indeks overhovedet vil SQL Server være tvunget til at bruge page-locking. Det kan være ganske mange rækker - og med så lille tabel kan det være hele tabellen der låses.
Meget meget kort; Indeks er en sorteret liste (en træstruktur) der indeholder data fra udvalgte kolonner. Databasen kan så udnytte indeks til lynhurtigt at fremfinde og sortere data - og dermed bliver alting nemmere.
Du kan prøve at søge via google på b-træer og b+ træer (den sidste struktur er den normalt brugte i databaser).
"Det jeg mener er helt almindelige indeks. Du tager properties på tabellen, og sørger for at lægge indeks på - der er en speciel fane til det." De eneste 2 faner jeg har er: General og Full-Text Indexing. (det var derfor jeg spurgte ang. Full-text indexing)
Det eneste jeg kan komme på er at den tabel der ikke kan opdateres har nogle felter af typen bit og float......prøver lige med en anden tabel som indeholder bit og float.
Eh.. ups. Du har ganske ret - skyldes at vi normalt anbefaler at bruge TinyInt på arbejde fremfor bit (du kan lægge indeks på TinyInt), Værdierne i en BIT i sql server er 1 eller 0 - ikke TRUE eller FALSE.
Check lige hvad flagene TRUE og FALSE bliver til i Access - jeg kan huske at VB i gamle dage brugte 0 for TRUE og -1 for FALSE (eller noget i den retning).
Hmmmm....hvis jeg åbner tabellen i MMC, er værdierne 0 og 1, men hvis jeg åbner den sammenkædede tabel i Access, er værdierne 0 og -1! :( Hvordan skal jeg "konvertere" fra bit til tinyint?
WADDA YA KNOW?! Jeg ændrede typen fra bit til tinyint i MMC, opdaterede de sammenkædede tabeller og vupti!, nu kan jeg redigere data! :) :) :) Takker mange gange for hjælpen, trer.
For mig betyder morgentræthed at jeg ALTID tager en ekstra backup før jeg laver noget - for ellers kommer jeg bare senere hjem ....
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.
