If Tascus feels slow — for a single site, multiple sites, or specific users — use this checklist to narrow down whether the cause is network, server, or database configuration before making changes.
Isolate Where the Slowness Is
- Is the slowness happening for all users, or only users at a specific site/location?
- Is it slow for users on the same local network as the SQL Server, or only for remote/offsite users?
- Does slowness happen on reads, writes, or both?
- Does it happen all the time, or only at specific times (e.g. peak hours, backup windows, month-end)?
If local users are also affected, the cause is more likely server/database-side rather than network. If only remote users are affected, suspect network/latency between sites.
Network Checks (for multi-site / remote latency)
- Run `ping` and `tracert` (or `mtr`) from the affected site to the SQL Server — check both latency (ms) and packet loss (%), not latency alone
- If connecting via VPN or a tunnel, compare latency over the VPN vs. a direct path — tunnels sometimes backhaul through a third location, adding hidden round trips
- Confirm available bandwidth isn't saturated at either site during business hours
Why this matters: Tascus (like most thick database clients) makes many small, synchronous round trips to SQL Server per action. On a local network this is unnoticeable; across sites, each round trip adds real delay, and the effect multiplies with the number of calls per screen or transaction.
Database Server Checks
- Check where the database data/log files are located — are they on the same drive as the OS (typically C:)? SQL Server competes with the OS for disk I/O if co-located.
SELECT name, physical_name
FROM sys.master_files
WHERE database_id = DB_ID('TascusDatabaseName');- Check index fragmentation — indexes above 30% fragmentation should be rebuilt (see Database Setup & Maintenance article for the query)
- Check CPU, memory, and disk I/O usage on the SQL Server during the periods when slowness is reported
- Confirm recovery model and transaction log setup are configured correctly (uncontrolled TLog growth can degrade performance over time)
If Confirmed as Cross-Site Network Latency
If local users are fast but remote-site users are consistently slow, and network checks show elevated latency or loss to the SQL Server:
- This is expected behavior for a database client connecting directly across a WAN — it is generally not fixable by tuning the network alone, since the issue is round-trip count, not bandwidth
- The standard fix is to avoid sending database traffic across the WAN at all: run Tascus via a remote session (RDP, Citrix, or RemoteApp) hosted local to the SQL Server, so only screen and input data cross the WAN
- A secondary database server/replica at the remote site can help with reads, but writes still need to reach the primary — this adds complexity and is usually not the first thing to try
Summary: What to Check First
1. Confirm whether slowness is site-specific or universal
2. If site-specific → run network latency/loss checks
3. Regardless of site → check DB file location and index fragmentation on the server (cheap, low-risk, rules out a contributing factor either way)
4. Only pursue a network-level architecture change (remote session, replica) once network latency is confirmed as the actual cause
