Har följande problem som jag ej får till.
Kan ej returnera ett recordset till asp sidan när jag gjort in insert i databasen.
Proceduren:
ALTER PROC insNewTest
@TestName varchar(50)
AS
INSERT INTO tblTest
(TestName)
VALUES
(@TestName)
Select MAX(TestId) AS NewIdentity FROM tblTest

Med denna proc returneras inget recordset till asp sidan som ser ut som föler:
strSQL = "insNewTest '" & strName & "'"
Rs.Open strSQL,Conn,1,3
Response.Write Rs("NewIdentity")

Flyttar jag däremot upp raden
Select MAX(TestId) AS NewIdentity FROM tblTest
i procen och lägger den ovanför inserten så returneras NewIdentity utmärkt men då givetvis det tidigare idnumret.
Vill ej plussa på detta med 1 då tabellen kan vara tom i bland.

Finns det något sätt att lösa detta utan output parametrar vilket jag inte kan ha i asp koden då detta kommer att skickas in i en komponent?

Din procedur medför att två stycken recordset skapas. Insert-satsen ger upphov till ett tomt recordset och sedan så blir det ett till som innehåller värdet av select-satsen.

Om du skriver om proceduren

ALTER PROC insNewTest
@TestName varchar(50)
AS
set nocount on
INSERT INTO tblTest
(TestName)
VALUES
(@TestName)
set nocount off
Select @@identity as newidentity


så blir det enbart ett recordset.

(Använd inte max för att få fram senast inlagda räknarvärde.)

Jag skulle rekomendera GUID som datatyp. Knaske lite för jobbigt för din aktuella applikation. Kräver ju att du uppdaterar alla tabeller.
Men kanske nästa.

En av fördelen med GUID är att du kan skapa det själv och skicka in det i frågan. Och på så sätt inte behöver retunera ID från servern. Vilket är mycket smidigt. Kan ju skapa en metod på din komponent vilkent skapar ett nytt GUID. Sedan är det ju bara att skicka med det i din insertsats.

Lars lösning stämmer bra, dock skulle jag inte säga att man kategoriskt ska använda @@identity för att få ut högsta värdet. Tänk vad som händer om någon lägger på en trigger på din tabell som gör en insert i en annan tabell. Då kommer @@identity att ge dig denna inserts id-nummer. I detta fall fungerar MAX() utmärkt. Men visst, prestandan är (något) bättre med @@identity.

Om man använder SQL Server 2000 så finns dessutom möjligheten att utnyttja en funktion som heter SCOPE_IDENTITY(), vilken ger det senast skapade identity-värdet i nuvarande 'scope' (med scope menas en lagrad procedur, trigger eller batch). Så även om en trigger gör en insert vidare så gerSCOPE_IDENTITY() det id som skapades senast i den aktuella proceduren.

Nja, en GUID här känns väl inte riktigt nödvändigt. Det fungerar ju alldeles utmärkt att returnera det skapade id-värdet från proceduren, antingen i ett recordset eller en output-parameter (jag förstod inte riktigt anledningen till att en output-parameter inte kunde användas bara för att ett objekt ska användas). En GUID är ju 4 ggr så stor som en int, och det försämrar ju naturligtvis prestandan. Ser som sagt ingen anledning att använda dem om man inte absolut måste (ex. vid merge replication).

Vår frågeställare har ju valt att göra en komponent vilket har en metod som har ett SQL uttryck som argument och retunerar ett recordset. Förstår inte varför han gjort så här.

Får hoppas han förklarar vad komponenten har för syfte...



Varför GUID's är bekväme och har viss prestanda fördel.

Det är bekvämt med GUIDs. Tänk dig att du ska infoga en poster i en tabell med hirarksik struktur. T.Ex Parent-Child förhållande. Bara att skriva dina insertsattser med de skapade GUID'en.

Efter som jag direkt känner till förelderns ID kan jag skicka alla Insertsatser på en gång. Bara att köra en execute och det är klart.
Hur kul skulle det vara om man var tvungen att vänta på idnummret för varje post. (Lite specefikt fall)

Dessutom kan man ju skicka anropen asynkront. Behöver ju inte vänta på något svar. för att fortsätta. Vilket är en mycket bra fördel för webbapplikationer. Efter som Webserven frigör resurser till att gör annat.

Okej. Den är fyragånger större. Vilket antagligen kommer märkas i joins. Helst om fälten inte är indexerade. Microsoft nissarna har ju säkert ägnat lite extra tid och tänkt på det. Eller det kan man ju alltid hoppas. Men tror en Int slår GUID's med hästlängder när det gäller Joins.

Så små databaser med enkel datastruktur är Inte är bra alternativ. Annars kanske man bör överväga fördelarna med GUID's. Helst när det gäller webbapplikationer.

Hmm..du skulle alltså göra en insert i en databas asynkront? Vad skulle du ha för garanti på att det går genom? OK, du kan köra ex. MSMQ men då snackar vi ju lite högre komplexitet. Själv är jag dock 'databasnisse' och föredrar att lägga logik i lagrade procedurer (i de fall det är användbart naturligtvis). Det är väl även därför jag är orolig för prestandaförluster med GUIDs, vilka jag vet kommer vara märkbara (det är inte så mycket ms-nissarna kan göra specifikt för joins på denna datatyp).

Men visst, jag säger inte emot dig i att GUIDs har flera fördelar vilket gör att de kan vara mycket användbara och önskvärda i vissa situationer.

Har bara använt asynkront insert typ vid databaskonvertering. Där jag inte har något behov av att typ kontrollera svaret. Enkelt att jämföra antalet poster när alla anrop gjorts. Vet inte. Är jag fel ute?

Nej, i den situationen känns det kanske inte helt fel. Jag tänkte snarare på exempelvis en transaktion i en webbapplikation, där jag inte skulle kunna tänka mig att göra en insert asynkront utan någon sorts garanti för att den går genom.

Komponenten har som syfte att ta hand om alla Select Inserts och Update i en webbapplikation.
Komponenten har en Privat Funktion som har hand om kopplingen mot databasen.
En Publik Funktion som endast gör execute mot databasen
En Publik Funktion som returnerar ett recordset.

Med hjälp av denna komponent behöver jag aldrig sätta några conn öppningar mot databasen i asp sidorna.
Jag behöver endast skicka in SQLProceduren och parametrar till komponenten och välja funktion beroende på om jag vill ha tillbaka ett recordset eller endast göra en insert eller update.

Känns som en vettig och säker lösning.

Har du en instans av objektet. Eller skapar du en instans när du använder den?

Jag skapar en instans när jag använder den och sen stänger jag den när sidan är slut eller om jag inte behöver använda den mer på asp sidan.
Är det någonting som inte är bra med det sättet så vill jag gärna ha förslag på bättre sätt!

Det låter väl okej. Var rädd att du hade en instans i Global.asa.
Har för mig att det hindrar IIS från att berabeta flera sider åt gången. En sida har då bara tillgång till objektet och nästa sida måste vänta tills den första är klar med objektet.