Additional data source settings

Do it

1. App display name — friendly name vs registered name

   The name you typed when you registered the data source flows everywhere — App Builder, Composer dropdown, the Library when reports get saved. If that name was cryptic (prod_mssql_clusterB_03) or just unfriendly, override it here.

   Type a friendly name in App Display Name, click Save & Apply, and the new name flows through every surface that shows it. Doesn't change the underlying app — just what users see.

   When to use it: almost always, if the registered name is anything other than the human label you want users to see. Cosmetic, but high-impact for adoption.

2. Connection timeout and Command timeout — leave them alone, mostly

   Two timeouts, two different things, both default-friendly:

   • Connection timeout (default 15 seconds) — how long DashboardFox waits to establish the connection. Hitting this means you have a network problem, not a DashboardFox problem. If a database can't be reached in 15 seconds it usually can't be reached at all. Don't bump this — fix the network instead.
   • Command timeout (default 30 seconds) — how long DashboardFox waits for a query to come back. Most reports return in under a second. If you're seeing 30-second timeouts you're either pulling too much data, the query needs an index, or you're running a long stored procedure.

   When to bump command timeout: long-running stored procedures (financial close, ETL-style aggregations), or unusually heavy analytical queries you can't simplify. Bump it to the smallest value that lets the query finish — 60 seconds, then 120 if needed. Don't set it to 600 "just in case"; that hides real performance problems.

   Generally we recommend not changing these unless our support team has asked you to.

3. Time Zone Offset and Adjust for DST — almost always GMT

   Cloud-hosted databases store timestamps in UTC by default. The defaults in this panel — GMT with DST adjustment off — are correct for nearly every modern database.

   The exception: a corporate, on-premises database server explicitly configured to a local time zone (US Central, etc.) where data was inserted in that local time without UTC conversion. In that case, set Time Zone Offset to match the database's zone, and turn on Adjust for Daylight Savings Time if the database's region observes DST.

   If you're unsure whether your database stores UTC or local time, ask your DBA — the question is "are timestamps in this database stored as UTC, or as local server time?" That's the only useful test.

4. Allow Direct SQL and Allow Stored Procedures — half of a switch

   These two checkboxes turn on capability at the data source. Neither one grants anyone access. They're half of a two-part switch — see the Enable advanced features lesson for the user-side grant, which is the other half.

   • Allow Direct SQL — lets DashboardFox accept raw SQL queries against this data source. Pairs with the Advanced SQL pre-built app on the user side.
   • Allow Stored Procedures — lets DashboardFox execute stored procedures defined on this data source. Only available for SQL Server and PostgreSQL. Pairs with the Advanced Reports pre-built app on the user side.

   Tick whichever apply, click Save & Apply, then go grant users access in the companion lesson. If you turn these on and don't grant anyone access, nothing changes — that's the most common confusion (covered in pitfalls below).

5. Table owner — leave blank by default

   Database tables live under a schema (also called a table owner): SQL Server defaults to dbo, PostgreSQL to public, MySQL doesn't really use the concept. You almost never need to set this field — DashboardFox handles default schemas correctly with the field blank.

   Set Table Owner only if your DBA has put all the relevant tables under a non-default schema (e.g., analytics, reporting) and you want App Builder to scope to just that schema. Setting it filters the table list shown in App Builder to that owner.

   If your tables are spread across multiple schemas with different permissions, the cleaner approach is two separate apps (one per schema), or leave Table Owner blank and set ownership per-table in App Builder. Don't set this field globally if your data isn't actually scoped that way — it'll hide tables.

6. Alternate user data sources — Enterprise tier only

   The Alternate User Data Sources section appears only on Enterprise-tier installations. It enables dynamic per-user database routing — useful when the same database structure is cloned across multiple customer instances and you want one app definition that switches connections based on which user is running it.

   Typical use case: a single-tenant hosted product with 10 customer-specific databases, all sharing identical schema. One DashboardFox app, one semantic layer, ten dynamic connections — DashboardFox routes each user to their assigned database at query time.

   If you don't see this section, you're not on Enterprise tier. If you see it and want to set it up, email team@dashboardfox.com — the configuration depends on how your tenant identification is wired, and it's faster to walk it together than to write a one-size guide.