Jeg har et problem, som jeg er sikker på der er nogen der kan hjælpe med.
Jeg er igang med at udvikle en shopløsning men er stødt på et problem.
Problemet opstår som følge af.:
En kunde går ind på betalingssiden her henter jeg så det højeste ID fra tabellen orders og tilføjer en record - dette sikre at 2 kunder ikke når samme side samtidig og får samme ordreID. Dette ordreID gemmes så i betalingsgatewayen sammen med PBS-transaktions nummer.
Alt sammen meget godt, men lad os tage udgangspunkt i følgende scenario.
Tabellen orders har p.t. orderID 100 som største record.
Der kommer nu en kunde ind på betalingssiden han får tildelt ordreID 101 - men imellemtiden vælger en anden kunde at lave en bankoverførsel og bruger så ordreID 101.
Dette betyder at når kunden på betalingssiden gennemfører får han en fejl om at der allerede er en record med dette ID (ikke hensynsfuldt)
Hvordan kan jeg "reservere" det her ID i databasen? På den måde ville bankoverførslen få ordreID 102, da ID 101 var "låst" af databasen...
Hvad med at allerede når man går ind på betalingssiden så gemmer den bare id'et og tid og dato i databasen (eller hvad det nu kan være) og så senere opdaterer?
Hvad hvis man vælger ikke at betale alligvel - så har jeg en record i databasen som er unødvendig (og i mit tilfælde ville det give en "tom" ordre - som jeg så skulle til at bøvle med at slette)
Brug Identity til primærnøglen og pak ordren ind i en transaktion. Man skal ikke hvad transaktioner kørende fra ordrens start til brugeren afslutter, kun den del der skriver til tabellen skal transaktioneres.
Du blive nok nødt til at lave ordrene uanset om de er tomme eller ej. Burde ikke være svært at sortere fra i en "select". I ordre-recorden kan du have et bit-flag der fortæller om den er annulleret eller ej
Som Arne beskriver er det ikke andet end (det er nu ret meget andet, men det simple svar er vist OK), at man før en eller flere skrivninger til tabellerne laver en "begin trans". Kommandoerne udføres og hvis de går godt bliver alt skrevet i én atomar handling vha. "commit trans". Går det galt rulles tingene tilbage til før transaktionen, her ved kommandoen "rollback trans".
Transaktionens opgave er at sikre, at databasen aldrig ender i den situation hvor der er oprettet en ordre og kun halvdelen af ordrelinjerne er blevet skrevet.
Hver gang du skriver til en tabel bliver der automatisk lavet en transaktion. Det er langsomt og her vindes en masse ydelse ved at pakke transaktionen udenom passende klumper af operationer.
Ang. eksemplet. Hvad laver du programmet i? Er ovenstående T-SQL eksempel nok til at hjælpe dig videre?
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.
