Hvordan findes ID'et i tabellen

det skulle virke hvis du har sat id til et identity field. har du det

Syntaksen er således

CREATE TABLE jobs

(
  Id  int IDENTITY(1,1),
  Navn varchar(100,
  tlf varchar(12)
)

ellers højreklik på tabel og vælg identity under kolonnen id + en værdi hvorfra feltet skal starte fra og hvormeget værdien skal steppe med
 

Hele humlen omkring identity er at du ikke skal bekymre dig omkring feltet ved insert, derfor må du heller ikke angive et identity felt i din værdi liste

Erhmm... nej. Det var nu ikke lige det jeg mente.

Okay, jeg prøver igen.

Efter min INSERT skal jeg bruge primær nøglen i en anden tabel hvor den fungerer som fremmednøgle.

Så det er noget i stil med:

insert i tabel1
find primær nøgle
insert primær nøgle i tabel2

Er det forklaret godt nok?

DECLARE @ID Integer
INSERT (Navn, Tlf) VALUES ('her', '12345678')
SELECT

damn tab og return

DECLARE @ID Integer
INSERT Test(Navn, Tlf) VALUES ('her', '12345678')
SELECT @ID = @@IDENTITY
INSERT Test2(ID, Navn, Tfl) VALUES (@Id,'Test', 'Test')

Dette kan kun virke hvis der ikke er nogen insert trigger
ellers kan @@IDENTITY være sat til noget forkert.

SELECT @ID = @@IDENTITY skal altid køres lige efter indsættelsen.

Jeg har 2 andre forslag, hvis du ikke kan benytte dette

Hmm, er det så ikke nødvendigt at ovenstående udføres som 1 transaktion? Ellers kan der jo komme en anden imellem.

Virker metoden også med uniqueidentifiers som primary key?

Hej Blackthorne

Umiddelbart ser det ud som det er noget jeg kan bruge.

Problemet er bare at jeg bruger det i ASP, og får en "Must declare variable '@ID'"

Noget tyder på at hvis det ikke fyres af i et script, så mister den variablen (ude af scope eller hvad?)

Ngen forslag?

Det gør vist ingen forskel om det gøres i en transaction, fordi @@Identity er en global variable som benyttes for alle identity field. jeg mener ikke at access til globale variable inkluderes i transaktion. Derfor er denne løsning ikke multiuser sikret, ej hellere i en transaktion. et af mine andre forslag er sikret imod multiuser problematikken

har du husket DECLARE @ID Integer.

Desuden der må ikke være nogle go statements imellem erklæringen af variable og når den anvendes

Ok, her er testen.....

set dbConnection = Server.CreateObject("ADODB.Connection")
dbConnection.Open Application("connectionString")
SQLStatement1 = "DECLARE @studentID Integer"
SQLStatement2 = "INSERT INTO student (navn, tlf) VALUES ('test', 'test')"
dbConnection.Execute(SQLStatement1)
set r = dbConnection.Execute(SQLStatement2)

SQLStatement3 = "SELECT @studentID = @@IDENTITY FROM student"
set r = dbConnection.Execute(SQLStatement3)

SQLStatement4 = "INSERT INTO student (ID, navn, tlf) VALUES (@studentID, 'test', 'test')"


Jeg kunne forstille mig at det er noget med recordsettet (set r = xxxxx)

Det skal være følgende

set dbConnection = Server.CreateObject("ADODB.Connection")
dbConnection.Open Application("connectionString")
SQLStatement1 = "DECLARE @studentID Integer"
SQLStatement1 + "INSERT INTO student (navn, tlf) VALUES ('test', 'test')"
SQLStatement1 + "SELECT @studentID = @@IDENTITY FROM student"
SQLStatement1 + "INSERT INTO student (ID, navn, tlf) VALUES (@studentID, 'test', 'test')"
dbConnection.Execute(SQLStatement1)
set r = dbConnection.Execute(SQLStatement1)

Det hele skal køres på engang eller kender serveren ikke længere variablen, fordi variabler lever kun indtil næste go statement eller indtil connection forsvinder og det gør den i dit tilfælde.

Yep

Det virker som det skal! Mange tak

Ja det virker, men husk på at i ekstreme tilfælde kan du risikere at få en andens brugers unikke nr. Det skal du lige huske er at undersøge om du vil tillade dette. Hvis du ikke vil tillade dette er der andre metoder!!!, som er lidt mere besværlige end nævnte

Kan de betale sig sig at låse basen mens man udfører SQL'en?

Nej for det sker måske i 0.005 af tilfældende. Desuden hvis du låser databasen ødelægger du at der kan være flere på systemet afgang og vil få lange svartider.
løst beskrivet lavet det således
man har en tabel med en kolonne som indeholder det sidste uniknr, så laver man en stored procedure der ligger i en transaktion, som først opdatere kolonnen med værdien af kolonnen + 1 og derefter select kolonnen som returnerer værdien

Grunden til at det er multibruger sikret er fordi når man først opdater og læser en værdi fra en tabel i en transaktion, så kan andre connection ikke opdatere felt men må vente til det bliver deres turn