Search Results

🗄️ Internal Support Document

BUSY Software
MSSQL Troubleshooting Guide

A professional knowledge base for BUSY Support Engineers to quickly diagnose and resolve common Microsoft SQL Server issues affecting BUSY accounting software.

🗂 20 Issues Covered
💾 SQL Server 2008 – 2022
🔧 BUSY All Versions
📋 Print Ready
🏢Connectivity5 issues 🗄Database Health4 issues 🔐Auth & Login3 issues ⚡Performance2 issues 💾Backup & Restore2 issues 🌐Network & LAN4 issues
⚠️ Common Issues at a Glance

Quick summary of all 20 documented issues with their root causes and severity levels.

#IssueRoot CauseSeverity
1Company Not OpeningSQL service stopped / networkHigh
2Data Showing SUSPECTDatabase corruptionHigh
3RECOVERY_PENDINGLog file / disk spaceHigh
4User LockedInvalid login attemptsMedium
5Password / Login FailedWrong or expired credentialsMedium
6Slow Voucher EntryBlocking / high resource usageMedium
7Backup FailedPermission / disk spaceMedium
8Restore FailedCorrupt backup / active connectionsMedium
9Multi-User ConnectionNetwork issueMedium
10SQL Timeout ErrorNetwork latency / SQL overloadMedium
11MDF File InaccessibleFolder permissionsMedium
12Log File FullAuto-growth disabled / no spaceMedium
13Ping Test FailedLAN issueLow
14Shared Folder InaccessibleSharing / permission issueLow
15SQL Service StoppedSQL Server service issueHigh
16Port 4444 ClosedFirewall / TCP-IP disabledMedium
17SQL Login FailedAuthentication issueHigh
18Disk Space FullStorage issueMedium
19Company Opens on Server OnlyNetwork / firewall issueMedium
20One User AffectedLocal configuration issueLow
🛠 Step-by-Step Solutions

Click any card to expand the full resolution guide. Work through each step in order.

1
🏢 Company Not Opening
Root Cause: SQL service stopped, database detached, or network unreachable
HIGH ⌄
⚠️ Most common first-call issue. Always verify SQL service status before investigating further.
✅ Solution Steps
  1. 1Open services.msc on the server. Locate SQL Server (MSSQLSERVER) — if it shows "Stopped", right-click → Start.
  2. 2Open SSMS and confirm the company database is listed, online, and not in a SUSPECT or detached state.
  3. 3Test network reachability from the client machine using ping SERVER_IP. If ping fails, escalate to the network team.
  4. 4Verify SQL port connectivity: telnet SERVER_IP Port_No. If blocked, add a Windows Firewall inbound rule.
  5. 5Once all three checks pass (service running, database online, network reachable), ask the user to reopen BUSY.
💻 Useful Commands
services.msc -- Open Windows Services Manager ping SERVER_IP -- Test basic network connectivity telnet SERVER_IP Port_No -- Test specific SQL port connectivity
2
🚨 Data Showing SUSPECT
Root Cause: Database file corruption
HIGH ⌄
⚠️ CRITICAL — Confirm a recent backup exists BEFORE running any repair commands. Data loss is possible.
✅ Solution Steps
  1. 1In SSMS Object Explorer, confirm the database status shows SUSPECT.
  2. 2Locate the most recent .BAK backup file and note its date. If a clean backup exists, prefer restoring from it instead of the repair below.
  3. 3Run the following commands in sequence in SSMS — replace DatabaseName with your actual database name.
  4. 4Review the full output of DBCC CHECKDB carefully for details on what was repaired or lost.
  5. 5If data loss occurred, restore from the last known-good backup after completing repair.
💻 SSMS Repair Commands
-- Step 1: Put database into Emergency read-only mode ALTER DATABASE [DatabaseName] SET EMERGENCY; -- Step 2: Switch to Single-User mode (disconnects all users) ALTER DATABASE [DatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; -- Step 3: Run repair (allows data loss — last resort only) DBCC CHECKDB ([DatabaseName], REPAIR_ALLOW_DATA_LOSS); -- Step 4: Return to normal Multi-User mode ALTER DATABASE [DatabaseName] SET MULTI_USER;
💡 REPAIR_ALLOW_DATA_LOSS can permanently delete records. Always prefer restoring from backup when available.
3
⏳ Database Showing RECOVERY_PENDING
Root Cause: Log file corruption or insufficient disk space
HIGH ⌄
✅ Solution Steps
  1. 1Open SQL Server Error Logs in SSMS (Management → SQL Server Logs) to identify the exact recovery failure reason.
  2. 2Navigate to the database data folder and confirm both MDF (data file) and LDF (log file) are present and accessible.
  3. 3Open diskmgmt.msc and verify there is sufficient free space on the drive hosting the database files.
  4. 4Restart the SQL Server service from services.msc and recheck the database status in SSMS.
  5. 5If the issue persists, restore the database from the latest healthy backup.
💻 Useful Commands
-- Check status of all databases SELECT name, state_desc FROM sys.databases; services.msc -- Open Services Manager to restart SQL service diskmgmt.msc -- Verify free disk space
4
🔒 User Account Locked
Root Cause: Multiple failed login attempts or security policy restriction
MEDIUM ⌄
✅ Solution Steps
  1. 1Ask the user to confirm their username and password — a simple typo is the most common cause.
  2. 2In SSMS, go to Security → Logins, right-click the affected login → Properties → Status tab → confirm it is not disabled or locked.
  3. 3Run the unlock command below in a new SSMS Query window.
  4. 4Ask the user to retry login with the correct credentials.
💻 SSMS Command
-- Enable and unlock the SA login (replace 'sa' with the actual login name) ALTER LOGIN sa ENABLE;
5
🔑 Password Changed / Login Failed
Root Cause: Password was changed or is incorrect / expired
MEDIUM ⌄
✅ Solution Steps
  1. 1Confirm what username and password are configured in BUSY's company connection settings.
  2. 2If the password was changed or forgotten, reset it using the SQL command below in SSMS.
  3. 3After resetting, update the BUSY company login settings to match the new password.
  4. 4Reconnect to SQL Server and verify BUSY opens the company successfully.
💻 Password Reset Command
-- Reset the SA login password (replace with actual login name and new password) ALTER LOGIN sa WITH PASSWORD = 'Busy@1234';
6
⚡ Slow Voucher Entry / Performance Issues
Root Cause: SQL blocking, high resource usage, or antivirus interference
MEDIUM ⌄
💡 Performance issues are often caused by multiple overlapping factors. Work through each check systematically.
✅ Solution Steps
  • Open Task Manager (taskmgr) and check CPU, RAM, and Disk usage — ensure none are consistently at 90–100%.
  • Open Resource Monitor (resmon) to identify any specific process consuming excessive resources.
  • In SSMS, check for blocking sessions holding locks that prevent other users from completing transactions.
  • Add the Busywin installation directory to the Antivirus exclusion list — real-time scanning of BUSY files can severely degrade performance.
  • Temporarily disable Antivirus and test voucher entry speed. If it improves, configure the exclusion permanently.
  • Temporarily disable Windows Firewall and retest. If improved, add targeted firewall rules instead of leaving it off.
  • Verify that UAC (User Account Control) is not restricting BUSY or SQL Server access.
  • If the issue is on client machines, test network latency with ping SERVER_IP.
💻 Useful Commands
taskmgr -- Task Manager (CPU/RAM/Disk) resmon -- Resource Monitor (detailed) services.msc -- Check SQL Server service status wf.msc -- Windows Firewall Advanced Settings UserAccountControlSettings -- Open UAC settings
7
💾 Backup Failed
Root Cause: Insufficient folder permissions or not enough disk space
MEDIUM ⌄
✅ Solution Steps
  1. 1Identify the SQL Server Service Account (visible in services.msc → SQL Server → Properties → Log On tab).
  2. 2Right-click the backup destination folder → Properties → Security tab → confirm the SQL Server service account has Full Control.
  3. 3Open diskmgmt.msc and verify adequate free space on the backup target drive.
  4. 4Confirm the backup destination path exists and the folder is accessible from the SQL Server service account.
🔎 Verification Checklist
  • Retry the backup operation after granting permissions and freeing space.
  • Confirm a .BAK file was created at the specified path.
  • Check the file size is non-zero and the creation timestamp matches the backup time.
💻 Command
diskmgmt.msc -- Open Disk Management to check free space
8
🔄 Restore Failed
Root Cause: Corrupted backup file or active user connections
MEDIUM ⌄
✅ Solution Steps
  1. 1In SSMS, use Restore → Verify Backup Media to check the .BAK file integrity before attempting the restore.
  2. 2Confirm the restore destination path is accessible and the SQL service account has write permissions on that folder.
  3. 3If overwriting an existing database, first disconnect all active users — right-click database → Tasks → Take Offline, or set to single-user mode.
  4. 4Check the destination drive has enough free space for both the MDF and LDF files using diskmgmt.msc.
9
🌐 Multi-User Connection Issue
Root Cause: Network connectivity or SQL Browser service not running
MEDIUM ⌄
✅ Solution Steps
  1. 1From an affected client, ping the server: ping SERVER_IP to verify basic network connectivity.
  2. 2Test shared BUSY folder access from the client — open Run and type \\SERVERNAME.
  3. 3Test SQL port from the client: telnet SERVER_IP 1433. Failure means the firewall is blocking it.
  4. 4On the server, open services.msc and confirm both SQL Server (MSSQLSERVER) and SQL Server Browser are Running.
  5. 5Open SQL Server Configuration Manager → SQL Server Network Configuration → Protocols → ensure TCP/IP is Enabled.
💻 Commands
ping SERVER_IP -- Test network reachability \\SERVERNAME -- Test shared folder access (in Run dialog) telnet SERVER_IP 1433 -- Test SQL Server default port services.msc -- Verify SQL services are running
10
⏱ SQL Timeout Error
Root Cause: Network latency or SQL Server overloaded
MEDIUM ⌄
✅ Solution Steps
  1. 1Test network connectivity from the affected machine: ping SERVER_IP. Packet loss or >10ms latency on LAN is a red flag.
  2. 2Test SQL port: telnet SERVER_IP 1433. A timeout here points to firewall or network issues.
  3. 3On the server, open taskmgr and check if CPU, RAM, or disk is under heavy load.
  4. 4In SSMS, check for blocking queries — long-running queries cause downstream operations to timeout.
  5. 5If multiple users are experiencing timeouts simultaneously, escalate to the DBA — the root cause is server-side.
💻 Commands
ping SERVER_IP -- Check network latency telnet SERVER_IP 1433 -- Verify SQL port connectivity services.msc -- Confirm SQL services are running taskmgr -- Check server resource usage
11
📁 MDF File Inaccessible
Root Cause: SQL service account lacks permissions on the file folder
MEDIUM ⌄
✅ Solution Steps
  1. 1Confirm the MDF file exists at the expected path (typically C:\Program Files\Microsoft SQL Server\MSSQL\DATA\).
  2. 2Right-click the folder containing the MDF and LDF files → Properties → Security tab.
  3. 3Add the SQL Server service account (e.g., NT SERVICE\MSSQLSERVER) and grant it Full Control.
  4. 4Confirm the account also has access to the parent drive (not just the subfolder).
  5. 5Retry the attach or restore operation in SSMS.
12
📋 Transaction Log File Full
Root Cause: Auto-growth is disabled or the disk is out of space
MEDIUM ⌄
✅ Solution Steps
  1. 1Check available disk space using diskmgmt.msc on the drive hosting the log file.
  2. 2In SSMS, right-click the database → Properties → Files tab. Check the current LDF (log) file size.
  3. 3Enable Auto-Growth for the log file if disabled — set a reasonable increment (e.g., 256 MB or 10%).
  4. 4Take a full database backup. This allows SQL Server to reuse inactive log space.
  5. 5Consider switching the database Recovery Model to Simple for non-critical databases to reduce log growth.
13
📡 Ping Test Failed
Root Cause: Physical LAN issue or incorrect IP configuration
LOW ⌄
✅ Solution Steps
  1. 1Check that the LAN cable is physically plugged in and the port LED is active on both the server and client.
  2. 2Confirm the network switch or router is powered on (check indicator lights).
  3. 3Run ipconfig on both machines — confirm they are on the same subnet (e.g., both 192.168.1.x).
  4. 4If IP configuration looks wrong, verify DHCP assignment or set a static IP address.
  5. 5Disable and re-enable the network adapter from Network Connections settings, then test ping again.
💻 Commands
ipconfig -- View IP, subnet, and gateway ping SERVER_IP -- Test client-to-server connectivity ping 127.0.0.1 -- Test local network stack (loopback)
14
📂 Shared Folder Inaccessible
Root Cause: Incorrect sharing or permission settings on the server
LOW ⌄
✅ Solution Steps
  1. 1From the client, open Run (Win+R) and type \\SERVERNAME to browse the server's shares.
  2. 2If access is denied, first verify network connectivity: ping SERVER_IP.
  3. 3On the server, right-click the shared folder → Properties → Sharing tab — confirm it is shared with correct permissions.
  4. 4Confirm File and Printer Sharing is enabled in Windows Firewall settings on the server.
  5. 5Ensure the server is powered on and connected to the same network as the client.
15
🛑 SQL Server Service Stopped
Root Cause: SQL Server service crashed or was manually stopped
HIGH ⌄
⚠️ All BUSY users are unable to work until this service is restored. Prioritize immediately.
✅ Solution Steps
  1. 1Open services.msc on the server.
  2. 2Find SQL Server (MSSQLSERVER) or the named instance (e.g., SQL Server (SQLEXPRESS)).
  3. 3If the status shows "Stopped", right-click and select Start.
  4. 4Wait 30–60 seconds and verify the status changes to "Running".
  5. 5If the service fails to start, open Event Viewer (eventvwr.msc) → Application and System logs for the exact error code.
💻 Commands
services.msc -- Open Windows Services Manager eventvwr.msc -- Open Event Viewer to review failure logs
16
🔌 Port 4444 Closed / Unreachable
Root Cause: Windows Firewall blocking the port or TCP/IP disabled
MEDIUM ⌄
✅ Solution Steps
  1. 1From the client, test port reachability: telnet SERVER_IP 4444. A blank screen = port open. Connection refused = port blocked.
  2. 2On the server, open Windows Firewall (wf.msc) → Inbound Rules → New Rule → Port → TCP → enter 4444 → Allow the connection.
  3. 3Open SQL Server Configuration Manager → SQL Server Network Configuration → Protocols → ensure TCP/IP is Enabled.
  4. 4Restart the SQL Server service from services.msc for changes to take effect.
💻 Commands
telnet SERVER_IP 4444 -- Test if port 4444 is reachable wf.msc -- Windows Firewall Advanced Settings services.msc -- Restart SQL Server after changes
17
🚫 SQL Login Failed
Root Cause: Authentication mode wrong or login is disabled
HIGH ⌄
✅ Solution Steps
  1. 1Verify the SQL username and password configured in BUSY's company connection settings.
  2. 2In SSMS, check whether the SQL login exists and is enabled: Security → Logins → right-click → Properties → Status tab.
  3. 3Confirm SQL Server Authentication (Mixed Mode) is enabled: right-click server → Properties → Security → select SQL Server and Windows Authentication Mode → restart SQL service.
  4. 4Reset the password if required and update BUSY connection settings accordingly.
💻 SSMS Commands
-- List all SQL logins and check if they're enabled SELECT name, is_disabled FROM sys.sql_logins; -- Enable a specific login ALTER LOGIN UserName ENABLE; -- Reset login password ALTER LOGIN sa WITH PASSWORD = 'NewPassword';
18
💿 Disk Space Full
Root Cause: Server storage is critically low or exhausted
MEDIUM ⌄
⚠️ A full disk prevents backups, log growth, and new transactions. Resolve promptly to avoid service disruption.
✅ Solution Steps
  1. 1Open diskmgmt.msc and check free space on all drives — especially the SQL data and log file drive.
  2. 2Use Windows Explorer or WinDirStat to identify the largest space consumers on the drive.
  3. 3Delete old redundant backup files (.BAK) that are no longer needed.
  4. 4Clear the Windows Temp folder and recycle bin for quick space recovery.
  5. 5Move backup files to a secondary drive or network storage; request a disk capacity increase if the drive is consistently full.
💻 Command
diskmgmt.msc -- Check disk space and volumes
19
🖥 Company Opens on Server Only (Not on Clients)
Root Cause: Firewall blocking client-to-server SQL access
MEDIUM ⌄
✅ Solution Steps
  1. 1From a client machine, verify LAN connectivity: ping SERVER_IP.
  2. 2Test shared folder access from the client: open Run and type \\SERVERNAME.
  3. 3Test SQL port from client: telnet SERVER_IP 1433. If this fails but ping works, the firewall is the issue.
  4. 4On the server, open wf.msc → Inbound Rules → add a new rule allowing TCP port 1433.
  5. 5Confirm SQL Server and SQL Browser services are both running on the server: services.msc.
💻 Commands
ping SERVER_IP -- Check LAN from client \\SERVERNAME -- Test shared folder access telnet SERVER_IP 1433 -- Test SQL Server port wf.msc -- Add port 1433 firewall rule services.msc -- Verify SQL services
20
👤 Only One User Affected
Root Cause: Local machine or BUSY client configuration issue
LOW ⌄
💡 If all other users are working fine and only one is affected, the issue is almost certainly local to that machine.
✅ Solution Steps
  1. 1Network check: From the affected machine run ping SERVER_IP to confirm it can reach the server.
  2. 2Shared folder: Open Run → type \\SERVERNAME and verify the BUSY shared folder is accessible.
  3. 3SQL port: Run telnet SERVER_IP 1433 to confirm SQL port is reachable from this machine specifically.
  4. 4BUSY client settings: Open BUSY on the affected machine and verify — correct server name/IP, correct database selected, and valid login credentials.
  5. 5If all checks pass, try reinstalling or repairing the BUSY client on that machine.
💻 Commands
ping SERVER_IP -- Verify network from this client \\SERVERNAME -- Test shared folder access telnet SERVER_IP 1433 -- Test SQL connectivity from client
💾 SQL & System Command Reference

Consolidated reference of every command used in this guide, organized by category.

🗄 SQL Server Commands (Run in SSMS)

CommandPurposeIssue
SELECT name, state_desc FROM sys.databases;Check status of all databases#3
SELECT name, is_disabled FROM sys.sql_logins;List all SQL logins and enabled status#17
ALTER LOGIN sa ENABLE;Enable a disabled SQL login#4, #17
ALTER LOGIN sa WITH PASSWORD = 'Busy@1234';Reset a SQL login password#5, #17
ALTER DATABASE [DB] SET EMERGENCY;Put database into emergency read-only mode#2
ALTER DATABASE [DB] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;Switch to single-user mode#2
DBCC CHECKDB ([DB], REPAIR_ALLOW_DATA_LOSS);Repair database corruption (may cause data loss)#2
ALTER DATABASE [DB] SET MULTI_USER;Return database to normal multi-user mode#2

🖥 Windows System Commands

CommandPurposeIssues
services.mscWindows Services Manager — start/stop SQL services#1, #3, #9, #15, #16, #19
ping SERVER_IPTest ICMP network connectivity to server#1, #9–#10, #13–#14, #19–#20
telnet SERVER_IP 1433Test SQL Server default port connectivity#9, #10, #19, #20
telnet SERVER_IP 4444Test BUSY custom port connectivity#16
ipconfigView IP address, subnet mask, and gateway#13
diskmgmt.mscDisk Management — check free space on all volumes#3, #7, #8, #18
taskmgrTask Manager — monitor CPU, RAM, and disk usage#6, #10
resmonResource Monitor — detailed process analysis#6
wf.mscWindows Firewall Advanced Security settings#6, #16, #19
eventvwr.mscEvent Viewer — Windows and application error logs#15
UserAccountControlSettingsUser Account Control (UAC) settings#6
\\SERVERNAMEBrowse network shares on the server (Run dialog)#9, #14, #19, #20
❓ Frequently Asked Questions

Common questions from BUSY support calls, answered clearly and concisely.

💬 What is the default SQL port for BUSY and should I always use 1433? ⌄
Yes, the default SQL Server port is 1433. BUSY also uses port 4444 for its own communication layer. Both ports should be open in Windows Firewall on the server. Always test both: telnet SERVER_IP 1433 and telnet SERVER_IP 4444.
💬 Should I use REPAIR_ALLOW_DATA_LOSS as a first step for a SUSPECT database? ⌄
No. Use REPAIR_ALLOW_DATA_LOSS only as a last resort when no valid backup exists. It can permanently delete corrupted data. Always restore from a healthy backup first if one is available.
💬 Why does BUSY work on the server but not on client machines? ⌄
When BUSY runs on the server itself it connects via localhost — no network needed. When clients connect remotely they need: TCP port 1433 open in Windows Firewall, the SQL Browser service running, and TCP/IP enabled in SQL Server Configuration Manager. Check all three systematically.
💬 What credentials do I use when resetting the SA password? ⌄
Log into SQL Server with a Windows Administrator account using Windows Authentication mode, then run ALTER LOGIN sa WITH PASSWORD = 'NewPassword';. Always use a strong password with uppercase, lowercase, numbers, and symbols. Update BUSY's company connection settings immediately after resetting.
💬 How often should backups be taken for BUSY databases? ⌄
For active daily-use BUSY installations, a minimum of one full backup per day is recommended — ideally at end-of-business. For high-transaction environments, consider differential backups every few hours. Always store backups on a separate drive from the SQL database files.
💬 How do I identify which session is causing SQL blocking? ⌄
Run this query in SSMS to identify blocking sessions:

SELECT blocking_session_id, session_id, wait_type, wait_time FROM sys.dm_exec_requests WHERE blocking_session_id <> 0;

To terminate a blocking session: KILL session_id; — this rolls back the active transaction, so use it carefully.
💬 Which SQL Server Authentication mode is required for BUSY? ⌄
BUSY requires SQL Server and Windows Authentication Mode (Mixed Mode). To enable it: right-click the server in SSMS → Properties → Security tab → select "SQL Server and Windows Authentication mode" → click OK → restart the SQL Server service.
BUSY Software — MSSQL Troubleshooting Guide BUSY Support Team  ·  Internal Use Only