Hej!

Kan man använda en lagrad procedur till att skapa likadana tabeller men med olika namn.
Tanken är att man då som parameter skickar med den blivande tabellens namn.

Hej, självklart går det. Du tar tabellnamnet som input variabel och använder den i ditt create table- kommando.

Hej Krister

Så här kan du skriva:

create procedure createtable
@name varchar(30)
as

exec("create table " + @name + "(column1 varchar(15), column2 varchar(30))")

/Helena

Varför vill du skapa flera tabeller med samma
utseende, använd en och samma tabell med ett extra fält
som tala om vilken grupp raderna tillhör
/JW

Tanken är att tabellen skall användas som en temporär "varukorg" där man lägget till de olika varorna.
Efter köpet är klart läses de in i en "försäljningstabell" där de slutligen lagras och den temporära tabellen sedan tas bort. Inget är bestämt än utan finns bara i tankestadiet än så länge.
Programmet är tänkt att användas som ett butikssystem via internet där flera butiker är kopplade till samma databas och kanske också kunderna kunde göra beställningar.

Men det finns en del fårgor att fundera över t.ex
* Hur kan man snabba upp sökningen av en viss typ av vara och hur skall den listas upp.
* Vad händer om kontakten med servern bryts.
* Hur hög säkerhet behövs.
* Hur kollar man upp om ett visst erbjudande faller in, t.ex "köp 3 betala för 2", 2 chips + 1 2 liters Coca Cola för 30:-

Som sagt var finns det en hel del att fundera över. Om ni har några förslag till lösningar är ni välkommna.
Det finns säkert mer än ett sätt att lösa problemen på.

Att skapa ny tabeller låter om jag får uttrycka mig lite osnällt extremt dumt. Då innebär det med det att du har skrivit att du skall skapa en tabell som ”lever” endast under en session. Att skapa tabeller är kostsamt, dessutom bör du ju ta bort din tabeller någon gång även om köpet inte blir av. Det bästa du kan göra om du vill ha en databsdriven varukorg är att skapa en varukorgstabell med sessionsid , användarid, produktid, antal mm beroende på hur du vill utfomra din varukorg (tänker på rabatter mm). Andra varianter är att spara den typen av information är i sessionobjekt eller cookies om det är en webbapplikation


<b>Men det finns en del frågor att fundera över t.ex
* Hur kan man snabba upp sökningen av en viss typ av vara och hur skall den listas upp.</b>
Det beror helt och hållet på hur ditt system är uppbyggt. För att ge specifika svar runt ditt system måste vi veta lite mer om hur det är uppbyggt, annars kan det bara bli generella svar typ ”SP är bättre än SQL-kod skriven i applikationskoden” och då är det bättre att du surfar runt lite och läser själv om generella optimeringar.

<b>* Vad händer om kontakten med servern bryts. </b>
Menar du databasservern? Det beror helt och hållet på hur du bygger ditt system, men den kommer ju iaf att sluta svara på anrop... ;-) Sedan finns det massvis sätt att lösa det där, alltifrån att i applikationen slänga upp en messagebox där det står att kommunikationen är bruten och där man sedan ligger och pollar om servern kommer upp till att man låter applikationen krasha och stängas ner eftersom man har bedömt risken för liten för att ta hänsyn till och kostanden för att fixa det för hög.

<b>* Hur hög säkerhet behövs.</b>
Så hög som möjligt. SSL är ju det minsta, men är det ett webbsystem så skall ju tex inte http://system/GetOrder.asp?OrderID=123 kunna fungera utom för de som verkligen har behörighet att se den ordern, dvs en annan kund skall inte kunna skriva in en URL med ett godtyckligt orderid (eller kundid) och få information om ordern (eller en annan kund). SQL injection antar jag att jag inte behöver ta upp...

<b>* Hur kollar man upp om ett visst erbjudande faller in, t.ex "köp 3 betala för 2", 2 chips + 1 2 liters Coca Cola för 30:-</b>
Man sätter sig ner och specar upp exakt vilka typer av kombinationsrabatter man vill skall finnas i systemet. Sedan är det bara att implementera rabattobjekt som räknar igeom kvittot och kollar efter sina villkor, snurran för att kolla igenom alla rabattobjekt bör triggas vid varje händelse som påverkar ekonomisk infomation på varorna du säljer. Tänk även på att rabatter av typen "köp 3 betala för 2" skall kunna falla ut olika ofta på försäljningen, tex så vill en del att rabatten bara skall ges en gång även om det finns 6 varor av samma typ, andra vill att den skall falla ut två gånger. Tänk även på att allt räknande kan ta mycket tid så det gäller att optimera det så mycket det bara går, kanske inte så viktigt om man säljer kläder i ett kassasystem på H&M men otroligt viktigt i ett kassasystem på ICA eller KF.

Sedan har jag en fråga angående: ” Programmet är tänkt att användas som ett butikssystem via internet där flera butiker är kopplade till samma databas”. Jag hoppas innerligt att inte kassorna i butikerna skall gå mot den databasen när man säljer i dem. En kassa i en butik har som absolut minsta krav att kunna fortsätta att sälja även om nätverket går ner. Att en butik inte skall kunna sälja varor pga att nätverket går ner och kunderna står och stampar i butiken får bara inte inträffa, den dagen det mot förmodan skulle göra det skall man i sådana fall ha TYDLIGA avtal vad gäller den ekonomiska biten för det kommer att innebära förlorad inkomst för butikerna och badwill som de eventuellt kan ställa leverantören av butikssystem till svars för.

Några års utveckling av butikssystem lär en ungefär hur de bör fungera och vilka krav kunder (profesionella kunder iaf) ställer... ;-)

<b>* Jag hoppas innerligt att inte kassorna i butikerna skall gå mot den databasen när man säljer i dem. En kassa i en butik har som absolut minsta krav att kunna fortsätta att sälja även om nätverket går ner.
</b>
Jag har också funderat över det och kommer nog att använda en "lokal databas" med nödvändiga uppgifter för att med jämna mellanrum ( då det finns en connection ) skicka upp information till Centraldatabasen och hämta information om beställningar därifrån. Som sagt var ... mycket att tänka på innan start