Erwin Relationlar üzerindeki ri action bölümü hakkında

[delphist]

S.a. Erwinde tablodan tabloya ve ilişkiden ilişkiye bu bölümün ayarları değişmekte tabi...Parent insert, Parent Update ve Parent Delete bölümleri ok...Parent update konusunda bir problemim yok fakat...Şu Child bölümündekileri tam kavrayamadım tam etkileri nedir no action de ne oluyor restrict de ne oluyor o bölümde mümkünse açıklarsanız arkadaşlar sevinirim. Teşekkürler

[fahrettin]

mesala fatura ve o faturanın detayındaki urunleri dusunelim....

child delete sirasinda yani bir urunu silmek istediginizde no action yani silsin yapacak bir sey yok...

child insert te yani urunler girilirken urun tablosundaki fatura no alanınin degeri fatura tablosunda olmalı. yani urun tablosuna fatura no 5 olan bir urun ekliyorsanız 5 numaralı fatura olmalıdır mutlaka eger yoksa restrict yani bu inserte izin verme. Ayni sekilde bir urunun fatura numarasını degistirirken yeni fatura numarasına ait bir fatura kaydı da mutlaka olmalı ve yoksa restrict yani musade edilmez....

Gerçi diyeceksiniz ki delphi programında fatura altına urun eklerken zaten master detay ilişkiden dolayı urun tablosuna fatura no alanı aynen masterdaki degeri alır. Farklı deger girme ihtimali yoktur.

Fakat işin aslı oyle degil... Veritabanına ayrı bir kanaldan mudahale edildiğinde bu tur referantial integrity kuralları verinin butunlugunu korumak icin gerekeni yapacaklardır....

[rsimsek]

Hocam burada önemli olduğunu düşündüğüm tutarlılıkla ilgili hatta hataya sebep olabilecek bir durum. Senaryo olarak iki kullanıcının fatura kestiğini düşünelim. Her biri farklı transaction içinde kayıta başladı ve fatura master tablosunda bir kayıt insert edip sıradaki fatura numarasını aldı. Fakat bu transection commit edilmediğinden sadece o kişi bu numarayı görebilir ve fatura detayını girebilir. Hatta işlemi yarıda kesip kayıttan vazgeçebilir. Rollback ile işleme başladığı noktaya dönebilir. Buraya kadar normal. Fakat aynı dakikalarda diğer kullanıcı da fatura girişi yapmakta ve aynı fatura numarasını almakta. İlk post/commit edende bir sorun yaşanmazken diğeri aynı numaralı ikinci bir fatura kayıtı yapmaya çalıştığından unique key hatası alacaktır Bu durumda bu hatayı aldığında veritabanından yeni bir fatura numarası çekip master tablo ve detail tablodaki ilgili alanları tekrar güncellemesi gerekmektedir. Bunun kullanıcıyı fazla rahatsız etmeden yapılması gerekiyor diye düşünüyorum, bilmem yanılıyor muyum

[mussimsek]

seminerin görüntüsü yayınlandı, onu ve Power Designer seminerini seyredin faydası olacaktır.

Referential Integrity bence bu programları kullanmanın en büyük faydası. Zamanında saçma sapan verilerden az çekmedim

Recep abi bu tarz fatura işlemi gibi işlemlerde Transaction yapmak en iyisi, transactionı başlatıp en sonunda ya hepsini yazacaksın, ya da hepsini iptal edeceksin. Fatura girildi ama ürün detayları girilmedi gibi bir durum olmaması lazım. İzlediğin yöntem bana pek doğru gelmedi.

Kolay gelsin.

[rsimsek]

Mustafa tabi ki olay/kayıt transaction içinde oluyor, fakat generator den ardışık sıra numarası olayını nasıl halledeceksin? Yada veritabanı transaction kapatılmasa bile bundan haberdar oluyor mu ki, olması mantıksız. Zaten ardışık alsa bile kullanıcı kayıttan vazgeçerse (diğer kullanıcı bir sonraki numarayı aldığından) o numara boş kalır. O yüzden Master-Detail kayıtı için sanal bir numara verdirip, kaydet/commit dendiğinde kayıtı o şekilde kaydedip tekrar transaction u açıp veritabanından o anki sıra numarası ile gerçek fatura numarası alıp, kaydedilen sanal yada geçici fatura numaralı kayıtı update etmek gerekir Bunun için negatif (-) değerlerle başlayan random bir sayı verilebilir ki diğer kullanıcılar da aynı yöntemi uygulayacak çakışma olmamalı. Yoksa aynı numara olursa problem devam eder...

[fahrettin]

Recep abi bu tur durumlar teorik olarak olmamalı. yani yeni fatura numarası alımı sırasında mutlaka artan numaralar verilirse bir kisi bir fatura numarası aldıktan sonra ikinci kisi aynı anda bila tusa bassa aradaki salise farklarından doalyı farklı transactionlar olarak farklı numaraları alabilemeliler....

[rsimsek]

Problem zaten farklı numaralar almalarında değil, önce numara alan kişinin çeşitli sebeplere kayıttan vazgeçmesi. Mesela faturayı tekrar girmeye kalktığında bir önceki aynı numarayı alamıyacak ve o numara boş kalacak. Bunu muhasebe yönünden anlatmak zor olabilir, eğer faturaların ardışık olarak numaralanması zorunluluğu yoksa başka

[mussimsek]

abi bu tarz bir durumda generatörü elle düzeltme imkanı verilebilir. Zaten bu generatör her hangi bir alana bağlı olmayacağından sıkıntı olmaz.

Mesela FATURA tablosundaki FATURA_NO alanını IBDataset'te Generatörü atama abi, yani autoinc gibi çalışmasın. Manuel çalıştırıp, değeri al, onu ata. Generatör'lerin AutoInc'ten farkı burda ortaya çıkıyor zaten.

Kolay gelsin.

[rsimsek]

O zaman da her fatura kesiminde arada boşluk var mı diye kontrol etmek işi uzatmaz mı? Önerdiğim sanal yöntem daha mantıklı gibi, bence

[fahrettin]

Aslında Primary Key olan FATURA_NO yu fiili faturadaki no ile aynı kullanmak yerine arka planda tekilliği temin için kullanmak daha makul bence.... Boylece FATURA_NO ların ardışık olup olmamasının hiç bir önemi yok... Hatta kullanıcı gormeyebilir bile.... Gerçek fatura no alanına ise before post olayında veya trigger tarafında bir değer ataması yapılabilri ki bu da maksimumun bir fazlası olur..... trigger kodu farklı iki satır icin aynı anda hic bir zaman calismayacagi icin once post oden numarayı kapar...

[rsimsek]

Evet, hocam ben faturaya takınca numaranın elle girilme olayını es geçmişim O alan sadece unique id alanıydı

[onaydin]

child delete sirasinda yani bir urunu silmek istediginizde no action yani silsin yapacak bir sey yok...

Şimdi galiba kelimeler karışmış No Action ile Restrict aynı işlemi yapıyor
No action yani silmesin.
Orda kastedilen 'none' oluyor
Kodlarına bakacak olursak

No Action;

Kod: Tümünü seç

CREATE TRIGGER tD_KART FOR KART AFTER DELETE AS

DECLARE VARIABLE numrows INTEGER;
BEGIN
       
    select count(*) from MUSTERI
      where
       
        OLD.MUSTERI_NO = MUSTERI.MUSTERI_NO into numrows;
    IF (numrows > 0) THEN
    BEGIN
      EXCEPTION ERWIN_CHILD_DELETE_NOACTION;
    END
END !!

Restrict;

Kod: Tümünü seç

CREATE TRIGGER tD_KART FOR KART AFTER DELETE AS

DECLARE VARIABLE numrows INTEGER;
BEGIN
  select count(*) from MUSTERI
      where
     OLD.MUSTERI_NO = MUSTERI.MUSTERI_NO into numrows;
    IF (numrows > 0) THEN
    BEGIN
      EXCEPTION ERWIN_CHILD_DELETE_RESTRICT;
    END

END !!

[rsimsek]

Bu konuda kafama takılan olay sanırım seminerdeki programdan kaynaklanıyor. Programı tekrar incelediğimde söyle bir sonuca vardım; Generator ile alınan Fatura_No transation içinde alınmayıp kalıcı olarak veritabanından alınmakta ve generator u bir artırmakta, dolaysıyla da kayıt iptal edildiğinde CommitRetaining/RollBackRetaining her ne yapılırsa yapılsın bir sonraki kayıt eskisinden değilde boşluk bırakılıp verilmekte bu da fatura numarası gibi önemli alanlar için kullanım imkanı vermemektedir Fatura numarası elle girilmeli Sadece unique lik sağlamak ve Master-Detail ilişkilerde kullanılmak üzere ID değerleri vermek için uygun bir kullanım.

Kayıtın iptal durumunda Generator kontrol edilere bir önceki değere set edilebilir. Çünkü bir sonraki değer diğer bir kullanıcı tarafından alınmış olduğundan bu da fazla sağlıklı olmayacak.
Aslında IBDataSet in GeneretorField ında bakılırsa değişik seçenekler de mevcuttur. Fakat Master-Detail ilişkide kullanılabileceğini sanmıyorum.

[Salih]

child delete sirasinda yani bir urunu silmek istediginizde no action yani silsin yapacak bir sey yok...

Şimdi galiba kelimeler karışmış No Action ile Restrict aynı işlemi yapıyor
No action yani silmesin.
Orda kastedilen 'none' oluyor
Kodlarına bakacak olursak

No Action;

Kod: Tümünü seç

CREATE TRIGGER tD_KART FOR KART AFTER DELETE AS

DECLARE VARIABLE numrows INTEGER;
BEGIN
       
    select count(*) from MUSTERI
      where
       
        OLD.MUSTERI_NO = MUSTERI.MUSTERI_NO into numrows;
    IF (numrows > 0) THEN
    BEGIN
      EXCEPTION ERWIN_CHILD_DELETE_NOACTION;
    END
END !!

Hocam NOACTION durumunda bu trigger a da ihtiyaç yok zaten, "kontrol etmene gerek yok, sil gitsin" diyorsan trigger da ne işlemi yapacaksın ki ?

[onaydin]

Hocam NOACTION durumunda bu trigger a da ihtiyaç yok zaten, "kontrol etmene gerek yok, sil gitsin" diyorsan trigger da ne işlemi yapacaksın ki ?

Nasıl yok ?

Kontrol etmene gerek yok sil gitsin dediğinizde burda bu durumda cocuk tablodaki kayıtların durumunun ne olacağı söz konusudur tamam parent ı sil gitsin child dekiler ne olacak bu durumda onlara bir kural uygulamanız lazım
ya cascade edersiniz ya set default dersiniz ya da set null dersiniz
ama bunların her durumunda bir kontrol illaki vardır.
Sadece parent ın insert ve child ın delete olayında bir kontrol yapmanıza gerek yok diğerlerinde mecburen bu olaylardan birini tercih etmeniz lazım.