fix(oracle): sys-grants.sql muta DMPDIR inapoi pe C:, iar 05 numara esecul drept succes

Gasite la prima rulare reala a FAZA2 la VADECO. Toate trei importurile de firma
au picat, si scriptul a raportat "Successful: 3, Failed: 0".

1. sql/sys-grants.sql facea CREATE OR REPLACE DIRECTORY DMPDIR AS 'C:\DMPDIR'
   neconditionat. Ruleaza in pasul 04, deci DUPA importul contafin-ului din 03:
   importul acela reusea cu calea corecta, iar obiectul era mutat imediat dupa.
   Pe VADECO, unde procesul Oracle nu ajunge la nicio cale de pe C:, esecul a
   aparut abia in faza 2, ca ORA-39002 / ORA-39070 / ORA-29283 - ore mai tarziu
   si fara nicio legatura vizibila cu pasul care il provocase.

   E aceeasi clasa de defect ca cel reparat in ec66377 pentru pasul 02, dar
   ascuns intr-un fisier .sql, deci corectia de atunci l-a ratat. Acum calea
   existenta se pastreaza si se raporteaza, ca in grants-public.sql; se creeaza
   doar daca DMPDIR lipseste cu totul, caz in care se si avertizeaza ca pasul 01
   nu a rulat.

2. 05-import-companies.ps1 incrementa $successCount si pe ramura de cod de
   iesire nenul, iar numarul de obiecte de dupa import nu era verificat deloc.
   Rezultatul: trei scheme goale raportate ca importate cu succes, faza 2
   terminata "cu observatii", si defectul descoperit doar pentru ca schemele
   goale sar in ochi la verificare.

   Acum: 0 obiecte inseamna esec, oricare ar fi codul de iesire - un import care
   lasa schema goala nu e un succes. Codul 5 ramane acceptat (ORA-31684 pe user,
   ORA-39082 pe obiecte compilate, normale la ROA), orice alt cod nenul e esec.
   Sumarul si codul de iesire spun adevarul, deci FAZA2.cmd se opreste pe
   :esec_05 in loc sa continue peste un import inexistent.

3. 07-verify-installation.ps1 verifica acum ca baza chiar poate SCRIE in DMPDIR,
   printr-o runda UTL_FILE (deschide, scrie, sterge). Calea din dba_directories
   e doar un sir de caractere si nu spune nimic despre acces - exact motivul
   pentru care New-OracleDirectory primise deja acelasi tratament in ec66377.
   Verificarea asta ar fi prins defectul de mai sus inainte de faza 2.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SzF1hf4aFS1tmJWpPMiwGp

proxmox/lxc108-oracle/roa-windows-setup/README.md

@@ -580,6 +580,32 @@ ALTER SYSTEM REGISTER;
 | `ORA-00959: tablespace 'USERS' does not exist` (PDB nou) | `impdp … REMAP_TABLESPACE=USERS:ROA` |
 | `ORA-39405: … TSTZ version newer` | folosește DMP-uri exportate din Oracle 18c (TSTZ 31), nu 21c (TSTZ 35) |
 | `ORA-39002` / eroare la deschiderea fișierului | serviciul Oracle nu are drepturi pe `C:\DMPDIR` — `icacls C:\DMPDIR /grant "NT SERVICE\OracleServiceXE:(OI)(CI)F" /T` |
+| `ORA-39002` + `ORA-39070: Unable to open the log file` + `ORA-29283` | `DIRECTORY DMPDIR` nu arată unde crezi — vezi mai jos |
+
+### `DIRECTORY DMPDIR` s-a mutat singur
+
+**Simptom:** importul contafin-ului (pasul 03) reușește, dar importul firmelor
+(pasul 05, de obicei în altă zi) pică pe toate schemele cu
+`ORA-39070 / ORA-29283`, iar schemele rămân goale.
+
+**Cauză, până pe 2026-08-25:** `sql/sys-grants.sql`, rulat de pasul **04**, făcea
+`CREATE OR REPLACE DIRECTORY DMPDIR AS 'C:\DMPDIR'` necondiționat. Pasul 04
+rulează *după* 03, deci importul contafin-ului apuca să reușească, iar obiectul
+era mutat imediat după. Pe mașinile unde `C:` nu e accesibil procesului Oracle,
+eșecul apărea abia ore mai târziu, fără nicio legătură vizibilă cu pasul care îl
+provocase. Corectat: calea existentă se păstrează.
+
+**Verificare** — calea din dicționar nu e o dovadă, contează dacă baza chiar
+poate scrie acolo. `07-verify-installation.ps1` face acum o rundă `UTL_FILE`.
+Manual:
+
+```sql
+SELECT directory_path FROM dba_directories WHERE directory_name = 'DMPDIR';
+```
+
+```powershell
+Run.cmd 01-setup-database.ps1 -DmpDir D:\DMPDIR   # repune calea si o verifica
+```
 
 ### ORA-12954: baza depășește 12 GB (doar XE)