Skrivekonflikt ved skrvning fra access til MS SQL

Jeg har ikke forstand på SQL-server, men er enig i, at fejlen sandsynligvis ligger på serveren. I ren Access kommer fejlen som regel når du prøver at ændre data, medens tabellen allerede er åbnet af en anden bruger.

Det at lave nye formularer tror jeg ikke hjælper (som du også selv har konstateret).
Prøv at gå metodisk til værks og se, om du kan finde en sammenhæng i de tilfælde hvor skrivekonflikten opstår.

"Problemet" er set før - og vist også løst i andre tråde her. 

Start med at checke at du har oprettet primærnøgler på dine tabeller i SQL Server - og relink så alle dine tabeller til din Access frontend. Sørg også for, at du ikke får pillet ved låsetyper og cursor placering ved DSN oprettelsen og i din vb kode.

Uden nøgler kan access få problemer med bl.a. med defaults og identity på sql server - de værdisættes først ved commit, og ikke før i access ved postoprettelse.

Hej Nikolaj,

Tak for sidst :o) Håber at opdateringsfunktionen fungere som den skal!?

Jeg har selv oplevet fejlen tit - både i ren Access og i Client/Server-løsninger. Min erfaring er, at det oftest skyldes konflikter - ikke mellem flere brugere - men mellem forskellige processor/kommndoer i Access. Det kan f.eks. være:
-Hvis du udfører en handlingsforespørgsel på samme tabel, som din formular
-Hvis du arbejder med Recordsets af samme tabel, som formularen
-Hvis du f.eks. åbner en ny formular baseret på samme tabel (eller en forespørgsel, hvor tabellen indgår), som din hovedformular

Hvis fejlen først er opstået efter upsizing til SQL server, kan det skyldes at Access ofte foretager en masse automatisk opdatering, når man klikker rundt i systemet. Nogle af disse automatikker er sat ud af drift, når det ikke er en ren Access-tabel.

Ofte kan man afhjælpe problemet ved at sætte denne kommando ind strategiske steder (f.eks. inden en handlingsforespørgsel eller inden en ny formular åbnes):
docmd.runcommand accmdsaverecord

Det kan ofte også anbefales at lægge et Timestamp-felt ind i hver tabel på SQL serveren. Dette gøres ved at orette et felt i hver tabel, som kan hedde hvad som helst, men som skal have datatypen Timestamp.

Risikoen for fejlen forøges, hvis man baserer sin formular på en forespørgsel med flere end én tabel.

Fortsat god weekend :o)

>> trer:
OK, jeg synes nu jeg havde kigget grundigt efter lignende. Jeg har lavet primærnøgler på alle tbl og gentjekket dette. Jeg har gjort det med 2 forsk. db'er (en sagsbehandlingsdb og en personaleadm.-db) og i begge de 2 db'er er det den 'primære' tabel hhv. tblSag og tblAnsat der skaber problemer. Andre relaterede tabeller med det - i princippet - samme tabeldesign har ikke problemerne.

>> thomasjepsen
Selv tak, jeg har et par enkelte kommentarer, men dem kan du få ved anden lejlighed.
Ift. dette spørgsmål har jeg konstateret at timestamp-metoden virker. Jeg tilføjede det nævnte felt i hver af de problematiske tabeller og så virkede det - hvilket jeg i øvrigt ikke finder særlig logisk og derfor ikke særligt betryggende...

God weekend til alle og tak for svarene!

At Timestamp - eller "rowversion" som er det korrekte navn i SQL Server 2000  - kolonnen fungerer er ikke overraskende; Den er beregnet som en unik rækkeidentifikation - og det er identifikation af rækkerne som er problemet når man bruger en singleuser frontend (som access) i et flerbruger system.

.. men jeg må indrømme at jeg ikke havde tænkt på den i den her forbindelse, ovenstående er blot efterrationalisering :-)