Har två tabeller som jag vill lägga in data i.

Booking tabellen har fälten: IDBooking,RoomCategory,NrOfAdults,NrOfChildren,INPCategory,ExtraBed,BabyCrib,SortOfPayment,CheckInDate,CheckOutDate,Remarks,SubSum,TotSum,CheckInStatus,CheckOutStatus,IDGuest

Guest tabellen har fälten:
IDGuest,FirstName,LastName,Adress,ZipCode,City,State,Country,Telephone,Fax,Email

Guests primärnyckel är alltså främmande nyckel i booking.

Jag vill ha en smart, kombinerad INSERT/SELECT/INSERT sats till detta så jag slipper att köra INSERT INTO GUEST, SELECT ... FROM GUEST och sedan INSERT INTO BOOKING i tre olika omgångar.

Har för mig att jag sett liknande frågor och svar här tidigare.

Tack!

Skapa en stored procedure (om du kör SQL-Server)

CREATE PROCEDURE ps_INSERT_booking
@firstName varchar(50),
@enAnnanVariabel Integer
...ännu fler variabler
AS
@DECLARE GID Integer
INSERT INTO GUEST(firstName,...fler variabler) VALUES(@firstName,...)
SET GID = (SELECT @@IDENTITY)
INSERT INTO BOOKING(bla,bla,IDGuest) VALUES(nlanal,mnlöan,@GID)


så får du allt gjort i ett enda anrop till

EXEC ps_INSERT_booking 'Kalle', 4,......osv

Hmmm.. jag kör till en Accessbas.

Skulle vilja ha ett rent SQL anrop. typ INSERT INTO...(SELECT...(INSERT ...)) och så är det säkert en del JOINS mm mm.

Det finns lite magi med Access som gör att du kan infoga informationen du vill med bar en Insert. Hemligheten är att först skap en fråga.

Fråga: qryBookning
<code>
SELECT Guest.*, Booking.*
FROM Guest LEFT JOIN Booking ON Guest.IDGuest = Booking.IDGuest
</code>

Sedan inserta i den:
<code>
INSERT INTO qryBookning (FirstName, LastName, NrOfAdults, NrOfChildren, CheckInDate, CheckOutDate )
VALUES ('Nisse', 'Karlsson', 1, 0, #1/1/2001#, #1/7/2001#)
</code>

Tog bara några fält för att demonstrera principen.

Jag tycker du förlorar lite möjligheter i framtiden om du bygger upp din logik, dvs ASP koden mm på att du skall kunna göra INSERT till en fråga. Då kan du endast använda MS Access och inte på ett enkelt sätt byta databas i framtiden. SQL server har sian Stored Procedure som inte stöds i många andra databaser. Gentemot SQL databaser är det mest generella att alltid köra rena SQL frågor direkt.

Du har dessutom planerat att ha EN rad per individ som är gäst, och dessutom har du tänkt ha EN rad per gäst i din booking tabell? Om du vänder på logiken så att varje gäst har en främmande nyckel som är ditt booking_nr så får du likt en order-orderrads logik.

Varje gäst tillhör en bokning, varje bokning kan ha X antal gäster. Många av dina fält i booking är också härledbara utifrån antal gäster etc. Se gärna över det för bästa prestanda och högsta normaliseringsgrad.

Roger

Jag håller med dig vad det gäller att det inte är bra om man vill byta databas i framtiden. Vill bar demonstrera vad Access kan göra. Access är en rätt imponerade databasmotor vad det gäller funktionalitet.

Om varje bokning har en ny gäst borde informationen ligga i samma tabell.

Annars bör man förs söka upp gästen och dess ID nummer för att sedan skapa en bokning med dess GuestId.

Tack för era svar och kommentarer!

De två tabeller som jag beskriver är "slutstationen" i bokningen av en gäst/gäster.
Kraven att veta alla gästers namn till en bokning finns inte varför jag inte har normaliserat upp det ytterligare.

Tabellen booking kommer att hålla data om gjorda bokningar och skall inte påverkas av framtida förändringar i databasen såsom prisförändringar, rumsförändringar mm mm. Tabellen skall, förutom att "lagerhålla" data också användas att köra statistik på.

Övriga tabeller som håller "rådata" och som inte finns beskrivna här har högre normaliseringgrad för ökad prestanda osv.

Håller mitt resonemang?

För att återgå till grundfrågan... finns det någon smart kombinerad ren SQL fråga som utför det jag vill. Andreas... ditt förslag med Access låter ju bra men jag håller med om svårigheterna vid ett databasbyte.

Tack igen.

Peter

Vill gärna utveckla mitt resonemang kring var guestID lagras. Det är avhängt tror jag om du behöver göra en INSERT eller två stycken.

Tänk er följande för en bokning.

Rum = 1, Antal vuxna = 2, Antal barn = 2 etc.

I tabellen bokning lagras då info om bokningen i sig, dvs rumsnummer, pris, incheckning etc. Det är samma uppgifter som gäller för alla gäster i rummet, oavsett om de är 1 eller fler personer. Skall du då lagra i tabellen bokning guestID så får du i detta fall 4 poster i databasen med exakt samma info per rad utöver olika guestID.

Vänder du på det som jag föreslår får du EN rad i tabell bokning och i tabell Guest får du fyra rader med för- och efternamn samt vilken bokning gästen tillhör.

Samma resonemang kan föras kring en faktura. En faktura innehåller X antal fakturarader. Det vore oklokt att skapa X antal rader i fakturatabellen där det enda som skiljer dem åt är produktnyummer och antal. Bättre är då att bryta ut till två tabeller med övergriåpande fakturainfo i faktura-tabellen, samt fakturarader med uppgift om produktnumemr och antal i en fakturaradstabell.

Bor gästen på samma ställe flera gånger skapas en ny rad med gästens uppgifter per bokning. (Kan givetvis bryta ut även detta i ny tabell med Personer ... )

Om du gör på detta sätt skapar du bokningen, samt knyter gäster till bokningen en och en. Görs detta i ASP sida så laddas sidan om varje gång ny gäst knytes till samma bokning och då anropar du INSERT SQL för varje gäst som läggs till. Eftersom det blir ett ökat anrop mot DB är iden dålig, men alternativet är att knyta det mot en Access-fråga som Anders föreslog, jag kan inte tänka mig någon annan lösning genom ett enda anrop till DB.

MS Access är ju bra på det sättet att den erbjuder lite specialfunktioner. Access är dessutom tillräckligt bra DB om det inte blir för många användare mot samam DB.

Roger,

>I tabellen bokning lagras då info om bokningen i sig, dvs rumsnummer, pris, >incheckning etc. Det är samma uppgifter som gäller för alla gäster i rummet, oavsett >om de är 1 eller fler personer. Skall du då lagra i tabellen bokning guestID så får du >i detta fall 4 poster i databasen med exakt samma info per rad utöver olika guestID.

Enligt din föreslagna bokning, precis som den kan inträffa i verkligheten, är det bara bokningsnamnet som lagras i db. Övriga gäster bokförs inte på någor sätt. Därför lagras inte heller deras namn på X antalet poster i db. Bokningsgästen lagras till db men antalet övriga gäster till en bokning blir endast en siffra till posten för själva bokningen.

Bokningsgästen bär ansvar för de övriga gästerna varför de inte behöver bokföras.

>Bor gästen på samma ställe flera gånger skapas en ny rad med gästens uppgifter >per bokning. (Kan givetvis bryta ut även detta i ny tabell med Personer ... )

Om återkommande gäst bokar ett rum kommer gästen att identifieras som återkommande gäst och därmed kommer endast en ny bokning med dess nya villkor att sparas i db (booking). Gästen återfinns då i Guest tabellen. Om inte gästen återfinns... ny gäst i Guest tabellen.

Jag kommer inte att köra detta mot en ASP sida men jag tycker också att Access duger bra så långt man kan bestämma antalet frågor som få till DB.

Återigen... finns det någon smart och kombinerad SQl fråga som kan kombinera INSERT/SELECT/INSERT?

Om inte så kör jag bara de olika frågorna i olika omgångar.

Tack!

Jag fattade inte detta först =)

Har ingen input kring en kombinerad super-SQL sats men hoppas det löser sig.