Limitations with Purpose Equal Strength
Our suite may be the only such database tool on the market today that offers this important security level: making sure data and metadata are only “xtracted” from a database, and never altered (including deletions and insertions). Our customers will just drill-down on relational relationships the fastest possible way, looking for data. They will reverse engineer your database metadata and expose comprehensible and flexible data models as diagrams. But they may never, and they should never, alter whatever your connected databases may have.
Table of Contents
One-Way Reverse Engineering
All our tools only collect data and metadata from any connected database. They can never alter anything through the remote connection. This makes your access safe for the database.
We do not support bidirectional updates, anywhere, because we want your database fully protected, even when you access it through a restrictive account.
The application offers a significant amount of functionality. You can extract information related to database tables, views, columns, and relationships. You can also create simple to complex queries without writing a single line of SQL code, and you can emulate features available only on some databases: pivot / crosstabs, grouping sets, intersect and except, sequence generator, data type functions and so on.
Read-Only SELECT Queries
For decades, most DBAs (DataBase Administrators) I worked with have been deeply reluctant to give anyone in their company direct access to their databases. Main reason has been by far the risk of changing data and of messing things around. Most (if not all) database management tools we know are proud with their facilities to run INSERT, DELETE and UPDATE queries as well. To change data.
We’re proud we’re actually able to enforce the possibility of running just read-only SELECT queries. And, through our selected wrapper, using only server-side functions that we know for sure do not alter your data.
Protection to SQL Injection
Our clients design queries. They never write, enhance or adjust SQL queries manually. This is a guarantee they can never use specific server-side functions or stored procedures that actually change data.
But you can also make your queries to (appear and/or) execute as parameterized: all user values may be (displayed and/or) passed as query parameters. This single fact alone guarantees people cannot produce a SQL Injection breach, even by mistake.
Safe Passwords
We recommend people are given a restrictive user account to connect to a database. However, your DBA can simply configure one first database connection with a password saved as encrypted in our database (if Save Password is checked). Your clerk will transparently use the connection with no need to know the initial credentials.
The other safe and secure approach is to provide the password again each time the application restarts (if Save Password is unchecked). That’s it: by closing the application, you make sure connection credentials are lost and nobody can automatically reconnect to your database by restarting our app.
Is it ok to save the password within application’s system database? It’s safe, but not always recommended. However, passwords are encrypted, and could be decrypted only on your computer. If someone takes your system database and tries to run it, through our app, on another computer, they will be asked to provide each password again.
