Saga multi-user în rețea — cum o configurezi corect (ghid 2026)
Saga rulează lent când lucrează 3+ utilizatori simultan? Înghețuri, locking, baze corupte? Iată setup-ul corect de rețea pentru Saga multi-user.
Ionut Mihaescu — Full Stack Developer Azuvio · 2026-05-21 · 7 min · ERP & Integrări
Problema multi-user clasică
Saga e construită pe Visual FoxPro / DBF — tehnologie excelentă pentru 1-2 utilizatori, dar care suferă pe rețea cu 3+ utilizatori simultani pe baze locking-intensive (facturi, încasări, plăți concurente). Simptome:
Saga îngheață când 2 useri salvează simultan
Mesaje «File is in use by another user»
Tranzacții parțiale (factura salvată dar nu și înregistrarea contabilă)
Corupere bază (foarte rar dar catastrofic)
Pasul 1 — Server fizic dedicat (NU desktop)
Cerințe minime:
Windows Server 2019 / 2022 (NU Windows 10/11 — limite de licență CAL)
16-32 GB RAM (8GB sunt suficienți pentru baza, restul pentru SMB caching)
SSD enterprise (Samsung PM893, Intel D3-S4520) — NU SSD consumer
RAID 1 sau RAID 10 — protecție pentru pierdere hardware
UPS profesional (APC Smart-UPS 1500VA+) — căderile bruște de curent corup baze DBF
Pasul 2 — Share de rețea configurat corect
Pe server creează un share `\\SERVER\SAGA\` cu permisiuni:
Permisiuni share: «Full Control» pentru grupul `Domain Users` (sau echivalent)
Permisiuni NTFS: Modify pentru grupul de utilizatori Saga, Full Control pentru admini
Caching: dezactivat («No files or programs from the shared folder are available offline»)
Opportunistic locking: dezactivat — vezi Pasul 3
Pasul 3 — Dezactivare oplocks (CRITIC)
Windows SMB are «opportunistic locking» care îmbunătățește performanța pentru fișiere mari, dar corupe bazele DBF când 2+ useri scriu simultan.
Pe server, în Registry:
```
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
EnableOplocks = 0 (DWORD)
EnableLeasing = 0 (DWORD)
```
Pe fiecare client Windows:
```
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
OplocksDisabled = 1 (DWORD)
```
Restart server + clienți. Acest pas singur reduce 80% din coruperile DBF.
Pasul 4 — Instalare Saga pe clienți
Saga se instalează local pe fiecare client, dar bazele sunt pe server. Setări:
La instalare, alege «Bazele de date sunt pe server» → introdu path-ul `\\SERVER\SAGA\BAZA\`
Verifică că fiecare user are credențiale Windows cu acces la share
Versiunea Saga TREBUIE să fie identică pe toți clienții + server (orice mismatch → erori)
Pasul 5 — Setări Saga pentru multi-user
În Saga, Service → Setări multi-user:
Timeout tranzacții: 30 secunde (default 10 = prea mic pentru retea)
Retry pe locking: 5 încercări
Cache local read: activat (citire mai rapidă, scriere rămâne pe server)
Pasul 6 — Backup centralizat (NU pe fiecare client)
Cu setup multi-user, backup-ul rulează doar pe server, nu pe clienți (clienții nu au datele). Recomandare:
Backup zilnic 23:00 cu Veeam Backup & Replication (free version pentru <10 VM)
Backup săptămânal full + zilnic incremental
Replicare către NAS secundar (Synology / QNAP)
Sync cloud săptămânal (Backblaze B2 sau Acronis Cyber Protect)
Pasul 7 — Monitorizare
Pentru a prinde problemele înainte să afecteze users:
SMB performance monitor (free Windows): vezi latența rețelei, blocaje, conexiuni active
Disk I/O monitoring (perfmon): vezi dacă SSD-ul e bottleneck
Logs Saga (`\SAGA\LOG\`): erori de locking, timeout, deconectări
Când Saga multi-user devine insuficient
La 10+ utilizatori simultani sau 5.000+ tranzacții/zi, arhitectura Saga DBF se apropie de limite reale. Soluții:
Fragmentare baze: 1 firmă mare → 2-3 baze (an curent + arhivă) pentru a reduce locking
Layer operațional separat: comenzile, facturarea, dashboard-ul, multi-user activ trăiesc în Azuvio (cloud, multi-user nativ), iar Saga primește agregate zilnice — reduce drastic concurența pe baza Saga
Vezi [conectorul Saga ↔ Azuvio](/software/conectori-erp/saga) sau articolul «[Limitări Saga pentru firme mari](/blog/saga-limitari-firme-mari-cfo-2026)».
Concluzie
Saga multi-user merge stabil cu: server Windows Server + SSD enterprise + RAID + UPS + oplocks dezactivat + backup centralizat. Greșeala #1: oplocks active = corupere DBF garantată. La 10+ users, consideră layer operațional separat. Vezi și «[Migrare Saga pe server nou](/blog/migrare-saga-pe-server-nou-fara-pierdere-date)» pentru tranziție corectă.