91e822eb53
La VADECO, backupora.exe rula in fiecare noapte, se termina cu cod 0 si scria "DONE" pentru fiecare schema - dar directorul zilei ramanea gol. Intre 25 si 28.08.2026 nu a existat niciun export. Cauza: schema.txt cere "@XEPDB1", iar 01-setup-database.ps1 scria in tnsnames.ora doar aliasul ROA. expdp cadea instant cu ORA-12154, iar backupora.exe nu-i verifica codul de iesire. Doua scripturi din acelasi kit nu erau de acord asupra numelui bazei, si nimic nu tipa. Indiciul din log, daca reapare: fiecare schema dura exact 16 secunde, indiferent de marime. Timp uniform = expdp moare la conectare, nu exporta. Reparatii, ca sa nu se repete la alt client: - 01-setup-database.ps1 scrie acum doua aliasuri, ROA si numele serviciului, in ambele tnsnames.ora. Curatarea dinaintea rescrierii parcurge fiecare alias gestionat de noi, altfel al doilea s-ar dubla la fiecare rulare. Aliasurile generate de Oracle (XE, LISTENER_XE, ORACLR_CONNECTION_DATA) raman neatinse. - 11-setup-backup-export.ps1 face tnsping inainte de a scrie schema.txt si opreste instalarea daca aliasul nu se rezolva. Mai bine o instalare care se plange decat un backup care nu exista. - lectii-actualizare-roa-alias-tns.md capata sectiunea despre a doua victima a aceleiasi cauze. Lectia generala: unde un script lanseaza un proces extern Oracle, verifica efectul, nu raportul procesului care l-a lansat. Include si blocul NTS din config/sqlnet.ora, ramas necomis: autentificarea OS cere si apartenenta la ORA_OraDB21Home1_DBA, si setarea din sqlnet.ora. Nota: CLAUDE.md apare ca modificat integral - blob-ul din git avea CRLF, iar core.autocrlf=true il normalizeaza la LF. Modificarea reala e o singura linie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X9Sa54oFKpE2XhD6A7NTch