When is iDBQuery not the right tool?
iDBQuery is built to answer questions from your data, so it is not a data-entry system, a transactional database or a pixel-perfect document designer. It reads and analyses your data rather than running your operations, and it is read-only by design, so it will not change your source systems.
Being honest about the boundaries helps you use iDBQuery for what it is genuinely great at. It is an analytics and answering layer, not an operational system.
What iDBQuery is not designed to be:
- A transactional database or system of record. It queries your data; it does not store or run your operations.
- A data-entry or workflow app. It is read-only by design, so it will not create, edit or delete records in your source systems.
- A pixel-perfect document or presentation designer. It produces charts, tables, live dashboards and shareable reports, but it is not a page-layout tool.
- A fix for missing or wrong source data. It faithfully reflects what your systems contain — it can help you find data problems, but it cannot invent data you do not have.
Where it shines is the opposite of these: getting a fast, cited answer to a question across your databases, files and APIs, investigating why a number changed, and letting non-technical people self-serve analysis. For example, iDBQuery is the right tool for 'why did margin drop and in which region?' but not for 'record this new order'. Knowing that line keeps expectations right: adopt iDBQuery to understand your data, and keep your operational systems for running the business. The two work together.
Updated 2026-06-22