Most chiropractic practices that run server-based ChiroTouch have a single computer in the back office or under the front-desk counter that quietly holds the entire operational record of the practice. That machine—often the first computer ChiroTouch was installed on during initial training—is the server. It stores the SQL Server database that powers every module your front desk, providers, and billing staff interact with throughout the day. If that server goes down, every workstation that pulls data through the \\SERVERNAME\CTData network path loses access to scheduling, patient charts, ledgers, and reporting in one fell swoop.

What Is Actually Stored in the Server Database

The local SQL Server instance holds far more than a simple list of names and phone numbers. Based on the ChiroTouch data model, the server database contains patient demographic information, treatment notes, patient records (including videos, photos, X-rays, and documents), chart notes, diagnoses, charges, ledger entries, insurance information, and full appointment history. When your front desk posts a charge, when a provider documents a session, or when the billing team runs an end-of-day transaction report, all of those actions read from and write to that single database on the server machine. The CTData folder, which workstations access over the wired network, is the shared directory through which the application communicates with the database.

Understanding this architecture matters for several practical reasons. First, ChiroTouch version 6.0 and higher requires Microsoft SQL Server 2005 or later, and Windows 10 support begins at ChiroTouch 6.3.29 with SQL Server 2012 or higher. That means the server is not just a file cabinet; it is a running database engine with its own service accounts, transaction logs, and growth files. Second, the ChiroTouch documentation specifically warns against wireless connections to the server, noting that they can cause data loss, and recommends a wired connection for the main server. If your office has recently renovated or moved equipment, verifying that the server remains on a hard-wired Ethernet link is a quick check that prevents intermittent connection errors like the "Error 76, Lost connection to the directory" message that workstations display when they lose the network path to CTData.

For office managers and practice owners, the practical takeaway is that the server is a single point of operational dependency. When a workstation shows a system time error or an optimistic concurrency failure, the troubleshooting steps in the ChiroTouch knowledge base almost always point back to the workstation's connection to the server. If you are a doctor who occasionally works from a home office and accesses ChiroTouch through a remote session, or a billing specialist who processes claims after hours, you are still ultimately reading from that one server-side database. The ChiroTouch Community support team will ask for your account number first—if it starts with CTC you are on ChiroTouch Cloud, and if it does not, you are on the server-based version, and the support phone number differs between the two (Cloud: 619-854-2998; Server: 844-307-4901).

Knowing what sits on that server also frames the conversation about data continuity. The patient-file export feature in ChiroTouch Front Desk can bundle a patient's information, notes, treatment notes, and records into a folder on the server for transfer to another facility, but that process requires the server to be online and the CTData path to be accessible. If the server's SQL instance is down or the CTData folder is unreachable, no export, no import, no new patient check-in, and no ledger posting can occur. For practices that have outgrown a single server or that want an additional layer of assurance that the data on that one machine is replicated off-site, understanding the local data architecture is the first step in deciding what to protect and how. Whether you are a provider reviewing your own records, a front-desk lead troubleshooting a check-in kiosk, or a support representative walking a practice through a network-permission mapping, the starting point is the same: identify the server, confirm the CTData path, and verify that the SQL Server service is running.

Sources and further reading