publicare scripturi de baza de date: script + documentatie
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.
This commit is contained in:
83
docs/publicare-scripturi-db.md
Normal file
83
docs/publicare-scripturi-db.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Publicarea scripturilor de baza de date catre clienti
|
||||
|
||||
Scriptul: `COMUN\utile\publicare_scripturi.ps1`. Inlocuieste pasii manuali din `tasks.exe`
|
||||
(`D:\PROIECTE\fox\tasks`, formularul din `clase\generare_script.vcx`), care raman varianta de rezerva.
|
||||
Cum se scrie un script de migrare: `scripturi-migrare-db.md`.
|
||||
|
||||
```powershell
|
||||
powershell -File COMUN\utile\publicare_scripturi.ps1 -DryRun # ce ar face pe luna curenta
|
||||
powershell -File COMUN\utile\publicare_scripturi.ps1 # luna curenta, tot fluxul
|
||||
powershell -File COMUN\utile\publicare_scripturi.ps1 -Luna 2026-08 # alta luna
|
||||
powershell -File COMUN\utile\publicare_scripturi.ps1 -Fisier a.sql,b.sql # doar scripturile date
|
||||
```
|
||||
|
||||
Alte optiuni: `-DoarImport` (fara arhiva), `-DoarArhiva` (doar regenerare arhiva), `-Toate`
|
||||
(republica si scripturile identice), `-FaraVerificareZip`, `-Settings`, `-ZipPath`, `-DirScripturi`,
|
||||
`-Alias`, `-User`, `-Password`, `-SqlPlus`.
|
||||
|
||||
## Configurarea
|
||||
|
||||
Se citeste din `settings.ini`-ul lui `tasks.exe` (`D:\PROIECTE\fox\tasks\settings.ini`, schimbabil
|
||||
cu `-Settings`), aceleasi chei pe care le foloseste formularul; orice parametru dat explicit bate
|
||||
ini-ul.
|
||||
|
||||
| din ini | ce devine |
|
||||
|---|---|
|
||||
| `[connection] host_database` | nume de **DSN ODBC** — aliasul TNS e cheia `ServerName` a DSN-ului din registri (`CENTRAL` → `ROA_CENTRAL`) |
|
||||
| `[connection] username_database` / `password_database` | utilizatorul Oracle |
|
||||
| `[folder] script_folder` | directorul scripturilor, cu `\SCRIPTURI\` → `\SCRIPTURI_CLAR\` (+ `\<an>\<luna>\`) |
|
||||
| `[folder] roa_output` | + `_UPDATE\` = directorul arhivelor |
|
||||
| `[folder] sqlplus_exe` | clientul Oracle (si `TNS_ADMIN` = directorul lui) |
|
||||
| `[script]` | prefixele valide (`CO_`, `FF_`, `RF_`, `SYS_`, `JCS_`) — prefix necunoscut = avertisment |
|
||||
|
||||
`sqlplus_exe` arata spre `instantclient_19_18`; `instantclient_11_2_0_2` (valoarea de dinainte) are
|
||||
un `tnsnames.ora` vechi, cu `ROA_CENTRAL` pe `10.0.20.122` in loc de `.121`, deci conexiunea expira.
|
||||
`settings.ini` e local (ignorat de SVN).
|
||||
|
||||
## Cei doi pasi
|
||||
|
||||
**1. Import** — fiecare `.sql` intra ca un rand in `CONTAFIN_ORACLE.UPD_DATABASE` de pe `ROA_CENTRAL`,
|
||||
cu `SCRIPT_ORDER = 0` (randul contine scriptul intreg, nu instructiuni parsate), `SCRIPT_NAME` cu
|
||||
MAJUSCULE si `.SQL`, `SCRIPT_TYPE` = ce urmeaza dupa `NN_`, `SCRIPT_CONTENT` = fisierul in clar.
|
||||
`ID` vine din trigger, `DATAORA` din `SYSDATE` implicit, `SCRIPT_APPVER`/`SCRIPT_EXTRA_FILE` raman
|
||||
goale. Daca `SCRIPT_NAME` exista deja, se face **update pe acelasi `id`** — asa se republica un
|
||||
script corectat, pentru ca clientul face `MERGE ... on (a.id = b.id)`.
|
||||
|
||||
**2. Arhiva lunara** — in `Y:\ROAUPDATE\_UPDATE\` se scriu `database_YYYYMMDD_YYYYMMDD.zip` **si**
|
||||
`databasen_...zip` (identice azi: `database_` era varianta criptata cu `wrap.exe`, nu se mai
|
||||
foloseste). Fiecare contine XML-ul cu acelasi nume ca zip-ul (format `VFPData`/`crsxml`,
|
||||
Windows-1252, CRLF, tab-uri, `script_content` gol) plus cate un `<STEM_MAJUSCULE>.sql` per script.
|
||||
Indexii `roa_database.xml` / `roa_databasen.xml` listeaza arhivele existente si se schimba doar
|
||||
cand apare o luna noua.
|
||||
|
||||
Continutul din arhiva se citeste **inapoi din baza**, nu de pe disc — deci arhiva contine exact ce
|
||||
va primi clientul.
|
||||
|
||||
## Verificari facute automat
|
||||
|
||||
- fisier cu sfarsituri de linie LF: **refuzat** (parsarea pe client se face pe `CHR(13)+CHR(10)`);
|
||||
- dupa import, continutul e citit inapoi din CLOB si comparat octet cu octet cu fisierul; la
|
||||
diferenta se opreste inainte de arhiva;
|
||||
- scripturile deja publicate cu acelasi continut se sar (`-Toate` forteaza republicarea);
|
||||
- arhiva generata se citeste inapoi cu cititorul clientului (`pack_utils.decodebase64` +
|
||||
`zip_util_pkg.get_file`) si se compara lungime + MD5 per fisier — o arhiva facuta din PowerShell
|
||||
este citita corect de `zip_util_pkg`;
|
||||
- fisierele inlocuite din `_UPDATE` se copiaza intai in `_UPDATE\_backup\<data_ora>\`.
|
||||
|
||||
`Y:\ROAUPDATE\_UPDATE\` e **live**: clientii descarca de acolo imediat ce fisierul e pus.
|
||||
|
||||
## Ce face clientul
|
||||
|
||||
`PACK_UPDATE.UpdateScripts` (`COMUN\docs\PACK_UPDATE.pck`) descarca indexul, apoi arhivele care
|
||||
acopera perioada neaplicata, extrage XML-ul cu `zip_util_pkg.get_file`, face `MERGE` in
|
||||
`UPD_DATABASE` pe `id`, apoi pentru fiecare rand cu `script_extra_file` pune continutul fisierului
|
||||
in `script_content` — pentru `.sql` text clar, fara base64 (base64 e doar pentru instructiunile
|
||||
parsate, alta ramura). Actualizare blocata: `depanare-pack-update.md`.
|
||||
|
||||
## Detalii de implementare
|
||||
|
||||
Continutul circula **hexazecimal** in ambele sensuri (`utl_i18n.raw_to_char` / `string_to_raw` cu
|
||||
`WE8MSWIN1252`), pe bucati de 900 de octeti, in blocuri PL/SQL de cate 15 bucati. Motivul: baza e
|
||||
`AL32UTF8`, fisierele sunt CP1252, iar comanda trimisa lui `sqlplus` ramane ASCII pur — nu depinde
|
||||
de `NLS_LANG` si nu poate strica octetii >= 0x80. Consecinta utila: comparatia dintre fisier si
|
||||
CLOB e exacta, nu pe lungime.
|
||||
@@ -3,7 +3,8 @@
|
||||
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.
|
||||
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):
|
||||
|
||||
|
||||
@@ -12,6 +12,7 @@ a doua oara — daca a doua oara e nevoie de acelasi lucru, scrie scriptul.
|
||||
| editare `.vcx`/`.scx` | `D:\ROA\UTIL\foxbin2prg\` : `git_sync.ps1`, `vfp_symbols.ps1`, `txt2vcx.ps1` | reimprospatare text in-arbore, index de simboluri, write-back cu fidelity-check |
|
||||
| actualizare de baza de date blocata | `COMUN\utile\diag_actualizare.ps1 -Alias <TNS>` | `UPD_ISTORIC` → `UPD_LOG` → `script_master.log` → versiuni per schema → job → tablespace → verdict. Vezi `depanare-pack-update.md` |
|
||||
| spatiu plin la un client | `COMUN\utile\diag_spatiu.ps1 -Alias <TNS> [-Disc] [-SysPassword]` | tablespace, audit, ADR, FRA, disc server, top segmente. Vezi `depanare-spatiu-oracle.md` |
|
||||
| publicare scripturi de baza de date | `COMUN\utile\publicare_scripturi.ps1 [-Luna YYYY-MM] [-Fisier ...] [-DryRun]` | import in `UPD_DATABASE` → arhiva lunara `database[n]_*.zip` + indexi in `_UPDATE`, cu verificare octet cu octet. Vezi `publicare-scripturi-db.md` |
|
||||
| teste UI VFP | harness din `COMUN\utile\Teste` | vezi `testare-ui-vfp.md` |
|
||||
|
||||
Documentatia **nu** se genereaza automat si nu exista niciun hook care s-o scrie — `livrare.ps1`
|
||||
|
||||
Reference in New Issue
Block a user