[FONT="]Begin Transaction : [/FONT][FONT="]Transaction işleminin başladığını belirtir. [/FONT]
[FONT="]Commit Transaction : [/FONT][FONT="]Begin Transaction ile başlattığımız transaction işlemimizin sonuna işaret koyarak, bunların veritabanına yazılmasını sağlar. [/FONT]
[FONT="]Rollback : [/FONT][FONT="]İşlemde hata oluştuğunda rollback çalışır ve yapılan bütün işlemler geriye alınır. Yani veritabanına yansıtılmaz. [/FONT]
[FONT="] [/FONT]
[FONT="]Veritabanı oluşturma (CREATE DATABASE), veritabanı değiştirme (ALTER DATABASE), veritabanı silme (DROP DATABASE) gibi işlemleri transaction nın içinde belirtemezsiniz. Farklı çeşitlerde transaction yöntemleri vardır. Bunlardan ilki Explicit transactiondır. Begin Tran ile başlattığımız, gereken yerde rollback komutu ile yaptığımız işlemleri geri aldığımız ve Commit Tran ile işlemimizi sonlandırdığımız yöntem Explicit Transaction yöntemidir. Şimdiden bununla ilgili bir örnek yapalım. Örneğimiz yukarıda belirttiğimiz gibi bir banka veya para transferi yapan bir yerin veritabanı olduğunu varsayalım. KisiID, ad, soyad ve bakiye bilgilerinin tutulduğu bir tablo oluşturalım ve ismine ABank diyelim. Bu tablomuza bakiyesinde 35000 ytl olan Murat KOCA isimli bir müşteri kaydettik. Aynı kolonlardan oluşan bir tablo daha oluşturduk ve içine birkaç kişinin bilgisini girdik.
[/FONT] [FONT="]ABank tablomuzdaki Murat KOCA isimli şahısın hesabından 1000 ytl yi BBank tablomuzdaki Korhan KOCA isimli şahsın hesabına aktaralım. [/FONT]
[FONT="]
[/FONT] [FONT="] [/FONT]
[FONT="]update Abank set [/FONT]
[FONT="]bakiye=bakiye-1000 [/FONT]
[FONT="]where kisiID=1 [/FONT]
[FONT="]update Bbank set [/FONT]
[FONT="]bakiye=bakiye+1000 [/FONT]
[FONT="]where kisiID=2 [/FONT]
[FONT="]İşlemimizi gerçekleştirdik. Peki ya ilk update işlemimizden sonra herhangi bir nedenden dolayı ikinci update işlemimizi yapamadığımızı düşünürsek? Murat KOCA nın hesabındaki 1000 ytl eksildi ama nereye gittiği belli değil. Veya ikinci sordumuzdaki where kriterinde kisiIDyi 5 olarak gösterelim. İlk işlemden para eksilecek ama BBank tablomuzda kisiIDsi 5 olan bir kişi bulunmadığından ikici sorgumuz hata verecektir. İşte birbirleri ile ilişkili tablolarda bu tip hataları ortadan kaldırmak için Transactionı kullanırız. Şimdide yukardaki işlemi transaction ifadeleri arasında belirtelim. [/FONT]
[FONT="]begin tran [/FONT]
[FONT="]update Abank set [/FONT]
[FONT="]bakiye=bakiye-1000 [/FONT]
[FONT="]where kisiID=1 [/FONT]
[FONT="]if(select count(*) from BBank [/FONT]
[FONT="]where kisiID=5)=0 [/FONT]
[FONT="]begin [/FONT]
[FONT="]update Bbank set [/FONT]
[FONT="]bakiye=bakiye+1000 [/FONT]
[FONT="]where kisiID=5 [/FONT]
[FONT="]commit tran [/FONT]
[FONT="]end else begin [/FONT]
[FONT="]rollback tran [/FONT]
[FONT="]end [/FONT]
[FONT="]
[/FONT] [FONT="] [/FONT]
[FONT="]Yukarıdaki işlemde ABank tablosunda kisiID=1 olan şahısın hesabından 1000 ytl eksilttik ve BBank ta kisiID si 5 olan kişinin hesabına aktarmak istedik. Bunun için ilk önce BBank tablosunda kisiIDsi 5 olan bir kişinin olup olmadığının kontrolunu yaptık. Eğer böyle bir kişi varsa mevcut bakiyesinin üzerine 1000 ytl daha ilave ettik. Eğer yoksa rollback ile yapılan işlemleri geri aldık. Bizim tablomuzda kisiIDsi 5 olan bir şahıs olmadığından bu işlemi gerçekleştirdikten sonra son duruma bakacak olursak bir değişiklik olmayacaktır.[/FONT][FONT="][/FONT]
[FONT="]Yukarıdaki transaction işleminde kisiIDsi 5 olan yeri 2 olarak değiştirip tekrar çalıştırdığımızda, son durum bakiyeleri değişmiş olacaktır. [/FONT]
[FONT="]
[/FONT] [FONT="] [/FONT]
[FONT="]begin tran [/FONT]
[FONT="]update Abank set [/FONT]
[FONT="]bakiye=bakiye-1000 [/FONT]
[FONT="]where kisiID=1 [/FONT]
[FONT="]if(select count(*) from BBank [/FONT]
[FONT="]where kisiID=2)=1 [/FONT]
[FONT="]begin [/FONT]
[FONT="]update Bbank set [/FONT]
[FONT="]bakiye=bakiye+1000 [/FONT]
[FONT="]where kisiID=2 [/FONT]
[FONT="]commit tran [/FONT]
[FONT="]end else begin [/FONT]
[FONT="]rollback tran [/FONT]
[FONT="]end
[/FONT] [FONT="]Isolation : [/FONT][FONT="][/FONT]
[FONT="]İki veya daha fazla kullanıcı aynı anda sorgu çekmeye kalktığında, bir kullanıcı update veya insert işlemi gerçekleştirirken commit veya rollback görülene kadar diğer kişi(ler) gerçekleştirmek istedikleri sorgularına cevap alamazlar. Bu bölümde yapacağımız işlemle bir kullanıcı insert, update işlemleri yaparken; diğer kişi(ler) başka bir sorgu yazıp çalıştırabilecek. Bir transaction işlemi gerçekleştirilmeye başlandığında ya commit ile yada rollback ile bitebilir. Isolation lar eş zamanlarda çalışan transactionların aynı yerde işlem yapmasını engeller. Sql serverda 4 farklı isolation seviyesi vardır. Bunlardan ilki Read Uncommitteddır. Bu en düşük isolation seviyesidir ve bir transaction okuma yaparken, diğer transaction lara karşı hiç bir kilitleme yapmamasından dolayı diğer transaction işlemleri ile veriler değiştirilebilir. Read committed da ise bir okuma işlemi için erişen transaction işini bitirmeden, veriler değiştirilebilir. Ayrıca bu seviye SQL Server 2000 için default değerdir. Bir diğer seviye olan Repeatable Read te ise sadece commit edilmiş verileri okumak ile birlikte, veriler okunurken başka kullanıcının veriler üzerinde herhangi bir değişiklik yapmasını kısıtlar yani izin vermez. En yüksek seviyeye sahip olan Serilizable() da ise veri ekleme ve güncelleme işlemleri yapılırken yazdığımız transaction işlemi boyunca verileri diğer transaction işlemleri kullanamaz. İstediğimiz veritabanındaki İsolation ların seviyesini belirlemek ve kullanmak aşağıdaki gibidir. Örnek olarak Northwind veritabanımızdaki Employees tablosu kullanılmıştır. [/FONT]
[FONT="] [/FONT]
[FONT="] [/FONT]
[FONT="]set transaction isolation level [/FONT]
[FONT="]Read Committed [/FONT]
[FONT="]select * from employees [/FONT]
[FONT="]set transaction isolation level [/FONT]
[FONT="]read uncommitted [/FONT]
[FONT="]select * from employees [/FONT]
[FONT="]/* uncommitted dediğimiz zaman diğer [/FONT]
[FONT="]tarafta commit görünceye kadar olan [/FONT]
[FONT="]değişiklikleride getirdi */ [/FONT]
[FONT="]Başka bir örnek daha yapalım. Örneğin bir kullanıcı select sorgusu yaparken başka bir kullanıcı update, insert, delete işlemlerini yapamasın. [/FONT]
[FONT="]set transaction isolation level [/FONT]
[FONT="]repeatable read [/FONT]
[FONT="]begin tran [/FONT]
[FONT="]select * from employees [/FONT]
[FONT="]Başka bir kullanıcı update işlemi yapmaya kalktığında yukarıda yazmış olduğumuz kodu yazan kullanıcı commit işlemini yapana kadar işlemi gerçekleşmeyecektir. Repeatable readte update,delete yapamaz fakat insert işlemi yapabilir.s[/FONT]
[FONT="]Commit Transaction : [/FONT][FONT="]Begin Transaction ile başlattığımız transaction işlemimizin sonuna işaret koyarak, bunların veritabanına yazılmasını sağlar. [/FONT]
[FONT="]Rollback : [/FONT][FONT="]İşlemde hata oluştuğunda rollback çalışır ve yapılan bütün işlemler geriye alınır. Yani veritabanına yansıtılmaz. [/FONT]
[FONT="] [/FONT]
[FONT="]Veritabanı oluşturma (CREATE DATABASE), veritabanı değiştirme (ALTER DATABASE), veritabanı silme (DROP DATABASE) gibi işlemleri transaction nın içinde belirtemezsiniz. Farklı çeşitlerde transaction yöntemleri vardır. Bunlardan ilki Explicit transactiondır. Begin Tran ile başlattığımız, gereken yerde rollback komutu ile yaptığımız işlemleri geri aldığımız ve Commit Tran ile işlemimizi sonlandırdığımız yöntem Explicit Transaction yöntemidir. Şimdiden bununla ilgili bir örnek yapalım. Örneğimiz yukarıda belirttiğimiz gibi bir banka veya para transferi yapan bir yerin veritabanı olduğunu varsayalım. KisiID, ad, soyad ve bakiye bilgilerinin tutulduğu bir tablo oluşturalım ve ismine ABank diyelim. Bu tablomuza bakiyesinde 35000 ytl olan Murat KOCA isimli bir müşteri kaydettik. Aynı kolonlardan oluşan bir tablo daha oluşturduk ve içine birkaç kişinin bilgisini girdik.
[/FONT] [FONT="]ABank tablomuzdaki Murat KOCA isimli şahısın hesabından 1000 ytl yi BBank tablomuzdaki Korhan KOCA isimli şahsın hesabına aktaralım. [/FONT]
[FONT="]
[/FONT] [FONT="] [/FONT]
[FONT="]update Abank set [/FONT]
[FONT="]bakiye=bakiye-1000 [/FONT]
[FONT="]where kisiID=1 [/FONT]
[FONT="]update Bbank set [/FONT]
[FONT="]bakiye=bakiye+1000 [/FONT]
[FONT="]where kisiID=2 [/FONT]
[FONT="]İşlemimizi gerçekleştirdik. Peki ya ilk update işlemimizden sonra herhangi bir nedenden dolayı ikinci update işlemimizi yapamadığımızı düşünürsek? Murat KOCA nın hesabındaki 1000 ytl eksildi ama nereye gittiği belli değil. Veya ikinci sordumuzdaki where kriterinde kisiIDyi 5 olarak gösterelim. İlk işlemden para eksilecek ama BBank tablomuzda kisiIDsi 5 olan bir kişi bulunmadığından ikici sorgumuz hata verecektir. İşte birbirleri ile ilişkili tablolarda bu tip hataları ortadan kaldırmak için Transactionı kullanırız. Şimdide yukardaki işlemi transaction ifadeleri arasında belirtelim. [/FONT]
[FONT="]begin tran [/FONT]
[FONT="]update Abank set [/FONT]
[FONT="]bakiye=bakiye-1000 [/FONT]
[FONT="]where kisiID=1 [/FONT]
[FONT="]if(select count(*) from BBank [/FONT]
[FONT="]where kisiID=5)=0 [/FONT]
[FONT="]begin [/FONT]
[FONT="]update Bbank set [/FONT]
[FONT="]bakiye=bakiye+1000 [/FONT]
[FONT="]where kisiID=5 [/FONT]
[FONT="]commit tran [/FONT]
[FONT="]end else begin [/FONT]
[FONT="]rollback tran [/FONT]
[FONT="]end [/FONT]
[FONT="]
[/FONT] [FONT="] [/FONT]
[FONT="]Yukarıdaki işlemde ABank tablosunda kisiID=1 olan şahısın hesabından 1000 ytl eksilttik ve BBank ta kisiID si 5 olan kişinin hesabına aktarmak istedik. Bunun için ilk önce BBank tablosunda kisiIDsi 5 olan bir kişinin olup olmadığının kontrolunu yaptık. Eğer böyle bir kişi varsa mevcut bakiyesinin üzerine 1000 ytl daha ilave ettik. Eğer yoksa rollback ile yapılan işlemleri geri aldık. Bizim tablomuzda kisiIDsi 5 olan bir şahıs olmadığından bu işlemi gerçekleştirdikten sonra son duruma bakacak olursak bir değişiklik olmayacaktır.[/FONT][FONT="][/FONT]
[FONT="]Yukarıdaki transaction işleminde kisiIDsi 5 olan yeri 2 olarak değiştirip tekrar çalıştırdığımızda, son durum bakiyeleri değişmiş olacaktır. [/FONT]
[FONT="]
[/FONT] [FONT="] [/FONT]
[FONT="]begin tran [/FONT]
[FONT="]update Abank set [/FONT]
[FONT="]bakiye=bakiye-1000 [/FONT]
[FONT="]where kisiID=1 [/FONT]
[FONT="]if(select count(*) from BBank [/FONT]
[FONT="]where kisiID=2)=1 [/FONT]
[FONT="]begin [/FONT]
[FONT="]update Bbank set [/FONT]
[FONT="]bakiye=bakiye+1000 [/FONT]
[FONT="]where kisiID=2 [/FONT]
[FONT="]commit tran [/FONT]
[FONT="]end else begin [/FONT]
[FONT="]rollback tran [/FONT]
[FONT="]end
[/FONT] [FONT="]Isolation : [/FONT][FONT="][/FONT]
[FONT="]İki veya daha fazla kullanıcı aynı anda sorgu çekmeye kalktığında, bir kullanıcı update veya insert işlemi gerçekleştirirken commit veya rollback görülene kadar diğer kişi(ler) gerçekleştirmek istedikleri sorgularına cevap alamazlar. Bu bölümde yapacağımız işlemle bir kullanıcı insert, update işlemleri yaparken; diğer kişi(ler) başka bir sorgu yazıp çalıştırabilecek. Bir transaction işlemi gerçekleştirilmeye başlandığında ya commit ile yada rollback ile bitebilir. Isolation lar eş zamanlarda çalışan transactionların aynı yerde işlem yapmasını engeller. Sql serverda 4 farklı isolation seviyesi vardır. Bunlardan ilki Read Uncommitteddır. Bu en düşük isolation seviyesidir ve bir transaction okuma yaparken, diğer transaction lara karşı hiç bir kilitleme yapmamasından dolayı diğer transaction işlemleri ile veriler değiştirilebilir. Read committed da ise bir okuma işlemi için erişen transaction işini bitirmeden, veriler değiştirilebilir. Ayrıca bu seviye SQL Server 2000 için default değerdir. Bir diğer seviye olan Repeatable Read te ise sadece commit edilmiş verileri okumak ile birlikte, veriler okunurken başka kullanıcının veriler üzerinde herhangi bir değişiklik yapmasını kısıtlar yani izin vermez. En yüksek seviyeye sahip olan Serilizable() da ise veri ekleme ve güncelleme işlemleri yapılırken yazdığımız transaction işlemi boyunca verileri diğer transaction işlemleri kullanamaz. İstediğimiz veritabanındaki İsolation ların seviyesini belirlemek ve kullanmak aşağıdaki gibidir. Örnek olarak Northwind veritabanımızdaki Employees tablosu kullanılmıştır. [/FONT]
[FONT="] [/FONT]
[FONT="] [/FONT]
[FONT="]set transaction isolation level [/FONT]
[FONT="]Read Committed [/FONT]
[FONT="]select * from employees [/FONT]
[FONT="]set transaction isolation level [/FONT]
[FONT="]read uncommitted [/FONT]
[FONT="]select * from employees [/FONT]
[FONT="]/* uncommitted dediğimiz zaman diğer [/FONT]
[FONT="]tarafta commit görünceye kadar olan [/FONT]
[FONT="]değişiklikleride getirdi */ [/FONT]
[FONT="]Başka bir örnek daha yapalım. Örneğin bir kullanıcı select sorgusu yaparken başka bir kullanıcı update, insert, delete işlemlerini yapamasın. [/FONT]
[FONT="]set transaction isolation level [/FONT]
[FONT="]repeatable read [/FONT]
[FONT="]begin tran [/FONT]
[FONT="]select * from employees [/FONT]
[FONT="]Başka bir kullanıcı update işlemi yapmaya kalktığında yukarıda yazmış olduğumuz kodu yazan kullanıcı commit işlemini yapana kadar işlemi gerçekleşmeyecektir. Repeatable readte update,delete yapamaz fakat insert işlemi yapabilir.s[/FONT]
