Ето още една възможност, която открих в моята кандидатура.
Това би било, ако данните, върху които е изчислена първоначалната контролна сума, са наистина различни от изчислението на контролната сума преди актуализацията, поради дефект в дизайна на вашата заявка!
В моето приложение източникът за едно от актуализираните полета беше COALESCE(name_calced, name_preferred). В изходната таблица името на лицето вече може да бъде заредено в записа от външен процес и ние го запазваме в едно поле - name_calced. Но крайният потребител може да въведе предпочитано име, което искахме да запазим в полето name_preferred. Искахме първоначално да попълним показаното поле на табличен формуляр с възможност за актуализиране с name_calced, ако съществува такъв, или name_preferred, ако потребителят вече е предоставил предпочитано име. След това те биха могли да променят тази стойност и да я запишат обратно в базата данни.
Най-накрая открих, че действието Запазване извежда съобщение за грешка, ако name_calced не е null, но name_preferred е null. Разбрах, че първоначалната контролна сума е изчислена въз основа на name_calced, но контролната сума преди актуализацията е базирана на name_preferred, така че приложението реши, че някой е променил стойността на заден план и показа съобщението за грешка.
Това, което не разбирам е как този проблем не се е появил през последните 3 години, когато приложението работи в производствена среда!
Моето решение е да направя полето източник само на name_preferred, което веднага реши този проблем. Също така мисля, че процесът на задния край също ще бъде променен, за да попълни предварително това поле на таблицата от name_calced, така че потребителят винаги да вижда базовата стойност, ако има такава.
person
StewS2
schedule
10.07.2016
