Personel sabir kaydi yaparken OPERATIAN ABORTED hatasi veriyor.

Bu hatayi günceleme yaptiktan sonra karsilastiysan;

Bu konuda egitim aldigim dönemleri ve destek aldigim konusmalari hatirliyorum... Zor bir problemde DBUPDATE yapin olmazsa Cumleupdate30 tablosunu silip tekrar deneyin konusmalari çooook geçti.... O yüzden bu konunun sadece 4.0.8 setine has bir problem oldugunu düsünüyor... Netsis 4.0.10 da da meydana gelen o hatanin düzelecegine ve NETSIS den destek alinip zorda kalinca Cumleupdate30 silerek DBUPDATE çalistirin diyeceklerine inaniyorum...

Sayin KELEBEK bu konuda size katilmam sadece gördügüm 1-2 istekde NETSIS'in cevabini gördügümdendir... Ancak 4.0.10 seti çikinca NETSIS den bu konuda tekrar bilgi alip eski huyuma devam edecegim...

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.