SQL Server + Querri
Your ERP and line-of-business systems already keep their numbers in SQL Server. Ask about margin, receivables or shipments in plain language, and Querri answers from a copy of those tables, joined with your other systems and your own definitions.
Querri only ever reads from SQL Server, and it never changes a row. Passwords are stored encrypted. SOC 2 Type II, HIPAA and ISO 27001:2022 certified.
Why SQL Server reporting gets hard
Finance and operations teams on SQL Server-based systems tend to hit the same five walls. Each one is a sensible choice by someone; together they leave simple questions waiting for days.
ERP schemas speak in codes like RM20101 and SOP30300, and homegrown systems have their own tblCust and Status = 4. Knowing which table holds open invoices is tribal knowledge.
Nobody wants an ad-hoc query locking the order tables at month end. So every new question becomes a request, and the request waits behind the ones that keep the business running.
Microsoft says no new version of SQL Server Reporting Services will be released, and on-premises reporting moves to Power BI Report Server. Teams with years of SSRS reports are deciding what comes next.
A server on the office network is invisible to cloud BI. Power BI's service, for one, needs an on-premises data gateway: Windows software someone installs inside the network and keeps running.
The query result gets pasted into a workbook, emailed, and edited. A sheet stops at 1,048,576 rows, and by Thursday there are four versions of Monday's numbers.
What you can finally answer
Each one comes from finance and operations teams whose ERP or in-house system runs on SQL Server: the question, why it stalls today, and what Querri does with it.
Why it's hard
Revenue sits on invoice lines, cost sits on the item or receipt tables, and product line sits on the item master. The canned ERP report shows one cut, never the one finance asks for.
With Querri
Querri joins the three in the Library once, and you say which cost counts in Facts & rules. Margin then lives as a KPI that keeps its own history from the day you start.
Why it's hard
An aging report shows buckets as of today. Spotting the customer who used to pay in 30 days and now takes 55 means comparing months, which nobody does by hand for every account.
With Querri
Monitors in Nightly insights check each customer's days-to-pay against its own past, using arithmetic. The ones that slipped are listed in your Inbox before the collections call.
Why it's hard
The person with the question knows the business; the person who can write the query knows the schema. The handoff between them is where days go.
With Querri
Ask in chat. Querri checks the tables for gaps and duplicates first, works the answer out two ways, and shows the query behind every number. See how answers are checked.
Why it's hard
Shipments live in the warehouse or order system on SQL Server, invoices often live in QuickBooks or NetSuite. Matching them is a monthly spreadsheet exercise.
With Querri
Connect QuickBooks or NetSuite beside SQL Server. Querri matches orders to invoices on customer and amount, returns the unmatched ones as a list, and says how it matched them.
Why it's hard
Someone runs the query, pastes it into last week's workbook, fixes the formatting and emails it. If they're on vacation, so is the report.
With Querri
Build it once as a project. A schedule reruns it on the latest sync and sends a formatted workbook, one per branch or manager if you want. See Excel tools.
Why it's hard
Order history is in SQL Server and the sales pipeline is in Salesforce or HubSpot. Customer names rarely match exactly across the two.
With Querri
Bring Salesforce or HubSpot into the same Library. Querri matches accounts across systems and flags the matches it isn't sure of, so sales sees which top buyers nobody is working.
Why it's hard
Status 4 means shipped, unless it's a credit memo. That knowledge lives in two people's heads and one wiki page from 2014.
With Querri
Say it once in plain words and Querri applies it to every answer. Data cleansing handles codes spelled several ways, and Visualize maps how each table connects to the rest of your systems.
Why it's hard
Pointing an assistant straight at a production database means a login, a guess at the schema, and a different answer each time someone asks.
With Querri
Once Querri is linked to Claude or ChatGPT, the assistant answers from the Library's copy, with your definitions, and each person sees only the rows their access allows. Nobody's chat touches the server.
SQL Server plus the rest
Orders and inventory sit in SQL Server. The books might be in QuickBooks, the pipeline in Salesforce, the budget in a spreadsheet. Querri brings them into one Library, so a question about the business can cross from one to the next.
SQL Server pairs well with
Answers you can stand behind
In an ERP, last month's sales can be counted by invoice date or by ship date. Both are fair, and at month end they rarely agree. Querri picks one, names it and shows the other, so finance and operations argue about the business instead of the cutoff. See how answers work.
Wake up to what changed
Each night Querri compares your KPIs with their own history, branch by branch and customer by customer, and looks for the slice nobody thought to check. By morning the results are in your Inbox, and none of them changes anything until you say so.
Custom SQL Server dashboards
Ask for the view you want, or hand Querri a screenshot of the SSRS or Excel report people already know. After that, you change it by asking. Every chart reads from the same Library as chat, and each branch manager can be limited to their own branch's rows.
Reports you can stop rebuilding
Revenue and landed cost from the ERP, tracked week over week.
See KPIsOpen receivables by bucket, plus customers paying slower than they used to.
See monitorsOrders, shipments, backlog and returns, emailed every Monday.
See reportsEach branch manager gets a formatted workbook with only their branch.
See Excel toolsOrder history, volume trend and open issues for each key account.
Read the playbookOrders out the door with no matching invoice in your accounting system.
See projectsWhat comes over
After you connect, Querri lists the databases and schemas the login can see. You pick tables and views, and each sync copies them into Querri. It can only read what that SQL Server login is allowed to read.
What you can pick
Every sync reads the selected tables again from the top, up to the row limit, so rows deleted in SQL Server drop out too. Run it on a schedule or by hand. There's no incremental or change-data-capture mode.
Up to 1,000,000 rows per table by default, taken in key order on the server so the same rows return each sync. Untick the limit to take everything; a cut-short table is labeled.
Querri only ever reads from SQL Server and never changes a row. Custom queries containing write, schema or permission statements are refused, and we ask you to connect with a read-only login.
The password, and any VPN certificates and keys, are stored encrypted. The Connector Agent never reads them; it only knows whether they're set.
How to connect SQL Server
Open Connect and say "connect our SQL Server," or pick Microsoft SQL Server from the catalog.
Server, port (1433 by default), database and schema (dbo by default), plus a SQL Server username and password in a secure form. Set the encryption and certificate options to match your server.
If the server is only on your private network, upload an OpenVPN profile and its certificates. The tunnel opens only for the connection test and each sync.
Querri lists what the login can see, with approximate row counts. Take every table, pick a few, or add your own SQL queries.
No table is copied until you click Approve. Once you do, the tables appear in your Library and you can start asking.
SQL Server FAQ
Tell the Connector Agent "connect our SQL Server", or choose Microsoft SQL Server in the catalog. Enter the server, port, database, schema and a SQL Server login, choose the tables and views to bring over, then approve the load. If the server is on a private network, you can add an OpenVPN tunnel.
The base tables and views you choose from the schema you pick, or every table in it. Querri shows an approximate row count for each table as you choose. You can also add custom SQL queries, and each becomes its own dataset. Querri can only read what the connected login can read.
On the schedule you set, and you can run a sync by hand at any time. Each sync is a full refresh: Querri re-reads the selected tables, so changes and deletions in SQL Server both show up. Questions and dashboards run on that copy, not live against your server.
No. Querri only reads from SQL Server and never changes your records. Custom queries that contain insert, update, delete, schema or permission statements are refused. Because that check can't catch everything, such as stored procedures run with EXEC, connect with a login that has read-only rights.
Querri can only see the databases, schemas, tables and views that the SQL Server login you connect with can read, so give that login exactly the access you want in Querri. Once the data is in Querri, row visibility follows Querri's sharing settings and the row filter set for each person; individual SQL Server grants don't carry over.
Yes, through an optional OpenVPN tunnel. You upload the .ovpn profile, CA certificate, client certificate and client key, which are stored encrypted. The tunnel opens only for the connection test and each sync. There's no SSH tunnel option, and we don't publish fixed IP addresses for allowlisting here; ask us before opening a firewall rule.
Querri connects with a SQL Server login: a username and password you create for Querri, with read access to the databases you want. It goes into a secure form the Connector Agent never sees. If your servers allow only Windows or Entra ID sign-in, talk to us before you connect.
Connect both, and Querri brings them into the same Library. A common use is matching shipped orders in your SQL Server system to QuickBooks invoices and payments by customer and amount, which turns up orders nobody billed. Querri says how it matched records and flags the uncertain ones.
Connect both, and Querri matches ERP customers to Salesforce accounts even when the names differ slightly, and says when a match could be off. Then you can ask which big buyers have no open opportunity, or compare quoted pipeline with what customers actually ordered last year.
Connect the ERP tables that hold invoice lines, item costs and the item master. Tell Querri once which cost to use, for example landed rather than standard cost. Then ask for margin by product line or customer, and track it as a KPI so its history builds week by week.
Connect the receivables tables and ask for open invoices by aging bucket and customer. Save it as a project and schedule it to send each Monday. A nightly monitor can also flag customers who are paying slower than their own history, which a static aging report won't show.
Set the report up one time as a Querri project and put it on a schedule. Each run uses the latest sync and sends a formatted Excel workbook by email, and it can send a separate version to each branch, region or client with only their rows. No one pastes query results by hand.
Yes. Say what the dashboard should show, or start from a screenshot of an SSRS page or workbook your team relies on. Edits are requests in plain words, a single dashboard can pull from SQL Server and your other connected systems, and a branch manager can be restricted to their branch. Querri works alongside the BI tools you already have.
Yes. Link Querri to Claude or ChatGPT, and the assistant draws on the ERP tables in your Library, applies the rules you've written there, and stays inside each person's Querri access. Your database login is never handed to the assistant, and its questions run on Querri's copy rather than on your server.
Yes. Add a custom query in the connector, preview its first rows with the Test button, and each query becomes its own dataset on every sync. Write, schema and permission statements are refused. Custom queries aren't subject to the per-table row limit, so add your own TOP or WHERE clause on very large tables.
By default Querri takes up to 1,000,000 rows per table, using TOP on the server and ordering by the primary key or a unique index so each sync returns the same rows. Untick the limit to take every row. When a table is cut short, Querri records it on the dataset and tells you.
Not today. Every SQL Server sync is a full refresh that re-reads the chosen tables, up to the row limit, so Querri doesn't keep a row-by-row change log. For history over time, track the numbers that matter as KPIs, which keep their own history from the day you start.
Questions, dashboards and reports run on Querri's copy, not on your server. The load comes from each sync, which reads the selected tables in chunks, with a 30-minute default limit on each database call. Choose only the tables you need, or connect Querri to a reporting replica if you have one.
Querri is SOC 2 Type II, HIPAA and ISO 27001:2022 certified, and your data is never used to train a model. The database password and any VPN keys are stored encrypted, the Connector Agent never sees them, and Querri only ever reads from SQL Server.
Keep exploring
Connect it in a few minutes with a read-only login. Querri reads your tables and never changes them.