# TRANSA 3 (L3) — cele doua puncte ramase din "Ce ramane neverificat"

Data: 27.07.2026. Read-only (Oracle: doar SELECT; cod: doar citire). Nimic modificat, nimic comis.
Nu ating `docs\handoff_transa3_conditii.md` (al colegului T3-cond).

## VERDICT GENERAL

- **Punctul 1 (goExecutor la timeout/conexiune cazuta) — CONTRAZICE PLANUL.** Comportamentul implicit
  NU e "se sare, cu linie in goLog": pe conexiune cazuta apare mereu un dialog modal blocant, care la
  Cancel face `QUIT` (inchide toata aplicatia). Pattern-ul defensiv cerut de plan **nu are niciun
  precedent** azi in codebase — trebuie construit, nu copiat.
- **Punctul 2 (linii pe decont) — RAMAS DESCHIS pe cifra exacta**, dar decizia arhitecturala a
  planului (fara lista `IN(...)`) ramane intemeiata independent de cifra. Schema dev nu are volum
  reprezentativ pentru batch-uri reale de extras/decont.

---

## Punctul 1 — comportamentul `goExecutor` la timeout / conexiune cazuta

Sursa reala (cautata cu `rg --no-ignore`... de fapt Grep a gasit-o direct, COMUN nu era exclus in
aceasta sesiune): clasa `oexecutor` e definita in `COMUN\programe\oproceduri_comune.prg:69-547`
(NU in `anaf_efactura.vc2` — de acolo doar se apeleaza). Instantiata o singura data:
`goExecutor = Createobject("oExecutor")`, `Programe\roacont.prg:588`.

### Ce intoarce `oExecute()` la esec

Functie normala, **nu arunca eroare VFP**. `SQLExec()` esuat intoarce direct `< 0`, prins de codul
existent — niciun `THROW`/`ERROR()` implicat. Return: `CT_INSUCCES` (`= -1`,
`COMUN\include\comun.h:10`) daca `lnSucces < 1`, altfel `CT_SUCCES` (`= 1`)
(`oproceduri_comune.prg:496`, `Return Iif(lnSucces >= 1, CT_SUCCES, CT_INSUCCES)`).
Cursorul de iesire nu se creeaza pe esec (Use-ul din urma nu ruleaza).

`oExecuta()` (wrapper cu litera mica, folosit in ~jumatate din apeluri) doar impacheteaza
`oExecute()` si adauga necontitionat `amessagebox(This.oPrelucrareEroare(), 16, "Eroare")` pe orice
esec (`:149-152`) — **indiferent de parametri**. Diferenta fata de `oExecute()` (raw) e semnificativa
pentru L3.

### Urca eroarea la `ErrorHandler` global? NU, direct — DAR

Nu urca la `ON ERROR` (nu e o exceptie VFP). Insa exista un dialog modal **necontitionat de
`tlShowError`**, la eroare ODBC (`lnEroare1 = 1526`) cu cod de eroare in lista
`12152, 3113, 3114, 12560, 4068, 28, 12` (`oproceduri_comune.prg:383`) — **exact codurile de
conexiune cazuta/protocol** (3114 = NOT CONNECTED TO ORACLE, 3113 = end-of-file on communication
channel, 12560 = protocol adapter error):

```
lnRaspuns = amessagebox('Eroare de conectare.' + ... + 'Doriti reconectare?', 4 + 32, 'Eroare')
```

(`:390`) — apare **mereu** cand `llReconnect = .T.`, chiar daca apelantul a lasat toti parametrii
default. Daca utilizatorul raspunde "Nu" (`lnRaspuns <> 6`): `Quit` + `Retry` (`:412-413`) —
**inchide toata aplicatia**, nu doar sare peste verificare.

`llReconnect` e recalculat **la fiecare apel**, ignorand orice setare anterioara pe obiect
(`:220-224`):
```
If SQLGetprop(lnHandle, "Transactions") = 2  && TRANZACTIE MANUALA
    This.lReconnect = .F.
Else
    This.lReconnect = .T.      && cazul normal, in afara unei tranzactii manuale
Endif
```
si apoi, daca apelul are sub 8 parametri (cazul general in tot codebase-ul), `llReconnect` preia
`This.lReconnect` — deci **.T. implicit** pentru orice verificare in afara unei tranzactii manuale.
Singurul mod de a opri acest modal e sa dai explicit al 8-lea parametru (`tlReconnect = .F.`) la
apel — vezi mai jos, nu exista niciun apel asa in tot codebase-ul.

**CONTRAZICE PLANUL:** cerinta "orice esec (... conexiune cazuta ...) -> se sare, cu linie in
`goLog`. Niciodata tacut... Esecul nu blocheaza salvarea" (plan, `:445-448`) **nu e comportamentul
implicit** pentru exact acest caz (conexiune cazuta). E opusul: un dialog modal blocant, care poate
opri toata aplicatia. Pentru orice ALTA eroare (SQL gresit, tabela inexistenta — `ORA-00942`,
coloana lipsa — `ORA-00904`), comportamentul implicit CHIAR e "se sare, log, fara dialog" —
`llShowError` e `.F.` implicit si acel dialog nu e conditionat decat de el. Deci planul are dreptate
pentru clasa generala de erori, dar nu pentru "conexiune cazuta" — exact cazul numit explicit in
text.

`goLog.Log(...)` SE cheama pe toate drumurile de esec (`:368-370`, `:384-387`, `:422-424`) — de
partea asta planul are dreptate necontitionat, indiferent de tipul erorii.

In plus, pe orice esec (`lnSucces < 0`), independent de parametri, codul posteaza automat eroarea la
endpoint-ul de erori (`goMyXMLHTTP.postError(...)`, `:463-471`) — un apel HTTP sincron in plus pe
drumul de salvare, la fiecare esec, inclusiv la cele care ar trebui "sarite silentios".

### Timeout configurat?

Nu exista niciun `SQLSETPROP` cu `QueryTimeout`/`ConnectTimeout`/`WaitTime` pe handle-ul Oracle,
nicaieri in `oExecutor`/`oConn` (`oproceduri_comune.prg:662-731`, `Connect` foloseste doar
`Sqlstringconnect(lcString)` cu `dsn=...;Uid=...;Pwd=...`, fara parametri de timeout). Singurul
`ConnectTimeout` gasit in tot fisierul (`:4105-4118`) e pentru verificarea HTTP de update-uri, fara
legatura cu conexiunea Oracle. **Concluzie: un query care ramane agatat (nu eroare, ci hang) nu are
niciun timeout care sa-l intrerupa — ar bloca formularul la nesfarsit**, ceva ce nici planul, nici
codul actual nu adreseaza. De consemnat separat, dincolo de "esec" (eroare) — un hang nu e un esec,
e o blocare fara iesire.

### Tiparul de apel defensiv "corect" deja folosit in codebase — NU EXISTA

Am cautat toate apelurile `oExecute(`/`oExecuta(` din COMUN si Programe (peste 150) — **niciunul nu
trece de 2 parametri** (`tcSql`, `tcCursor`). Nimeni nu foloseste vreodata parametrii 6-8
(`tlShowError`, `tlQuitOnError`, `tlReconnect`) explicit. Deci pattern-ul "cheama cu
`tlReconnect = .F.` ca sa eviti dialogul de reconectare" **nu are niciun precedent** — L3 ar fi
PRIMUL loc din codebase care il foloseste.

Cel mai apropiat precedent (nu perfect, dar cel mai aproape de "se sare fara dialog"):
- `oproceduri_inchidere.prg:1297`: `goExecutor.oExecuta(lcSql, "imob_conturi")` urmat doar de
  `If m.llSucces ... Endif` — la esec nu se face nimic in plus (dar `oExecuta` tot arata singura
  `amessagebox` interna, deci nu e cu adevarat silentios).
- Pattern mai bun de citat ca baza (foloseste `oExecute`, nu wrapper-ul `oExecuta`):
  `COMUN\clase\baza.vc2:1807`, `lnSucces = goExecutor.oExecute(lcSql,lcCursor)`, fara parametri
  suplimentari — la 2 parametri, `llShowError`/`llQuitOnError` raman `.F.` (fara dialog pe erori
  generice), dar `llReconnect` tot devine `.T.` implicit, deci tot apare dialogul de reconectare pe
  conexiune cazuta.

**Recomandare pentru L3** (nu e sarcina mea sa implementez, doar de raportat ca gasire): interogarea
noua trebuie sa apeleze `goExecutor.oExecute(...)` (NU `oExecuta`, care are mesaj propriu
necontitionat), cu toti cei 8 parametri, ultimul (`tlReconnect`) explicit `.F.`, si verificarea
proprie a rezultatului fara niciun `amessagebox` propriu — un tipar care azi nu exista nicaieri in
cod si trebuie scris de la zero, nu copiat.

---

## Punctul 2 — numarul real de linii pe un decont de curier/procesator

### Ce s-a verificat despre sursa datelor

Confirmat din cod (`Programe\oproceduri_import.prg:100-264`): importul de extrase/deconturi e
**strict pe fisier local** (`Getfile()` la `:138`, parsat client-side in cursoare VFP
`C_IMPORT_TEMP` -> `cActTemp`). Oracle NU pastreaza niciun tabel de staging cu "lot de import" si
numar de linii — abia dupa validare, liniile devin note (`ACT`/`ACTACTAN`) si se salveaza individual.
Deci **nu exista in Oracle o coloana/tabela care sa raspunda direct la intrebare** — a trebuit
reconstruita indirect.

`nom_fdoc`: `id_fdoc = 40` = `EXTRAS CON` (extras cont), `id_fdoc = 33` = `DECONT` (decont
curier/procesator).

### Reconstructie indirecta (proxy, nu masuratoare directa)

`ACT` nu are o coloana de "id lot" — am grupat notele salvate prin apropierea `DATAORA` (momentul
efectiv al salvarii, cu ora), pe acelasi `id_util`, cu prag de 10 minute intre randuri consecutive ca
limita de lot. E o aproximare (poate sparge/uni loturi reale), nu o masuratoare exacta din aplicatie.

**Rezultate (schema `MARIUSM_AUTO`, dev):**
- `DECONT` (id_fdoc=33): **doar 2 randuri in toata baza**, un singur lot de 2 linii (25.06.2026).
  Date insuficiente pentru orice concluzie.
- `EXTRAS CON` (id_fdoc=40): 222 randuri, pe 32 zile distincte, din 19.01.2008 pana in 29.05.2026 —
  40 loturi estimate. **min 1, max 70, medie 5.6, percentila 95 ≈ 10 linii/lot.**

**CONTRAZICE PLANUL, cu rezerva explicita de mai jos:** cifra afirmata in plan ("un extras obisnuit
are 300-2000 linii/luna") e cu un ordin de marime peste orice lot gasit in aceasta schema (maximul
absolut observat e 70).

**De ce nu extrapolez asta la "planul gresit pe cifra":** `MARIUSM_AUTO` e schema de dezvoltare a lui
Marius (confirmat in `COMUN\docs\oracle_export.md`), nu un client real cu volum de productie. Loturile
gasite arata a teste punctuale facute de-a lungul anilor (o inserare la cateva luni sau ani), nu
activitate de contabilitate lunara reala pe un cont bancar activ. **Schema dev NU are date
reprezentative pentru volumul real al unui client — nu pot confirma sau infirma cifra 300-2000 pe
aceasta baza.** Ramane RAMAS DESCHIS strict pe cifra exacta.

**Corroborare slaba, doar indicativa:** fisierul-sablon real din `Alte\Extras_de_cont_11634808MT
940.txt` (extras MT940 pentru o singura zi, un singur cont) are 11 linii de tranzactie (`:61:`) pentru
acea zi. Extrapolat naiv la ~20-22 zile lucratoare/luna ar da ~220-240 linii/luna pentru un cont de
activitate medie — aproape de capatul de jos al intervalului din plan (300), dar e un singur esantion
de o zi, pentru o singura firma, nu o distributie.

### Ce ramane solid, indiferent de cifra exacta

Decizia arhitecturala a planului de la Pasul 3 ("fara lista `IN(...)`", `:421-431`) **nu depinde**
de cifra 300-2000 ca sa fie corecta: o interogare unica, de lungime fixa, cu intersectia facuta local
in VFP, elimina o clasa intreaga de eroare (`ORA-01795`, prag 1000) **indiferent daca lotul real are
10 sau 2000 de linii** — nu exista un prag sub care revenirea la `IN(...)` ar fi de preferat, pentru
ca varianta cu interogare unica nu are dezavantaj de cost fata de o lista `IN` mica. Deci verdictul
practic: **decizia ramane intemeiata**, chiar daca premisa numerica citata in text nu e verificata
(si, pe aceasta schema, pare supraestimata).

---

## Alte observatii utile

- `oExecuta()` (wrapper) vs `oExecute()` (raw): distinctia conteaza mult pentru L3 si nu era
  evidenta din plan. `oExecuta` are propriul `amessagebox` necontitionat pe esec — pentru cerinta
  "niciodata dialog, doar log", trebuie folosit `oExecute`, nu `oExecuta`.
- `oPrelucrareEroare()` (folosit de mesajele proprii de eroare) nu a fost citit in detaliu — nu era
  necesar pentru cele doua puncte cerute.
