Files
ROMFASTSQL/proxmox/lxc108-oracle/roa-windows-setup/sql
Marius 3ba36b6119 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
2026-08-25 22:32:17 +03:00
..