Under not jet know conditions *) UnifAce will crash in the middle of nowhere.
With the help of a debugger, I cound find the exact point in the executable where UnifAce crash.

This is due to a table of 16 entries (id and value) where the last one is a null entry.
UnifAce is looking for a ID, which should not null but actual is null.
So the last entry will found and the value there is also null.
Next step UnifAce use this as an address ==> crash

So how to report such error where the conditions not clear.
Build a testset is time consuming, as there is not a real clue *), when this occures


*) Something with right mouse/ start of a menu

    CommentAdd your comment...

    1 answer


      Hi Ingo,

      Just a brainstorming here...

      First step:
      - Is that table of 16 entries under your control (like a relationship table)? Then you could fix it by yourself.
      - Is that table NOT under your control? You have one choice only: communicate to ULab.

      Sometimes is difficult, very difficult, to dig in our complex, sometimes very complex, applications to isolate and build a testset. In few cases (about 10% in my experience...) while building the testset and navigating up the software stack I've found the REAL problem; in all remaining cases a strong cooperation with ULab is mandatory.

      As Uniface users we expect always something more from ULab: more attention, more focus, quicker response times...we would like to tell them in a sentence "I've made an hell of work to put together this testset, now my problem is really your problem!"...but cooperation means to continue to work on both sides.

      As a technician I hate when, while digging an important issue, it becomes clear ULab resources are fully booked and it is asked to raise priority at business level. Business level is always already impacted on Uniface customer side when we, from the field, need to go to A'dam to solve an issue...sometimes procedures being put together on paper are too perfect: being too strict, sticking too much, to those procedures it becomes really an exaggeration.

      The better choice is to try to communicate always properly, to let ULab to understand they are the only solution to have a proper fix; oh yes, a fix must be a proper fix: cannot be "you should change something in your application because we never imagined you can use this feature in the way we know now you are using..." (It happened!).

      But to get to the conclusion of this post: we need to work together with some empathy on both sides.

      Good luck!


      BTW: I've decided to write this post because this week we closed with a collegue of mine and Nico from ULab an issue being opened for more than 15 month; the final fix will made its path into Uniface product soon.

        CommentAdd your comment...