docs: script_master.log, unde apar erorile de aplicare a scripturilor

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

docs/depanare-pack-update.md

@@ -14,6 +14,7 @@ O etapa esuata le opreste pe toate urmatoarele.
 | ce a raportat jobul | `dba_scheduler_job_run_details` (`log_date`, `status`, `additional_info`) |
 | ce versiuni s-au descarcat | `UPD_PROGRAME` |
 | scripturi disponibile / aplicate | `UPD_DATABASE.script_date` vs `<schema>.VERSIUNE.data_script` |
+| **erorile din aplicarea scripturilor** | **`C:\DMPDIR\script_master.log` pe serverul de baze de date** |
 
 Un sir de rulari oprite la aceeasi `stare` da direct etapa vinovata, iar prima zi din sir da data de
 la care s-a schimbat ceva.
@@ -32,6 +33,25 @@ la care s-a schimbat ceva.
   Se deblocheaza cu `exec contafin_oracle.pack_update.IncheiereActualizare`.
 - Programele `%USERREPORTS%` merg toate in directorul `UPD_USERREPORTS`, nu in `UPD_<nume_program>`.
 
+## Aplicarea scripturilor (script_master.log)
+
+Etapa 3 nu ruleaza scripturile din PL/SQL, ci genereaza in `DMPDIR` (`C:\DMPDIR`) cate un
+`script_<SCHEMA>.sql` plus `script_master.sql`, pe care le da unui **SQL\*Plus extern**, cu iesirea
+in `C:\DMPDIR\script_master.log` (`script_master2.log` = pasii de la final).
+
+**Erorile de aici NU ajung in `UPD_LOG`.** O rulare care esueaza la un script arata perfect curata
+in baza: `UPD_LOG` fara nicio eroare, doar `UpdateSchemaSQLPLUS ... / UpdateDatabaseSQLPLUS END`.
+Semnele indirecte sunt ca rularea ramane la `stare = 3` fara `dataora_end`, iar
+`<schema>.VERSIUNE` nu mai avanseaza. Scriptul vinovat e primul din `UPD_DATABASE` de dupa ultima
+versiune inregistrata acolo, iar mesajul real e doar in `script_master.log`.
+
+Scripturile au `WHENEVER SQLERROR EXIT SQL.SQLCODE ROLLBACK`, deci primul esec opreste tot lantul
+si se repeta identic la fiecare rulare pana e reparat.
+
+Fisierul se poate citi si fara acces la desktopul serverului, prin `UTL_FILE` pe directorul
+`DMPDIR` (`fopen(...,'R',32767)` + `get_line` in bucla; tine ultimele N linii intr-un tablou —
+partea utila e la sfarsit).
+
 ## Descarcarea (UpdateApp)
 
 Cu `server_info.POWERSHELLDOWNLOAD = '1'`, `PACK_UTILS.DownloadFileOS` scrie un `.ps1` cu `curl` in

docs/scripturi-migrare-db.md

@@ -24,6 +24,35 @@ Reguli confirmate de Marius (24.07.2026):
   Verificarile se fac inainte, separat, pe schema de lucru.
 - **Idempotent**: rulat de doua ori nu mai schimba nimic (`merge`, `where <coloana> is null`).
 
+## Compatibilitate cu serverele clientilor
+
+Serverul de dezvoltare e mai nou decat serverele clientilor, deci un script care trece local poate
+pica la client si opri actualizarea. **ROMCONSTRUCT e singurul client ramas pe Oracle 10.2** — el da
+masura pentru orice se pune in comune.
+
+Constructii care merg pe dev si pica pe 10g:
+
+| Constructie | Ce iese pe 10g |
+|---|---|
+| identificator peste 30 de caractere (tabela, index, constrangere, coloana) | `ORA-00972` (12.2+ accepta 128) |
+| `REGEXP_COUNT` (functie din 11g) | `ORA-00904` in SQL / `PLS-00201` in PL/SQL |
+| `CONTINUE` (instructiune PL/SQL din 11g) | `PLS-00201: identificatorul 'CONTINUE' trebuie declarat` |
+| `FORALL` cu campuri de record din colectie (`S(i).camp`) | `PLS-00436` / `PLS-00382` |
+
+Plus, independent de versiune: **un obiect nu se poate referi la ceva creat de un script ulterior.**
+Pe dev obiectul exista deja, deci pachetul compileaza; la client scriptele se aplica in ordine si
+iese `ORA-00942` / corp invalid. Cand un script creeaza o tabela si altul un pachet care o foloseste,
+tabela trebuie sa fie prima in ordinea `YYYY_MM_DD_NN`.
+
+Un pachet care nu are echivalent 10g se livreaza ca varianta separata pentru serverul acela
+(ex. `ff_..._PACK_CONTAFIN_10G_ROMCONSTRUCT.pck`). La aplicarea manuala a unei astfel de variante se
+compileaza **doar PACKAGE BODY-ul**: recrearea specificatiei invalideaza dependentele si da
+`ORA-04068` utilizatorilor conectati. Inainte, verifica ca specificatia din fisier e identica cu cea
+de pe server.
+
+Verificarea erorii se face in `C:\DMPDIR\script_master.log` de pe serverul clientului
+(`depanare-pack-update.md`) — nu apare in `UPD_LOG`.
+
 ## Numerotare si versiune_db.txt
 
 Numele scriptului: `<prefix>_YYYY_MM_DD_NN_<subiect>.sql`. Prefixe in uz: `ff` (schema fiecarei