comun/docs/scripturi-migrare-db.md

Scripturi migrare baza de date Oracle

Scripturile de migrare a schemei (si modelele pentru scripturi noi) sunt in DATABASE\SCRIPTURI_CLAR de sub radacina suitei ROA (gcDirMare/dirgen — ex. D:\ROA\DATABASE\SCRIPTURI_CLAR). Sursa SVN: http://svnroa:3001/svn/ROA/DATABASE/Branches/RB-1.00. Pentru un script nou, urmeaza formatul/conventiile celor recente de acolo. Publicarea catre clienti (import in UPD_DATABASE + arhiva lunara): publicare-scripturi-db.md.

Reguli confirmate de Marius (24.07.2026):

• Line-endings CRLF obligatoriu in scripturile .sql — tool-urile agentului scriu implicit LF; dupa orice scriere, verifica si converteste byte-safe LF -> CRLF (fara decodare/reincodare). Parsarea pe fluxul ROA (ex. ALINES pe CHR(13)+CHR(10)) esueaza silentios pe LF: tot fisierul devine un singur rand.
• versiune_db.txt (marker-ul YYYY_MM_DD_NN din radacina aplicatiei) se scrie fara newline la final (conventia existenta).
• Aplicarea prin ODBC/goExecutor: sintaxa SQL*Plus exec pachet.procedura(...) nu functioneaza — foloseste begin pachet.procedura(...); end;.

Continutul unui script

• Minimul necesar si intotdeauna SCOPED: update/insert doar pe randurile cazului tratat (setul, codul, firma anume), niciodata pe toate randurile care "seamana" cu el.
• Fara select de raportare in script — nu-l citeste nimeni la aplicare si poate da eroare. 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.

Parcul de servere (03.08.2026): un client pe Oracle 10.2 (ROMCONSTRUCT), cativa pe XE 11 si 11g standard, restul pe XE 18/19/21 si 18/21.

Regula: orice script care ajunge in comune se scrie la nivelul Oracle 10.2 si trebuie sa ruleze pe 10.2 si pe 11.x. Numitorul comun e 10.2 — nu se folosesc facilitati 11g si cu atat mai putin 12c+, oricat de comod ar fi pe dev. Proba inainte de publicare se face pe serverul cel mai vechi (ROMCONSTRUCT), nu pe dev.

Constructii care merg pe dev si pica mai jos:

Constructie	Disponibila de la	Ce iese sub ea
identificator peste 30 de caractere (tabela, index, constrangere, coloana)	12.2	ORA-00972
REGEXP_COUNT	11.1	ORA-00904 in SQL / PLS-00201 in PL/SQL
CONTINUE (instructiune PL/SQL)	11.1	PLS-00201: identificatorul 'CONTINUE' trebuie declarat
LISTAGG	11.2	ORA-00904
PIVOT / UNPIVOT	11.1	eroare de sintaxa
trigger compus (COMPOUND TRIGGER)	11.1	eroare de compilare
secventa.NEXTVAL direct intr-o atribuire PL/SQL	11.1	PLS-00357 (pe 10g: select ... into din dual)
FETCH FIRST n ROWS, CROSS APPLY, LATERAL	12.1	eroare de sintaxa (pe 10g/11g: rownum)
IDENTITY, DEFAULT ON NULL, coloane invizibile	12.1	eroare de sintaxa
VALIDATE_CONVERSION, CAST ... DEFAULT ON CONVERSION ERROR	12.2	ORA-00904
FORALL cu campuri de record din colectie (S(i).camp)	11.1	PLS-00436 / PLS-00382

Editiile XE adauga limite proprii, independent de sintaxa: XE 11.2 nu are partitionare, executie paralela si nici masina virtuala Java in baza; XE 18/19/21 au setul de facilitati al editiei mari, dar plafonate pe resurse (12 GB de date, 2 GB RAM, 2 fire de executie). Deci nimic care sa depinda de partitionare sau de Java in baza, si nicio operatie care sa presupuna spatiu/memorie de server mare.

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 firme), co (CONTAFIN_ORACLE), sys, ris, rf.

• NN e o secventa unica pe zi, comuna tuturor prefixelor — un numar consumat de un co_ nu se reia intr-un ff_ din aceeasi zi si invers.
• In versiune_db.txt (radacina aplicatiei) se trece doar versiunea ultimului script ff_: programele se conecteaza pe schema firmei, nu pe CONTAFIN_ORACLE, deci markerul urmareste numai migrarile aplicate acolo.