Marius Mutu
4666262c92
COMUN/utile/publicare_scripturi.ps1 face cei doi pasi ai publicarii (import in UPD_DATABASE + arhiva lunara database[n]_*.zip in _UPDATE), cu configurarea citita din settings.ini-ul lui tasks.exe si verificare octet cu octet a continutului.
86 lines
5.0 KiB
Markdown
86 lines
5.0 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. 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.
|