Reports
Last updated
Last updated
The following reports are available:
If SQL Tran detects errors when translating due to the limitations in its ability to translate specific code constructs or when there is nothing it can do due to feature gap between source and target database engine, it will list said issues here.
The reports are available in a list of objects, where one object can have multiple errors detected, or grouped by error type for easy impact analysis.
We are currently making a distinction between translation issues caused by our translation engine inability to handle specific code constructs, and detection of functionality that target database engine does not have. We will be merging all of those into errors soon, to simplify the user interface for the end-user so these reports will be removed.
When you specify the target staging/production connections in the project settings, you get the ability to create the complete target schema right from within SQL Tran and get immediately usable database.
Whenever we get an error from the target database on object creation, we will save the error and it will be available when hovering on object name in the tree, when hovering over the Creation stage in the object lifecycle chart, and here.
To determine the complexity of each database object, we look into the complexity of the syntax tree. It is a better metric than number of lines of code (tables are simple yet have each column on a separate line) or even the number of characters (which completely ignores the expression and call complexity, and can be impacted by naming conventions).
A table can use a function for a computed column. A view relies on tables and other views. A procedure reads from some tables, modifies some tables, calls other procedures...
Our static analysis engine tracks all the references in the code, determines what's what, and uses that information to improve translation by taking into account the specific circumstances.
These reports are very approximate! Individual people vary in efficiency by an order of magnitude. There is no golden rule in determining how long manual effort will take. Instead, use these reports as a relative measure of complexity of objects that are left for manual rewrite.
Tackling the objects SQL Tran cannot translate on its own usually means deciding what to remove of the existing functionality, or how to completely rewrite a piece of functionality to achieve similar goal even if not doing exactly the same thing.
SQL Tran is charged per-use. As you translate databases, you will be charged depending on the number and complexity of the objects.
It is good to know exactly when you are charged:
In Basic and Pro plans, you are charge when you unlock the project and when you add/update objects to existing project
In BYOL plan all prices per-object and per-user are set to zero but the same billing events are still sent to the billing server to ensure that billing code is simple
You are charged per user, with the statistics on number of users sent hourly
Billing events reports shows events for a current project only.
To see an example of syntax tree, take a look at the Workspace side panel, tab.
See for more details.
To see an example of a data lineage analysis, take a look at the Workspace side panel, tab.
