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.

Feature	SE16	SAP Query	Hovitaga OpenSQL Editor
Freely defined selections
Transport free
Inner joins
Outer joins
Subqueries
Group functions
"Select for all entries in" syntax
Editing of the result set
Mass update
Mass delete
Background processing
Import from Excel, Access
Hierarchical display
Executing ABAP code on the result set
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.

Transport-free

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.

Subqueries

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.

Group functions

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.

Editing the result set

SE16 has the feature of editing the result set, but the limitations of the selection options hinder using it effectively. Our OpenSQL Editor provides a secure way of editing the results of queries with lots of user-friendly features. Handling authorizations and locking are strictly integrated into the data modification engine.

Mass update and delete

Only our product offers the option of using mass update and mass delete commands, if the authorizations allow it for the user. If the number of records to be edited is high, you don’t need to modify them one by one manually, nor do you need to write a new report. Update and delete commands are fully supported (with proper authorizations) since they are part of the OpenSQL standard.

Background processing

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.

Import from Excel, Access

The OpenSQL Editor offers a strikingly simple way of importing data from Excel files, Access databases or practically any source that can be placed on the clipboard. Pasting the contents of the clipboard into the editable ALV grid is the simplest way of importing data. An automatic input check ensures data consistency, additionally each record can be verified manually before writing them to the database. Adjusting the order of columns to match the columns in the source file is quick and easy with the use of the Field Selection Wizard and the use of drag and drop.

Hierarchical display

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.

Executing ABAP code on the result set

If the elements of the OpenSQL syntax are not enough for you reporting needs, you can - with the necessary authorizations - create and run ABAP code that works on the result of a query.

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.