[SQL, C#] dve proceduri z transkacijo

Ko opravi prva procedura ne sme narediti komita na bazi. Komit naredi šele naslednja, če pa ne naredi pravilno, pa naredi rollback. Vsaj tako lahko narediš na DB2 bazi.

Zakaj pa vse skupaj ne narediš kot eno proceduro?

Glavna težava je v tem, da imam za Nakup en komit, za KupljeneIzdelke pa več komitov (ker je List).. torej rollback bi moral biti za vse KupljeneIzdelke ter za en Nakup Če bi se sam List ali Array dal nekako prenest v proceduro bi bilo idealno ...

baza je pa MSSQL


edit:

Rešil problem, sem ustvaril svoj User-Defined Table Type (v bistvu nek tip tabele IzdelekVKosarici) tako lahko v proceduro kot parameter dobim cel DataTable.

Transakcijo mora upravljat tvoja poslovna logika in ne stored procedura.

Priporocam ti, da ne uporabljas stored procedur (ne bo delalo nic pocasneje) in ce jih ze v zacetku ne bi uporabil, do tega problema sploh ne bi prisel.

In pol delas nekaj takega:

class Nekaj
{
public void Shrani(IList<Nakup> nakupi)
{
try
{
//Begin transaction
foreach(Nakup n in nakupi)
{
//Validacija (ob napaki throw Exception)
//Shrani
}
//Commit
}
catch(Exception ex)
{
//Rollback
}
}
}

Ena stvar je, da so nove baze optimizirane tako za adhoc sql stavke kot tudi za stored procedure in naceloma v performanci ni razlik.

Druga je pa ta, ko bos spremenil podatkovni model, bos po vsej verjetnosti spremenil tudi stored proceduro, in ker bos spremenil stored proceduro bos spremenil se program. Se pravi bo sprememba na treh mestih in ne samo na dveh. To ti poveca moznost napake.

Tretja stvar je, da ko enkrat zacnes pisati stored procedure kaj kmalu vanje zacnes tlacit tudi T-SQL (if stavki in podobno) in se ti poslovna logika razprsi na dva dela. Nekaj bos imel v stored procedurah, nekaj v programu.

Cetrta. Stored procedure je tezje debagirat, se posebej ce upostevas celotno poslovno logiko (ki je sedaj na dveh mestih).

Peta. Stored procedure so se spomnili v starih casih client/server sistemov, kjer je zaradi posodabljanja programa bilo treba posodobiti vse cliente (ki jih je bilo veliko) in je bilo smiselno del kode prestaviti na streznik. To je bil takrat pac SQL streznik in so izumili TSQL (PL/SQL in podobne zadeve). Amapk ta jezik je za pisanje poslovnih pravil zelo okoren, zato so kmalu presli na 3 nivojsko arhitekturo in so na srednjem nivoju zaceli uporabljati programske jezike tretje generacije (c++, c#, java...), ki so pa za implementacijo poslovne logike bistveno bolj fleksibilni. No in potem so se pocasi vse stvari zacele seliti na srednji nivo od security-ja pa tja do ne vem cesa se.

Sestic. Poglej kam se razvoj programske opreme odvija. Popularnost ORM-jev (ki sami generirajo sql stavke -- in ne klicejo stored procedur -- razen ce explicitno ne zahtevas), vizualnega programiranje poslovnih pravil (WWF) in vsega boga...Tako da je podatkovna baza ostala samo za to kar je namenjena - sistematicno shranjevanje podatkov.

Sedmic. V velikih sistemih se stremi k temu, da je podatkovni streznik cim manj obremenjen - se pravi naj samo shranjuje/bere podatke in ne dela nic drugega.

Osmic. Store procedure zavzamejo pomnilnik podatkovnemu strezniku in ga tako posredno obremenjujejo.

Pa se kaj bi se naslo.
Vec info v moji diplomi, ki se je dotaknila del tega tvojega problema:
http://de.scientificcommons.org/38083648

Drugače pa:

using System.Data;
using System.Data.Common;
using System.Transactions;
.
.
.
using (TransactionScope scope = new TransactionScope())
{
using (DbConnectionScope db = new DbConnectionScope())
{
// Tvoja koda, kjer kličeš poljubno št. procedur na bazi
}

scope.Complete();
}

Se strinjam z darkolordom. Vse je odvisno od namenske situacije. Obstaja tudi logika razvoja, ki pravi, da čim več podatkovne logike prenesti na podatkovni strežnik... kot pravim, vse je odvisno od situacije.