Skip to Content
author's profile photo Former Member
Former Member


Hi there,

I am wondering about SQLJ. I am familiar with the concept of SQLJ (being preprocessed and transformed into corresponding JDBC before compile) but I have a little trouble understanding about the distribution logistics that certainly have to be included with it in order to have it run correctly.

As far as I understand the connection your are using for SQLJ has to be fetched from a connection pool via JNDI. Just as you would with JDBC if you are working on a distributed environment. However the SAP NWDS always tells me that I cannot access the data pool. This seems quite logical considering that the pool resides on the J2EE server and is only to be accessed from compiled code within. SQLJ and its features however rely on this connection to be fetched before compile time. I on my end don't know how to acomplish this and therefore I cannot test SQLJ and take advantage of all the features it is supposed to provide.

Can anyone help me by either putting me right on my view of the concept or by telling me where I can get more SAP specific info (like a tutorial) on the subject to work within SAP NWDS.

I also wonder about the strategic decision: Is SAP going to choose SQLJ over JDBC in general? And how about CMP and BMP. Will SQLJ be the primary concept to implement BMP while CMP will in future be solved usinf JDO?

There are a lot of questions open about this subject I guess, so appreciate any input!

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Posted on Oct 20, 2003 at 05:12 PM

    Hi Dominik,

    i hope i can help you with the following explanations:



    SQLJ and Connection Pool

    A sqlj source code obtains a database connection in the following way:

    1. define a context object using a JNDI name of the connection pool, in the following example the jndi name of the connection pool is: 'jdbc/PERSISTENCE_EXAMPLE'

    // define a context class

    #sql public context Ctx with (dataSource = "jdbc/PERSISTENCE_EXAMPLE");

    2. get an instance of the context class. It represents a connection to the database:

    // get an context instance:

    ctx = new Ctx();

    3. work with the context instance and close it.


    The following happens if you press 'save' to save your .sqlj source code inside IDE:

    - the SQLJ Translator checks your ' #sql ...... ' statements and it replaces them with corresponding invokations to SQLJ runtime layer (existing on the SAP J2EE Engine).

    It means, in our case, the SQLJ runtime layer will ensure the jndi lookup in behalf of your program - but at runtime. Of course, you don't need to access the data pool from within IDE.



    Have a look at the 'getting started with relational persistence' tutorial beeing part of the docu of

    SAP Web AS 6.30, J2EE Technology in SAP Web AS. You can access it via

    go to: Development Manual/Developing Business Logic/Java Persistence/Relational Persistence/Getting Started With Relational Persistence'

    The tutorial provides a complete source code of a sample SQLJ application, follow the instructions and you will have run the example after a short time.



    And now i will send you a draft of a paper 'Persistence for Java Applications',

    please refer to the chapter 'Application Programming Interfaces' for a short discussion of the

    SQLJ, JDBC, CMP and BMP API's.

    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Oct 20, 2003 at 05:49 PM

    Here is a short draft of the Java Persistence API's supported by SAP Web AS:

    1. Entity Beans with CMP and JDO

    are competing object/relational (O/R) mapping technologies that free you from writing SQL and JDBC statements entirely. Your persistence layer implementation is portable across the different DBMSs that SAP Web AS supports.

    The Entity Beans with CMP technology is part of the J2EE/EJB standard. To persist data transparently, you must implement all your EJB entity bean components in accordance with the EJB specification. Ideally, you should follow some J2EE design patterns in order not to waste performance.

    The JDO standard extends the Java language with a lightweight, transparent object persistence mechanism for plain Java classes.

    2. SQLJ and JDBC

    The developer implements SQL-based persistence code. We say that SQLJ and JDBC are relational persistence technologies. For SQL code portability, which is guaranteed by Open SQL for Java framework, the SQL statements must be in accordance with the SQL language set adopted at SAP.

    SQLJ is the recommended persistence API. With SQLJ, you do not invoke JDBC methods explicitly. Rather, you will embed SQL statements directly into the Java code.

    The advantage of SQLJ over JDBC is that the SQL statement check happens immediately, inside the SAP Java IDE. This shortens the whole application development cycle. Therefore, always apply SQLJ if working with static SQL statements. A SQL statement is static if its content may be determined at development time.

    Conversely, JDBC API is part of the J2EE 1.3 standard. With JDBC, your SQL statements become parameters of specific JDBC methods. Thus, inside the SAP Java IDE, the Java compiler considers them as simple string objects and the syntax check does not occur until at runtime.

    On the other hand, this mechanism has also a big advantage over SQLJ: With JDBC, the application may generate SQL statements at runtime - e.g. by concatenating strings.

    For example, your Java program may assemble dynamic SQL statements (and use them with the JDBC API) to allow database column names to be provided as method parameters.

    3.Entity Beans with BMP

    The developer again implements the persistence code ? e.g. by using SQLJ or JDO or even by providing proprietary code and using a legacy system (e.g. an ABAP System) as the data store.

    You have to weigh the increased efforts (as with CMP Entity Beans, you have to learn and adhere to the EJB specification and follow some J2EE design patterns) against the achieved object-oriented view of persistent data.

    Regardless of the persistence API used, it is actually Web AS Java that communicates with the database on behalf of the application. In doing so, Web AS Java at the lowest level always sends JDBC statements to the database.

    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.