Why is SE16 and SAP Query not enough?
Here is a detailed comparison with two tools that consultants and developers use mostly to extract data from SAP systems.
Hovitaga OpenSQL Editor
|Freely defined selections|
|"Select for all entries in" syntax|
|Editing unlimited queries in one session|
|Saving queries to a repository|
|Record level authorizations|
|Field level authorizations|
Freely defined selections
While SE16 and SAP Query only allow multiple selection options used together with an “AND” operator, Hovitaga OpenSQL Editor can handle any kind of logical expression. You can use other operators such as “OR” and “NOT”, or even use subqueries and related queries to define relations between selection options. This ensures maximum flexibility and ease of use.
Using queries built by Hovitaga OpenSQL Editor in a different system does not require any kind of transporting between SAP systems. Since the queries are not development objects, they don’t need to be put into transport requests. However, if you want to use an SAP Query on a different system, a transport request must be created and all necessary objects must be transported to the target system.
Inner and outer joins
SE16 is only capable of displaying the contents of a single table (and related text tables). If you want to see data read from multiple tables, you must create a view in the repository. Hovitaga OpenSQL Editor can handle any number of inner and left outer joins in a query. With the use of the Linked Query Assistant which offers the tables related to each other to use with a join, and automatically generates the join condition, which can be extended at any time if needed.
It is possible to work with subqueries: queries within queries. This syntax element offers superior performance and much more options to create complex queries with ease.
While SAP Query can be used to calculate formulas, it does not allow aggregate (group) functions to be calculated on the database server. Hovitaga OpenSQL Editor can process queries utilizing the “GROUP BY” syntax element, providing a quick and simple way to create sums, averages and other group functions within queries.
"Select for all entries in" syntax
Another great feature is to use the output of any query as the input for another query. If you have a query on business partners for example, you can use the result set to get all the payments for those business partners in a second query.
Hovitaga OpenSQL Editor can schedule any number of queries to be executed in the background and automatically exports the results to a file without any additional effort.
We can not only can display the results in an ALV grid, we can display it with an ALV tree also. The hierarchy levels can be adjusted any time without re-executing the query and putting unnecessary stress on the server.
Editing unlimited number of queries in one session
If you want to work with SE16 or SAP Query on multiple queries at the same time, you have to open multiple windows and switch back and forth between them. Hovitaga OpenSQL Editor uses a navigation tree and every query is listed there. You can switch between queries by simply selecting them in the tree.
Saving queries to a repository
Commands can be organized a folder structure that you can manage with drag and drop also.
Record level authorizations
While SE16 and SAP Query only use table group level authorizations to filter query results, Hovitaga OpenSQL Editor can be controlled with a much more sophisticated authorization concept. A generic standard SAP authority check is used to filter the query results based on any organizational criteria defined in customizing. For example a scenario can be set up easily where certain users only see data for their company code (or country or any organizational level).
Additionally any number of existing authority objects can be assigned to tables (with a field mapping also) that are used when filtering query results. For example to filter VBAK entries by sales organization simply assign authority object V_VBAK_VK0 to the table (M_MATE_WRK to table MARC to filter by plant etc... ).
Field level authorizations
In addition to the record level authorizations, queries can be filtered on field level also. For example, certain users could see the contents of the salary field in a table, others could not, depending the authorizations.