Hur ska man få reda på vilken plats en insert hamnar på. Mitt exempel: jag vill spara ner en klubb och sedan spara ner ett lag som hör till den klubben. Primärnyckeln är en räknare och klubbid är en främmande nyckel i Lag? Försökte att söka upp max värde i klubb efter insert men det känns inte rätt och kan bli fel om någon hinner imellan.

Se mitt inlägg
[143589]

Du gör "select @@Identity" om du inte jobbar med sp

Det finns flera sätt, här är några :

* Ändra primärnyckel till ett GUID (UniqueIdentifier). Detta kan du lätt skapa redan i GUI:t, och sätta dessa i DataSetet/RecordSetet både på master-(klubb) och detail-tabellen (lag), innan du skickar ned datan.

* Använd en Stored Procedure och returnera SCOPE_IDENTITY() eller @@Identity...Har för mig att SCOPE_IDENTITY() ger säkrast resultat.

* Har du möjligen ett annat unikt fält i tabellen, t ex klubbnamn? I sådana fall kan du ju ställa en fråga efter insert : SELECT [ID] FROM Klubb WHERE [Namn]='klubbnamn'

Personligen föredrar jag lösning 1 eller 2...

Din föreslagna lösning med MAX() är inte alls bra i ett fleranvändarsystem (för eller senare får du en konflikt), men kan fungera ok om det bara är en användare. Ovanstående lösningar är dock säkrare...

Ska prova med sp och använda mig av SCOPE_IDENTITY() får väl bli att googla

Om du vill veta mer om @@Identity, SCOPE_IDENTITY() och IDENT_CURRENT kan du läsa här, http://www.pdc.se/blog/DisplayEntry.aspx?eid=12

uniqueidentifier är en 128 bitars datatyp, och kan inte rekommenderas om man inte har specifika behov (replikering etc.). Den tar onödigt mycket lagringsutrymme och slöar ner operationer (ex. joins) jämfört med en vanlig int.

/k

> <b>uniqueidentifier är en 128 bitars datatyp, och kan inte rekommenderas om man inte har specifika behov (replikering etc.). Den tar onödigt mycket lagringsutrymme och slöar ner operationer (ex. joins) jämfört med en vanlig int. </b>

Man får givetvis väga fördelarna mot nackdelarna...Det är sällan storleken på datatypen eller prestandan är relevant i mina projekt/jobb i alla fall. Det är mycket oftare (utvecklings-)tiden som måste optimeras och då är enklare lösningar viktigare än optimerade/slimmade. Personligen gillar jag GUID-lösningen men använder den bara när jag behöver, dvs i fallet som beskrevs ovan.

Som jag förstår det så skapas Guidet innan det skickas ner i databasen och man behöver inte vänta på svar eller söka efter nyckelid. Nackdelen är att man måste generera guid på samma dator men det görs ju på webbservern. Låter som ett bra förslag, finns det några bra förslag på kod

Jag håller med Kalle Dahlberg. GUID bör av prestanda skäll endast användas om absolut nödvändigt.

Int och BigInt räcker långt.

Vad menar du med att Int och bigInt räcker för en lösning som jag beskrev? Du förordar en annan lösning alltså vilken?

Mvh Stefan Ljungstedt

Jag säger att det är väldigt få fall man behöver GUID. Jag pratar inte om specifika lösningar. Om din anledning för att använda GUID är att man kan kan skicka in den i en SQL sats. Så tycker jag du borde omvärdera användningen av GUID.

Skillnaden med att infoga ett GUID och att arbeta med en räknare är at du måste få en räknare retunerad. Vad är det som är så alvarligt med detta, eftersom du valt GUID för detta?

Hur returnerar man då en id vid en Insert för att veta vilket id den fick?

Stefan

@@SCOPE_IDENTITY() eller @IDENTITY(). MEn man får ge akt på triggers.

> <b>@@SCOPE_IDENTITY() eller @SCOPE_IDENTITY(). MEn man får ge akt på triggers.</b>

Du blandar ihop @@IDENTITY och SCOPE_IDENTITY() här, Andreas.

Hur som helst, en SP som returnerar en identity-kolumn kan se ut så här :

CREATE PROCEDURE InsertCustomer
    @Name     varchar(50)
AS
    INSERT INTO Customer ([Name]) VALUES (@Name)
    SELECT SCOPE_IDENTITY()
    -- Mindre bra alternativ : SELECT @@IDENTITY
GO

Vad menar du med blandar ihop? JAg slarvade när jag klip och klistrade. ;o)

Viktigt: Om man har fler insert-satser efter varandra (eg. använder scope_identity() flera gånger) så måste man ha felhantering. Annars följer tidigare värdet på scope_identity() med vid en rollback.

/K

Då var väl detta löst TAck! behöver alltså använda mig av sp och SCOPE_IDENTITY

Stefan Ljungstedt