Posts

ABAP Database Connectivity (ADBC)

ADBC  is an  ABAP Objects-based API  that allows you to directly execute  native SQL  statements on the underlying database (such as SAP HANA), bypassing the usual Open SQL layer. This is especially useful for performance-critical scenarios or when using features not supported by Open SQL. Typical Steps for Using ADBC in ABAP: 1. Establish a Database Connection Use the static method of the connection class: DATA(lo_conn) = cl_sql_connection=>get_connection( ). 2. Instantiate a Statement Object Based on the connection, create an instance of the statement handler: DATA(lo_stmt) = NEW cl_sql_statement( lo_conn ). 3. Prepare the Native SQL Statement Ensure that the SQL syntax is compatible with the target DB (e.g., HANA). If the statement includes input parameters, register them: DATA(lv_sql) = `SELECT * FROM ZTABLE WHERE FIELD = ?`. 3b. Register Input Parameters (Optional) lo_stmt->set_param( 1, lv_input_value ). 4. Execute the SQL Statement Use the appropria...

Native SQL

Image
 We all know that the ABAP programs use Open SQL, which is translated by the SAP Database Interface into the native SQL of the underlying database during execution. What if I told you that the folks at SAP were prodigies and even before the concept of code pushdown or the existence of SAP HANA by itself, ABAP already supported a way to call and execute native database code directly from the application layer using native SQL! EXEC SQL.   <native SQL code> ENDEXEC. This block allowed developers to write native SQL statements specific to the underlying DB (e.g., Oracle, SQL Server, etc.) directly inside ABAP code. It bypassed the abstraction layer of Open SQL and talked straight to the database. Example: Let's say I want to apply some conditions and then retrieve data. These conditions can be based either on default values or on inputs provided by the user. In native SQL, we handle them as follows: User-provided values are treated as variables and are prefixed with a colo...

Code-To-Data Paradigm

Image
We all know that in the classical programming approach, performing data calculations in the database layer was considered taboo. Typically, data was pushed to the application layer, where operations like calculations, aggregations, and transformations were performed. The results were then sent to the presentation layer. This model, known as the Data-to-Code approach, emerged due to hardware limitations that made databases inefficient at handling large-scale data processing. However, with the advent of powerful hardware and in-memory databases like SAP HANA , the database layer has evolved into a true powerhouse. It can now perform complex calculations, aggregations, and data transformations efficiently and without compromising performance. As a result, the old recommendation to offload processing from the database layer is no longer relevant. Instead, pushing the logic down to the database is now encouraged. Only the essential results are sent back to the application server. How cool...

Getting Started with SAP HANA for ABAP Developers

 In the evolving world of enterprise technology, SAP HANA has redefined the way we store, process, and access data. For ABAP developers, this shift from traditional relational databases to an in-memory computing platform is not just a performance upgrade—it's a mindset change. This blog walks you through what SAP HANA is, why it matters, and how you as an ABAP developer can harness its full power using Core Data Services (CDS), AMDPs, and HANA-optimized best practices. What is SAP HANA? SAP HANA (High-Performance Analytic Appliance) is SAP’s flagship in-memory database. Unlike traditional databases that store data on disk, SAP HANA keeps the entire dataset in main memory , enabling real-time analytics and lightning-fast transactional processing. But HANA is not just a faster database. It’s a platform designed to simplify application logic, reduce data redundancy, and support real-time business operations. Key advantages: In-memory storage for ultra...