Multi-user Saga network setup — how to configure it correctly (2026 guide)
Is Saga running slowly with 3+ simultaneous users? Freezes, locking, or corrupted databases? Here is the correct network setup for multi-user Saga environments.
Ionut Mihaescu — Full Stack Developer Azuvio · 2026-05-21 · 7 min · ERP & Integrations
The classic multi-user problem
Saga is built on Visual FoxPro / DBF — an excellent technology for 1-2 users, but one that struggles over a network with 3+ simultaneous users on locking-intensive databases (concurrent invoicing, receipts, payments). Symptoms:
Saga freezes when 2 users save simultaneously
«File is in use by another user» messages
Partial transactions (invoice saved but accounting entry missing)
Database corruption (very rare but catastrophic)
Step 1 — Dedicated physical server (NOT a desktop)
Minimum requirements:
Windows Server 2019 / 2022 (NOT Windows 10/11 — due to CAL licensing limits)
16-32 GB RAM (8GB is sufficient for the database, the rest for SMB caching)
Enterprise SSD (Samsung PM893, Intel D3-S4520) — NOT consumer SSDs
RAID 1 or RAID 10 — hardware failure protection
Professional UPS (APC Smart-UPS 1500VA+) — sudden power cuts corrupt DBF databases
Step 2 — Correct network share configuration
On the server, create a share `\\SERVER\SAGA\` with the following permissions:
Share permissions: «Full Control» for the `Domain Users` group (or equivalent)
NTFS permissions: «Modify» for the Saga user group, «Full Control» for admins
Caching: disabled («No files or programs from the shared folder are available offline»)
Opportunistic locking: disabled — see Step 3
Step 3 — Disabling oplocks (CRITICAL)
Windows SMB uses «opportunistic locking» which improves performance for large files but corrupts DBF databases when 2+ users write simultaneously.
On the server, in the Registry:
```
HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
EnableOplocks = 0 (DWORD)
EnableLeasing = 0 (DWORD)
```
On each Windows client:
```
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
OplocksDisabled = 1 (DWORD)
```
Restart server + clients. This step alone reduces 80% of DBF corruptions.
Step 4 — Installing Saga on clients
Saga is installed locally on each client, but the databases remain on the server. Settings:
During installation, choose «Databases are on a server» → enter the path `\\SERVER\SAGA\BAZA\`
Ensure each user has Windows credentials with share access
The Saga version MUST be identical on all clients + server (any mismatch → errors)
Step 5 — Saga settings for multi-user
Inside Saga, go to Service → Multi-user Settings:
Transaction timeout: 30 seconds (default is 10 = too low for network use)
Locking retry: 5 attempts
Local read cache: enabled (faster reading, writing remains on the server)
Step 6 — Centralized backup (NOT on every client)
In a multi-user setup, the backup runs only on the server, not on the clients (clients do not store the data). Recommendation:
Daily backup at 23:00 with Veeam Backup & Replication (free version for <10 VMs)
Weekly full backup + daily incremental
Replication to a secondary NAS (Synology / QNAP)
Weekly cloud sync (Backblaze B2 or Acronis Cyber Protect)
Step 7 — Monitoring
To catch issues before they impact users:
SMB performance monitor (free Windows tool): monitor network latency, locks, active connections
Disk I/O monitoring (perfmon): check if the SSD is a bottleneck
Saga Logs (`\SAGA\LOG\`): check for locking errors, timeouts, disconnections
When multi-user Saga is no longer enough
At 10+ simultaneous users or 5,000+ transactions/day, the Saga DBF architecture approaches its real limits. Solutions:
Database fragmentation: 1 large company → 2-3 databases (current year + archive) to reduce locking
Separate Operations Layer: orders, invoicing, dashboards, and active multi-user workflows live in Azuvio (cloud, native multi-user), while Saga receives daily aggregates — drastically reducing concurrency on the Saga database
See the Saga ↔ Azuvio connector or the article «Saga limitations for large companies».
Conclusion
Multi-user Saga runs stably with: Windows Server + enterprise SSD + RAID + UPS + disabled oplocks + centralized backup. Error #1: active oplocks = guaranteed DBF corruption. For 10+ users, consider a separate operational layer. See also «Migrating Saga to a new server» for a correct transition.