ORA-08177: can't serialize access for this transaction (ORA-08177: bu işlem için erişim serileştirilemiyor) hatası

Bu hatayı, insert işlemi yaptığım bir prosedürü serileştirmeye çalıştığım zaman aldım. Amacım, prosedürün farklı sessionlarda birbirini ezmeden çalıştırılabilmesiydi. Bunun için prosedürün tanım kısmına Serialization tanımını (SET TRANSACTION ISOLATION LEVEL SERIALIZABLE)
ekledim. Bu eklemeden sonra, prosedürü tek sessionda çalıştırsam bile hata vermeye başladı. Kısa bir aramadan sonra, ORACLE'da tabloların varsayılan olarak "Tablo seviyesinde" kilitlendiğini öğrendim. Bunu satır seviyesi olarak ayarlamak için, tabloyu oluştururken ROWDEPENDENCIES keywordunu eklemek gerekiyor. Örnek Table Create ve SP scripti aşağıdaki gibidir:



CREATE TABLE ALIBUDAK.TABLO_TEST
(
     SID      NUMBER,
     NAME VARCHAR2(20)
)
ROWDEPENDENCIES
---------------------------------------------------------------------------------------------------------

CREATE OR REPLACE PROCEDURE SP_TEST
IS

    PRAGMA AUTONOMOUS_TRANSACTION;

BEGIN
       
    SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
   
    DELETE FROM ALIBUDAK.TABLO_TEST;
    INSERT INTO ALIBUDAK.TABLO_TEST
    VALUES (1 ,'Ali');
       
    COMMIT;
END;

must declare the scalar @... problemi

Gridview datasource'unun DELETE COMMAND'ını yazınca karşıma bu problem çıktı. Problemin sebebi, Delete komutunda yazdığım;

 DELETE FROM tablo WHERE id=@id

kısmındaki @id yi parametre olarak görememesi. Çözüm olarak gridview özelliklerinden "DataKeyNames" özelliğine değer olarak "id" yazdım.  DataKeyNames'in değeri, tablodaki birincil anahtardır.

windows mavi ekran problemlerinden 0×0000007b

STOP : 0×0000007b kodu ile karşınıza mavi ekran gelip bilgisayar sürekli yeniden başlayıp duruyorsa, BIOS'tan HDD'nizin sata denetiminin pasif (disabled) durumda olup olmadığı kontrol edilmeli.

Invalid postback or callback argument.

GridView Update işlemini yapmaya çalışırken karşıma çıkan hata:
  
Invalid postback or callback argument.  Event validation is enabled using in configuration or <%@ Page EnableEventValidation="true" %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.
Çözüm için Page_Load() içine isPostBack şartının koyulması lazım.

Page_Load() {
    if(!isPostBack){
          //PAGE_LOAD İÇERİĞİNİ BU KOŞULUN ALTINA YAZMAK GEREKİYOR
    }
}

Oracle WM_CONCAT Fonksiyonu

GRUPLAMAYI TEK SATIRDA NASIL YAPABİLİRİM?
Aynı kritere sahip değerleri tek satırda gruplamak için wm_concat fonksiyonunu kulanabiliriz.
Örnek üzerinden gidiyorum:
Tablo adı: CALISAN
Sütunlar: Maaş, İsim

MAAŞ	İSİM
1000	Ali
1000	Veli

Şimdi bu tabloya normal select çektiğimiz zaman karşımıza gelecek tablo 2 satırdan oluşuyor. İstediğimiz ise, tek satırda şunun gibi bir sonuç gelmesi:
MAAŞ      İSİM
1000       Ali,Veli
Bunun için yazılacak sorgu şöyle olmalıdır:

SELECT  MAAŞ, vm_concat(İSİM) 
FROM CALISAN
GROUP BY MAAS

TRUCATE ve DELETE farkı

Birçok meraklı developer'ın, aralarındaki farkı en az bir kez sorguladığı bir mevzudur bu. DELETE FROM varken TRUNCATE nedir ki? Aralarındaki en büyük fark şu: DELETE bir DML (Data Manipulation : Veri İşleme) komutudur. DML komutları, "commit" edilmeden kabul görmeyip, rollback ile geri alınabilirler, haliyle rollback segmentlerini kullanırlar. TRUNCATE ise bir DDL (Data Definition : Veri Tanımlama) komutudur. DDL komutları commit veya rollback ile değiştirilemezler. İşin özüne gelirsek: Bir tablo düşünün, 10 milyon satır ve 150 sütundan oluşan bir devanası. Bu tabloyu boşaltmak isterseniz, ve bunu DELETE ile yaparsanız, tüm veri rollback segmentlere yazılır, ki bu performans ve hız açısından hiç de istemediğimiz sonuçları beraberinde getirir. Bu yüzden tablonun tamamının boşaltılması istenen durumlarda TRUNCATE'in kullanılması önemlidir.

Oracle Trigger

Trigger'lar bir nevi programlamadaki Event Listener'lar gibidir. Örnek verelim: TABLO1 adında bir tablomuz var ve bu tablonun satırları üzerinde yapılan değişiklikleri (Update işlemlerini) loglamak istiyoruz. Bunun için bir Update trigger yazıp değişen veriyi, eski halini, hangi tarihte değiştiğini kendi belirlediğimiz bir tabloya insert edebiliriz.

Tablomuzu oluşturalım:
CREATE TABLE TABLO1
(user_id int, department_code int)
-------

Log tablomuzu oluşturalım
CREATE TABLE AUDIT_TABLO1
(user_id int, old_department_code int, new_department_code int, entry_date date)
-------
Tablolarımızı oluşturduktan sonra gelelim Trigger'a:
CREATE  TRIGGER  trg_tablo1
AFTER UPDATE
ON Tablo1
FOR EACH ROW
INSERT INTO AUDIT_TABLO1
(user_id, old_department_code, new_department_code, entry_date)
VALUES
(:new.user_id, :old.department_code, :new.department_code, sysdate)

Bu trigger ile log tablomuzda hem önceki hem update işleminden sonraki departman kodunu tutabiliriz. Bu şekilde hatalı update edilmiş kayıtların geri dönüşü için kolay bi fırsat yaratmış oluruz. ;)