Pilot estimate
About 35 minutes after driver validationUnproven estimate for a future founder-assisted pilot.
Connection guide · On-premise SQL Server / MySQL
On-premise SQL POS connection validation blueprint
Status: core lab-proven; production driver pending. The read-only reconciliation path passes on simulated POS data. A production database driver and a real-store read-back are still required.
Do not run these steps today. They are future-pilot acceptance criteria, not an available installer or self-serve connection. A vendor-specific mapping is required in addition to the generic database driver.
Many on-premise point-of-sale systems keep data in SQL Server or MySQL on the store network. This blueprint maps the intended least-privilege path: a real database driver, a vendor-specific schema map, a read-only login, an outbound-only connector, and a matching real-store read-back.
Written for design review, not execution. Placeholders such as <YOUR_POS_DB> show what a founder-assisted pilot would have to map. StoreRounds does not currently provide the vendor-specific table names, installer, or setup screen described below.
Pilot support
Founder-assistedNo self-serve installer or generic driver is available.
A future pilot would require
IT review firstThe exact POS, version, schema, database host, and a safe least-privilege path.
Running example throughout: a fictional two-store chain, Aurora Beauty Supply (Riverside and Eastgate). Every number shown is made up for the example. Your screen shows your real stores.
First, the honest description
What is the proposed StoreRounds connector boundary?
No generic production SQL connector is available. The proposed edge program would run on an approved back-office computer, use a vendor-specific map and named read-only database user, minimize the approved daily fields locally, and send them outward over an encrypted connection. Every control below is a future-pilot acceptance criterion.
What it is
- A read-only reader. A validated driver must run named SELECT queries and nothing else.
- Outbound only. A pilot must open only an outbound connection and no inbound listener.
- Scoped to named tables. Access must be limited to reviewed tables in a vendor-specific map, never the whole database.
- Yours to switch off. Dropping the database user or uninstalling the pilot agent must end new reads.
- Self-reporting. A supported adapter would need a truthful health log for reads, gaps, retries, and unresolved errors.
What it is not
- It must be not a writer. The pilot database user must be denied insert, update, delete, execute, and schema changes.
- It must be not an open door. The pilot design must require no inbound port or firewall rule.
- It is not a remote-control tool. No one at StoreRounds gets a login to your computer or your POS.
- It must not touch payment card data. The approved map would include aggregate totals and counts, not card numbers.
- It must be not surveillance. The intended output is store-level operational exceptions, not employee scoring.
For your IT person
A technician or managed-services provider can review the proposed controls in the one-page connector security brief. It is a design brief, not evidence of a deployed connector.
The shape of it
How would the proposed connection fit a multi-machine store?
The diagram shows an intended topology for future validation. A pilot edge agent would sit near the database and make outbound-only calls after local minimization. StoreRounds has not shipped or production-proven this generic driver.
Two facts worth repeating, because they are the whole security story:
- A pilot connector would have to read over the local network and send only the reviewed, minimized fields.
- The pilot connection would have to be outbound only, with no new inbound firewall rule or listener.
Where the connector lives
A founder-assisted pilot would decide whether an approved edge agent belongs on the database host, another always-on LAN computer, or an reviewed HQ host. That choice depends on the actual POS, network, schema, and IT approval. Do not deploy from this generic blueprint.
Archived validation runbook
What would a future founder-assisted SQL pilot have to validate?
Do not run these steps today. There is no generic StoreRounds driver, installer, setup screen, or one-time code. The five stages preserve acceptance criteria for a future vendor-specific pilot.
1
Planned stage: create a least-privilege database user
Future approved pilot only · timing unproven
A future pilot would create a dedicated login only after the vendor-specific table map is reviewed. The examples below show the intended least-privilege boundary but must not be run with placeholders or guessed table names.
Future pilot prerequisites
1. Exact vendor mapping. A founder and the owner's IT reviewer would identify the database, schema, and minimum named tables. No StoreRounds setup screen supplies these values today.
2. Authorized database administration. An approved IT administrator would review and execute any SQL using the database's normal administration tool. StoreRounds must never ask an owner to guess a schema or run an unreviewed grant.
Before you paste
These blocks are non-executable documentation. A future pilot must replace every placeholder from a reviewed vendor map, use a strong unique secret, and obtain explicit IT approval before execution.
SQL Server (Microsoft SQL Server)
-- 1. Create a server login with a strong password. USE [master]; CREATE LOGIN [storerounds_ro] WITH PASSWORD = '<STRONG_PASSWORD>', CHECK_POLICY = ON; GO -- 2. Map it to a user inside your POS database. USE [<YOUR_POS_DB>]; CREATE USER [storerounds_ro] FOR LOGIN [storerounds_ro]; GO -- 3. FUTURE PILOT ONLY: grant SELECT on the tables a validated adapter would read. -- Do NOT add this user to db_datareader (that reads everything). GRANT SELECT ON OBJECT::dbo.<SALES_TABLE> TO [storerounds_ro]; GRANT SELECT ON OBJECT::dbo.<SALES_LINE_TABLE> TO [storerounds_ro]; GRANT SELECT ON OBJECT::dbo.<TENDER_TABLE> TO [storerounds_ro]; GRANT SELECT ON OBJECT::dbo.<STORE_TABLE> TO [storerounds_ro]; GO -- 4. Belt and suspenders: explicitly deny anything that changes data. DENY INSERT, UPDATE, DELETE, EXECUTE, ALTER, CONTROL TO [storerounds_ro]; GO
MySQL or MariaDB
-- 1. Create a dedicated read-only user. -- FUTURE PILOT OPTION: if an approved agent were placed on the -- database machine itself, a host-scoped user could use -- 'storerounds_ro'@'localhost' in every line below instead. -- '10.0.0.%' is an EXAMPLE LAN range for a multi-machine store; -- change it to match your own network (many are '192.168.1.%'). CREATE USER 'storerounds_ro'@'10.0.0.%' IDENTIFIED BY '<STRONG_PASSWORD>'; -- 2. FUTURE PILOT ONLY: grant SELECT on the tables a validated adapter would read. -- Never GRANT SELECT ON <YOUR_POS_DB>.* , that reads every table. GRANT SELECT ON `<YOUR_POS_DB>`.`<SALES_TABLE>` TO 'storerounds_ro'@'10.0.0.%'; GRANT SELECT ON `<YOUR_POS_DB>`.`<SALES_LINE_TABLE>` TO 'storerounds_ro'@'10.0.0.%'; GRANT SELECT ON `<YOUR_POS_DB>`.`<TENDER_TABLE>` TO 'storerounds_ro'@'10.0.0.%'; GRANT SELECT ON `<YOUR_POS_DB>`.`<STORE_TABLE>` TO 'storerounds_ro'@'10.0.0.%'; -- 3. Apply. FLUSH PRIVILEGES;
Verify stage 1
Confirm the user can read, and only read. On SQL Server, run EXECUTE AS USER = 'storerounds_ro'; SELECT TOP 1 * FROM dbo.<SALES_TABLE>; REVERT; and check that it returns a row. On MySQL, run SHOW GRANTS FOR 'storerounds_ro'@'10.0.0.%'; and confirm you see only SELECT on the tables you named. If you see any grant other than SELECT, remove it before continuing.
2
Planned stage: receive an approved, signed pilot build
No customer download exists today
- StoreRounds would first approve the exact POS, version, driver, schema map, and owner for a named pilot.
- The owner's IT reviewer would receive a build hash, requested network access, rollback steps, and the exact data map before installation.
- The pilot build must be code-signed before it is offered to a customer. No unsigned customer download is available from this page.
- A one-time pairing mechanism would have to expire after 30 minutes, work once, bind only the approved pilot record, and automatically retire a never-used attempt at expiry without touching paired connections or history.
Verify stage 2
Acceptance criterion: the future pilot must show the approved host, build identity, pairing time, and a truthful paired or failed state. This screen is not live today.
3
Planned stage: configure the reviewed database endpoint
Future approved pilot only · timing unproven
- In the connector window, choose your database type: SQL Server or MySQL / MariaDB.
- Enter the server address (often localhost if the connector is on the database machine, otherwise the server's name or LAN address like 10.0.0.20) and the port (SQL Server default 1433, MySQL default 3306).
- Enter the database name <YOUR_POS_DB>.
- Enter the user storerounds_ro and the password you set in stage 1.
- Click Test connection.
Verify stage 3
Acceptance criterion: a future pilot must prove it can read only the named vendor objects and cannot write. The customer-facing connected state described here is not live.
4
Planned stage: map approved store codes
Future founder-assisted pilot · timing unproven
A future vendor-specific driver would return store codes from the reviewed table map. A human would have to name, include, or exclude each code before reporting. Aurora Beauty Supply is fictional example data.
- Acceptance criterion: a future adapter would return only reviewed store codes, and the owner would map each one to a real location.
- A warehouse, training register, or closed location would have to be excluded before the pilot read-back.
- Set each store's day cutoff (when the sales day ends, for example 11:00 PM) and time zone, so the daily totals line up with your own Z-report.
Verify stage 4
Future verify condition: the reviewed store list must show the right number of active locations with the right names. The fictional Aurora example shows exactly two: Riverside and Eastgate. A missing code would fail the pilot until its mapping and least-privilege grant are reviewed.
5
Required gate: run a real-store read-back
Future founder-assisted pilot only
This would be the release gate. A future pilot would compare a StoreRounds read-back with the owner's POS report. Only a matching real-store result could mark the driver and vendor mapping verified and schedule a first Morning Flash.
Receipts from minute one
How would a pilot prove the driver read the right store and numbers?
A founder-assisted pilot would select one closed sales day, read one approved store through the vendor-specific driver, and compare those totals with the owner's trusted Z-report or daily sales summary. The driver must remain unsupported until the values match and the owner confirms the definitions.
Verified Read-back test Aurora Beauty Supply, Riverside · sales day of the example
| Future pilot field | Fictional adapter result | Fictional POS report | Example match |
|---|---|---|---|
| Gross sales | $8,412.70 | $8,412.70 | Yes |
| Transactions | 143 | 143 | Yes |
| Cash tendered | $1,905.00 | $1,905.00 | Yes |
| Card tendered | $6,507.70 | $6,507.70 | Yes |
Fictional validation example only. No customer POS data or production read-back is represented.
To pass the read-back test
- The future pilot would initiate a read-back for one approved store and closed date.
- In your POS, open that store's Z-report or daily sales summary for the same date.
- Compare gross sales, transaction count, and the cash and card split. They should match to the cent.
- If a future pilot matches, the owner would confirm the reconciliation. Only then could the connection be marked verified and a first Morning Flash be scheduled.
If the numbers are close but not exact
A future pilot must stop on any mismatch. Likely investigation points include the day cutoff, tax-inclusive versus tax-exclusive totals, and returns and voids. No Morning Flash should be scheduled until the owner confirms a clean match.
When a stage will not pass
Which failure modes must a future pilot handle?
These troubleshooting notes are acceptance criteria for a future approved pilot, not support for a connector available today.
The connection test fails with "cannot reach server"
Future pilot scenario: an approved agent could fail to reach the database because of the host, instance, port, or local-network route. The pilot would stop for authorized IT review.
Future pilot diagnostic: an authorized technician would verify the approved server address and local-network route. A same-host agent could use localhost; a separate approved host would use the server's LAN address. Typical ports are 1433 for SQL Server and 3306 for MySQL. Named instances and TCP/IP settings would be reviewed before any connection attempt.
"Login failed for user storerounds_ro"
Future pilot diagnostic: a refused login would require an authorized technician to re-check the approved credential and host scope. On MySQL, the host part must match the approved agent host; on SQL Server, a SQL login requires mixed-mode authentication. No generic StoreRounds agent exists to run this test today.
"Read-only confirmed" but a table is missing
Future pilot diagnostic: if an approved adapter could sign in but not read a reviewed object, the pilot would stop for a schema and grant review. The vendor-specific map, not a customer guess, must name the exact object and schema before an authorized administrator changes any SELECT grant.
The store list is missing a location, or shows extras
Future pilot diagnostic: training registers, warehouse codes, and closed stores would be reviewed and excluded by the owner. A missing active store would fail validation until its vendor mapping and least-privilege grant are confirmed.
The read-back numbers are off by a consistent amount
A steady gap can reflect a definition difference: day cutoff, tax treatment, or how returns and voids are counted. In a future pilot, the owner and StoreRounds would document the approved definition and repeat the read-back until it matched the owner's report to the cent. Until then, the adapter would remain unverified.
The connector went offline overnight
A supported pilot agent would need bounded retries, a receipted gap, and an explicit unresolved-offline alert. Those behaviors are not production-proven. Host uptime, sleep settings, and database service health would be reviewed with the owner's IT contact.
Still stuck
A future supported connection would need a truthful health record with recent reads, retries, gaps, and the exact unresolved error. This health view is an acceptance criterion, not a live generic SQL feature.
Your off switch
How must a future SQL pilot prove revocation?
No customer SQL connector is installed today. A future pilot must prove two independent stop paths: disabling the edge agent and dropping its least-privilege database user. Either must stop new reads.
Required switch 1: disable and remove the pilot agent
The future pilot must provide a verified pause, unpair, and uninstall path that removes its working credential. No such customer control is live today.
Required switch 2: drop the pilot database user
Dropping the dedicated read-only user is the source-side stop. The commands below are review examples for a future pilot and must be adapted by the authorized database administrator.
USE [<YOUR_POS_DB>]; DROP USER [storerounds_ro]; GO USE [master]; DROP LOGIN [storerounds_ro]; GO
DROP USER 'storerounds_ro'@'10.0.0.%'; FLUSH PRIVILEGES;
Verify the revoke
Future pass condition: the database query returns no pilot principal, the agent has no working secret, and an attempted read fails closed. An authorized administrator would document that result.
What a future pilot could keep, and must not
In a future pilot, revoke must stop new reads. Until self-serve data controls ship, export and deletion requests would go through [email protected].
Quick answers
Frequently asked questions
Status for every answer below: no generic production SQL POS driver is live. These answers are intended pilot controls that require vendor-specific proof.
Can StoreRounds change or delete anything in my POS?
No production generic SQL connector exists today. A future vendor-specific pilot would have to prove that its dedicated user is limited to named SELECT grants and cannot insert, update, delete, execute, or alter data.
Do I have to open a port in my firewall?
A future vendor-specific pilot is designed to require no inbound firewall rule. Its acceptance criterion is outbound HTTPS on port 443 after an approved agent reads only reviewed objects over the local network. No generic SQL agent is available to install today.
Which POS systems does this guide cover?
An on-premise Microsoft SQL Server or MySQL / MariaDB database can be a candidate architecture, but database engine alone does not make a POS supported. A future pilot would still require a vendor-specific driver, reviewed schema map, revocation proof, and matching real-store read-back. No generic SQL adapter is available today.
What would a future vendor-specific connector read?
The intended minimum is reviewed sales-header, line, tender, and store objects, returning aggregate totals, counts, and store codes without full card numbers. The exact map does not exist for customers today and must be approved before a pilot.
How long does the whole setup take?
The blueprint estimates about 35 minutes after a vendor-specific driver and schema map exist. That estimate has not been tested with a real customer and is not a current setup promise.
Does my IT person need to approve this?
Any future SQL pilot would require an authorized database administrator to review the vendor-specific map and least-privilege grant. The one-page security brief documents proposed controls only; it is not evidence of an available connector.
How do I turn it off later?
No customer connector exists today. A future pilot must prove both edge-agent removal and source-side database-user revocation, with either path stopping new reads.
Founding cohort application
Tell us which POS you run
You can inspect this blueprint without an account. A generic production driver is not live, payments are closed, and applying does not promise a connection date. Suitable applicants will be contacted only if a vendor-specific, founder-assisted validation opens.
A portal account does not unlock a SQL POS adapter. Do not install software or create credentials until StoreRounds confirms an approved pilot.