Ghid practic de postare de erori

Ghid pt. raportarea erorilor din WinMENTOR.
-valabil atat pe forum cat si pe mailurile trimise direct la testare-

Pentru o buna depanare, ințelegere și incercare de reproducere a erorii de către tester-ii WinMENTOR, este foarte important sa se precizeze exact ultimul eveniment efectuat inainte de apariția mesajului de eroare, și dacă se poate ce NU s-a intamplat dupa mesaj. Astfel se va putea mai ușor identifica atat codul cat și tabelele care ar putea cauza o astfel de eroare.


Ex. Ma aflu pe macheta de iesiri.

Ca eveniment declanșator, apăs butonul client pentru deschidere view parteneri, aleg partener din view, apare un mesaj de eroare (EAccesViolation...), după ce am inchis mesajul de eroare sunt in macheta de ieșiri, dar știu ca trebuia sa imi deschidă view-ul de comenzi de la clienți.

Astfel se va ști ce cod a aruncat acea eroare, și urmărind codul, știu că e vorba de tablele FNESOSIT, COMAND* si incă 2-3 table, din cele peste 150 de table care se deschid odată cu macheta.

Ce prezintă interes din mesajele de eroare:
Erorile Mentor sunt de 3 feluri:
a) Erorile prinse si tratate de WinMENTOR, și apar in mesaj cu palma roșie; Este suficient textul mesajului.
b) Mesajele Windows de forma "Eroare ... <denumire funcție>". Acestea sunt prinse de WinMENTOR, dar nu sunt tratate, pentru ca sunt erori fatale ce nu trebuie sa se intample, nu trebuie ignorate, orice altă eroare ce apare după are la baza această eroare și pentru a merge mai departe trebuie reparată cauza. Ele au scopul doar de a fi localizata mai ușor problema, in lipsa lor, eroarea s-ar fi propagat in cascada pana la inchiderea forțată a aplicației. Este suficient textul mesajului.
c) Mesaje de excepții de genul EAccessViolation in module at address. Din tot mesajul acesta, singurul lucru de precizat este tipul erorii E<nume-eroare>, eventual dacă e precizat vreun camp sau cale fișier.

a) si b) sunt mai usor de identificat, erorile de tip c) daca nu sunt explicite, mult mai greu.

Un simplu print screen cu mesajul de eroare, fără explicații, de cele mai multe ori nu spune nimic, pentru că nu arată ce a declanșat eroarea.

Tips
Crearea unui fisier cu denumirea 'debug.pas' la nivel de executabil va rula mentorul in modul depanare. Acest fisier se va umple cu evenimente, ce ar putea ajuta la localizarea unei erori de tip c) care duce la inchiderea fortata a mentorului.

Erori de genul Corupt Table Index Header daca au aparut dupa socuri de curent, cel mai bine se rezolva cu restaurare din ultima salvare, pentru ca daca pe o tabla, exista mari sanse sa mai dea pe 300 table, fiind total si irecuperabil distruse. Daca dati F3 din Total Commander pe el, veti vedea ca nu mai contine nimic, doar spatiu gol, nu doar headerul, deci nici verificare structuri, nici orice alta aplicatie de reparat table nu va reusi sa mai faca ceva daca nu e nimic. Riscati doar sa pierdeti 3-4 ore luind fiecare tabla la rand si tot inlocuind-o si obtinand o baza de date incoerenta cu date pierdute.

Ce e de facut inainte de a posta o eroare.

O eroare ce se poate reproduce efectuind acelasi set de pasi ofera un tipar si astfel va putea fi identificata. Recomandam insa rularea acelor pasi si pe alta baza de date (pentru a izola si directorul data), sau cel putin pe alta firma.
Daca nu poate fi reprodusa pe alta firma, probabil e ceva specific bazei de date si va fi nevoie si de trimiterea unei baze spre testare, verificare acord GDPR.
Fara acest test suplimentar, nu facem decat sa pierdem timpul in comunicare in loc de executie, pentru ca oricum se va ajunge la exact aceeasi situatie, adica cerere de conectare remote/baza de date.
E posibil chiar si cu baza de date sa nu putem reproduce eroarea, ceea ce inseamna intrarea remote pe calculatorul unde se reproduce eroarea. (fisiere la nivel de exe, directorul data, antivirus, setari securitate windows, bde corupt...)

Ce trebuie postat.

1. Mentionarea versiunii de mentor/declaratii cu care se lucreaza. E posibil sa stim deja de eroare si sa fie rezolvata pe versiuni ulterioare.

2. Mentionarea pasilor facuti ce pot fi reprodusi si genereaza eroarea, pentru a sti exact ce sa facem.
Daca eroarea nu poate fi reprodusa tot timpul, va fi greu de prins, dar ultimii pasi pana sa se genereze eroarea tot trebuie descrisi, si probabil vor trebui detalii despre modul de lucru cu baza de date (exista importuri din alte aplicatii, lucru simultan pe mai multe luni, etc.) Aici probabil cel mai bine este o discutie telefonica.
Precum am zis, mesajele de eroare prezinta interes prin continutul lor, suplimentat de descrierea unde si cum s-a intamplat. O poza statica, eventual numai a mesajului este doar o pierdere de timp, pentru ca nu spune decat mesajul. De exemplu sunt mesaje de eroare ce apar dupa inchiderea unei machete, deci ea nici macar nu mai apare in fotografie.

Daca nu reusim sa ne dam seama de problema din detaliile mentionate la (2), atunci forumul nu e suficient si trebuie apelat la suportul tehnic, pentru ca va fi nevoie de obtinerea unor date private(baze de date, etc.)

Informatii suplimentare prin care precizati in ce an veti termina de introdus documentele, sau cat de mari sunt amenzile si cat de mult lucrati, sa stiti ca le intelegem si le cunoastem, dar nu ne sunt de nici un folos in identificarea erorilor si nici nu usureaza descifrarea mesajului, de aceea va rog sa le scrieti intr-o sectiune ce nu se vrea "Tehnica".