Why DataXcel Needs a Sage 100 SQL User — And Why It's Safe

Why DataXcel Needs a Sage 100 SQL User — And Why It's Safe

When we onboard a contractor, IT or the controller almost always asks the same three questions:

1. Why do you need a SQL login with sysadmin rights?
2. Isn't that dangerous — what are the risks of giving you that access?
3. Can the access be monitored and audited?

These are exactly the right questions to ask. Here are the honest answers.

What we actually ask for

We ask you to create one dedicated SQL Server login — named dataxcel — on the SQL Server instance behind your Sage 100 Contractor data. We never ask for your Sage application login, your Windows admin password, or anyone's personal credentials. One purpose-built database login, nothing more.

Why it needs sysadmin — that's Sage's rule, not our preference

Here's the part most people don't know: Sage 100 Contractor protects its own SQL database with a built-in security trigger that blocks any SQL login from reading the data unless that login is a sysadmin. This is Sage's own design, not ours. A plain read-only login (db_datareader) is denied — the trigger stops it cold. So to read a Sage 100 Contractor database at all, the connecting login must hold sysadmin.

On top of that, DataXcel builds a reporting data warehouse on your own server — a separate database (we call it dataxcel_analytics) that holds the cleaned, modeled tables your dashboards run on. To do that, the dataxcel login needs to:

• read your Sage company database (the source data for reports) — which Sage gates behind sysadmin, as above, and
• create and maintain the dataxcel_analytics database on the same SQL Server.

So sysadmin is not a convenience we reached for — it's the access level Sage 100 Contractor itself requires to read its database. The login is still a single, named, auditable principal, scoped to one server (more on that below).

The most important point: your data never leaves your server

This is what makes DataXcel fundamentally different from "send us a backup" or cloud-extraction tools.

We build the warehouse on your server. We do not copy, move, or store your data on another system. The modeled tables live in dataxcel_analytics on your SQL Server, right next to Sage. Your dashboards query that database in place.

Why that matters for risk:

• No PII leaves your building. Employee records, client details, financials — none of it is exported to a third-party database where a breach or misconfiguration could expose it.
• No second copy to lose. Many reporting setups extract your data into a vendor's cloud warehouse. That creates a new copy of your sensitive data on someone else's infrastructure — a new thing to secure, a new place it can be accidentally shared, and a new breach target. DataXcel has none of that, because the data stays where it already lives.
• You stay in control. It's your server, your database, your backups, your retention. We're just the engine that models the data and the dashboards that read it.

Is replicating to a data warehouse allowed by Sage?

Yes. Sage's terms of use for Sage 100 Contractor permit replicating your data to a reporting data warehouse. Building dataxcel_analytics on your own server — a modeled copy of your data, used for reporting — is exactly that kind of permitted use, and because it never leaves your server, it's the most conservative form of it. You can review the governing terms yourself on Sage's official legal page: Sage End User License Agreement & terms (Sage 100 Contractor).

Is it dangerous? The real risk picture

Any login with elevated rights deserves respect, so let's be concrete about the actual risk surface:

• The login is scoped to one machine. It only works against your SQL Server, and only over the locked-down, one-port NetBird tunnel we describe in our connectivity white paper — there is no inbound port and no remote desktop.
• It does what reporting needs and nothing customer-facing. We read Sage tables and build/refresh the warehouse. We don't write back to your Sage company data, we don't touch your production transactions, and there's no interactive session for a human to "poke around."
• The password is yours. You set it; we hold it only to run the automated refresh. It can be rotated any time.
• It's revocable in seconds. If you ever want to cut access, disabling or dropping the dataxcel login immediately stops everything — no uninstall, no negotiation.

Yes — it can be monitored and audited

SQL Server gives your DBA full visibility into exactly what the dataxcel login does:

• Login auditing. SQL Server logs every login, including dataxcel, with timestamps and source. You can see precisely when and from where it connects.
• SQL Server Audit / Extended Events. Your team can audit the statements the login runs — every read, every warehouse build — and keep an immutable trail.
• One named principal. Because it's a single, clearly named login (dataxcel), its activity is trivial to filter and review. There's no shared or ambiguous account to untangle.
• Predictable, scheduled behavior. The refresh runs on a schedule, so its activity is regular and easy to recognize — anything unexpected would stand out immediately.

We encourage customers to audit it. Transparency is the point.

Why this is the more secure choice

Put together, this is a tighter security posture than the common alternatives:

	"Send us a backup" / cloud extract	DataXcel
Where your data lives	Copied to a vendor cloud	Stays on your server
PII exposure	New external copy to secure	None leaves the building
Network access	Often a broad VPN or open port	One SQL port, outbound-only
Auditability	Vendor-side, opaque	Your SQL Server logs every action
Revoke access	Vendor process	Drop one login — instant

In one sentence

We ask for a single, named dataxcel SQL login so we can build a reporting warehouse on your own server — your data never moves, the access is fully auditable in SQL Server, it reaches your machine only over a one-port encrypted tunnel, and you can revoke it instantly.

A note for security-conscious DBAs

Because Sage's trigger requires sysadmin to read the Sage database, we can't swap that for a read-only role on Sage itself — Sage simply won't allow a non-sysadmin login to read its data. So we won't pretend otherwise. What we can do, and gladly will:

• Run it only when it's needed. Enable the dataxcel login during the scheduled refresh window and disable it the rest of the time, so it isn't a standing open door.
• Rotate the password on whatever cadence your policy requires — you own it.
• Audit every action. Turn on SQL Server Audit / Extended Events on the dataxcel login so every read and every warehouse build is logged to an immutable trail your team controls.
• Keep reporting least-privilege. Day-to-day access is already least-privilege: your dashboards read the dataxcel_analytics warehouse — which is not behind Sage's trigger — so end users and Metabase never need elevated rights. Only the nightly build process ever touches Sage.

Want help wiring up the audit and the enable/disable schedule before go-live? Just reach out — we'll set it up with your DBA.

---

Related

• How DataXcel Connects to Your Sage 100 Server — Securely, with NetBird and WireGuard
• Microsoft — SQL Server Audit overview
• Microsoft — Server-level roles (sysadmin and alternatives)