PERSONEL KAYDI

Bende herkese tesekkür ederim.

Kelebek nick li üyemize katiliyorum ve aktarmis oldugu bilgiler için kendisine tesekkür ederim. Bundan sonra bu tür hassas konularda bizleri büyük hatalardan kurtaracagi kanatindeyim.

dbupdate te yasadigimiz sorunlarin aslinda mantikli açiklamalari var.

1.si field not found hatasi ve bu fieldlari manuel yaratmak zorunda kalmamiz.

Diyelimki updateteki 25000. cümle x kolonunu yaratan bir cümle

dbupdate çalistirdik ve bu cümle kolon create olsada olmasada çalistigini belirten OK durumunu aldi.

Bir sonraki sette 27.000. cümleye x kolonuna bagli yeni bir kolon yada index create ediliyor.

25000 Ok oldugu için tekrar çalismaz ve oto olarak buna bagli 27000 de hata yer.Ve su klasik index create hatalari karsimiza çikar.

Buna elle müdahale edip kolonu manuel yaratir ve dbupdate çalistirabiliriz yada cumleupdate30 ‘u where close ile sileriz dbupdate çalistiririz. 

2.si Birbirine bagli 2 kolon ayni anda dbupdate  e alindi ise 25000-25001 gibi ve siralari yanlis ise(ki bu sik yasanir)yani önce bagli kolon cümlesi sonra ana kolon create cümlesi ise ilk nesne ilk update te olusmaz fakat 2.si olusur.2. defa update çalistirdiginizda ise ilk kolonda yaratilmis olur. 

Asgari azami stoklari detayli tutmak adina stsabitten alinip ayri bir tabloya atildigi(caristok) bir istek vardi.cumleupdate30 silip dbupate yaptigimizda bu istek tekrar çalisip stsabitteki bos kolonlari caristok tablosuna atiyordu.Suanda kadar bu gibi veri kaybi yaratan bir istek daha olmadi fakat bunu takip etmek mümkün degil.bunuda nasil bulduk birçok müsterinin planlama kayitlari gidince tespit edildi.

Bu nedenledirki bugün bu kisitla sildigimiz tablo yarin baska kisitlara ihtiyaç duyabilirJÇok uzadi bu konu biliyorum ama amacim gerçekten iddialasmak degil.Yakin tarihte yeni tablolar olusabilir ve kayitlar ayrilabilir.O zaman sorunlarimiz tekerrür edebilir.En azindan silmeden önce netsis çagri merkezinden yapisal degisiklik olup olmadigini ögrenmeliyiz.

Bu veri gidisleri tek setlik degil maalesef..Yeni tablolara veri bölen istekler oldukça ve Bu tablo bu yapida kaldikça bu tip veri kayiplari üstüne eklenerek artacak diyorum ve sayin sa ya tesekkürlerimi iletiyorum.

 

Siz bilirsiniz arkadaslar.Ben sadece bildigimi aktardim.Seçim sizin

peki cok sayin ve muhterem uyemiz kelebelek.

Düzenleyen (sa) - 25 Ekim 2007 Saat 12:58

Eger bu konuda eminseniz ... Benim bilmedigim yada yanlis bilgilendigim birsey olabilir diyor... Bu konuda KELEBEK arkadasima katiliyorum...

dbupdate mevcut kayitlara zarar vermez ama cumleupdate i sildiginizde maalesef verir.Yinede siz bilirsiniz tabiiki.Ben sadece çok emin oldugum bi konuda bilgi vermek istedim.

Personelde personel giris-çikis isleminde tablo read edilemiyor seklinde hata veryor. 4,0,6 da bu hata yoktu.
Müsterim kendisi online güncelleme yapmis simdi bu hatayi veriyor. Netsis ile görüsmede bu tür bir hata olabilecegini söyledigi için bende fazla üstüne düsmedim.

kelebek Yazdı: Arkadaslar karismak gibi olmasin ama Cumleupdate30 u silmek çok tehlikeli bir is.Sonuna bir where close koyarsaniz (istekno ile ilgili)sorun yok fakat direk sildiginizde istekle gelen yenilik kayitlari gidiyor.Örnegin;caristok tablosu malum sonradan oldu önceden casabitteydi  siz cumleupdate silip dbupdate çalistirdiginizda planlama kayitlarinin tamami gider.Yani set güncelledik planlama kayitlarimiz gittinin sebebi cumleupdate30 un silinip dbupdate çalistirilmasidir.

Arkadaslar karismak gibi olmasin ama Cumleupdate30 u silmek çok tehlikeli bir is.Sonuna bir where close koyarsaniz (istekno ile ilgili)sorun yok fakat direk sildiginizde istekle gelen yenilik kayitlari gidiyor.Örnegin;caristok tablosu malum sonradan oldu önceden casabitteydi  siz cumleupdate silip dbupdate çalistirdiginizda planlama kayitlarinin tamami gider.Yani set güncelledik planlama kayitlarimiz gittinin sebebi cumleupdate30 un silinip dbupdate çalistirilmasidir.