Showing results for 
Search instead for 
Did you mean: 

Central Build Problem

Former Member
0 Kudos

We are facing a problem while doing a central build of a DC. The details of the problem are given below.


A Webdynpro Development Component (DC A) contains the SQLJ files(Ctx.sqlj,CustDetails.sqlj,UserDetails.sqlj,MyLanguage.sqlj).

The generated Java classes CustDetails, UserDetails and MyLanguage is being used in the application (Same DC A) to create, delete and modify records in the database tables.The local build of this DC (DC A) is successfull and is working fine inthe local testserver.While doing a Central Build of DC A it gives an error message that unable to resolve sysmbolCustDetails, UserDetails and MyLanguage.

Help will be generously appreciated.

Thanks and Regards,


Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos


One Solution to this is Create a development component and in src/packages folder of the component, place all the SQLJ files. Expose this package folder as Public part. In public part use Java Package Tree option (select all the files). Build and deploy this component.

Use this component in the your component as used webdynpro component.

Let me know if you require any other help.


Answers (2)

Answers (2)

Former Member
0 Kudos

Solution was similar to what kishore has posted.

Created a Java DC containing the SQLJ files and helper classed to insert/select... records from table. In this dc created a public part and exposed the class files.

In the webdynpro declared the above mentioned java dc as a used dc....

thanks for all the replies.

Former Member
0 Kudos


Im afraid that the CBS server does not compile the .sqlj files in the WebDynpro DC's. You could report this issue as a Customer Message to SAP.

However, using .sqlj files in the webDynpro app suggests that you are doing the database access/modify in the webDynpro application, which is not a very good idea in general, as webDynpro is to provide only the "view" or the "user part" of the application. WebDynpro should not execute backend operations directly, but access some exposed interface of the backend. That's why you cannot access SAP tables directly, but have to use BAPI's.

Consider moving the data mangling functionality out of the WebDynpro application, for example into an EJB or a WebService, and call those from webDynpro.