Files
comun/docs/scripturi-migrare-db.md
2026-08-03 10:05:33 +03:00

66 lines
3.6 KiB
Markdown

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