Just a few days ago, as I promised in the last blog post, we released a completely new product – Manta Checker for Teradata. Since a live demonstration is better than a thousand words, we have prepared a new demo.
Just a few days ago, as I promised in the last blog post, we released a completely new product – Manta Checker for Teradata. Since a live demonstration is better than a thousand words, we have prepared a new demo containing three scenarios and 28 rules.
I have really good news for those who want to try not only checks but also transformations of scripts, because the demo also contains transformation scenarios. You can transform every Teradata SQL script (BTEQ, macros, views and stored procedures are supported) by uploading it as a file or even by directly typing code to an input form. As a result, you get a validation report as you know it from Manta Checker IFPC, and also the transformed script. You can even select whether you want to pretty-print the script according to your methodology.
Some people tell us they would be afraid to have their scripts transformed automatically. What if the application makes some undiscoverable errors to your pure, faultless code? No worries. There are at least two reasons why you can continue to sleep well. First, every transformation is logged to the validation report, which says what is transformed and where. Second, the built-in transformation rules are very conservative. They transform code only if all conditions are met.
Well, you have tried the demo, you can check and even transform your SQL scripts, so why buy the full version?
Finally, I have more good news also for our Manta Checker IFPC customers. Besides the fact that you can create custom Java rules, as I mentioned last time, it is possible to add exceptions for every rule based on a basic template. Do you have folders or workflows that are deprecated and you do not want to report violations of particular rules for them? Nothing is easier than adding an exception to the rule containing a regular expression for an object location, and another regular expression for an exception value. Let’s have an example of an exception pair for the Expression transformation name rule:
Location: dev_[^\.]*\.[^\.]*_obsolete\..*
Value: (?i)(exp|expr)_.*
It means that in every workflow with the “obsolete” postfix, in folders with the “dev” prefix, it is possible to have expression transformations with the “expr” prefix in their names. Naturally, you can add as many exceptions as you want.
What to do next? If you have not checked our demos yet, I suggest to try them right now. Then, just contact us if you want to have your own trial versions of both Manta Checker products. Do not forget to follow our blog because we will soon tell you about new features available in the next release which is now planned for end of January 2014.
Lukáš
Lukáš is a head of Manta development. Do you have any questions for Lukáš? Post them in the comments.