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.

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. 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 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.