cancel
Showing results for 
Search instead for 
Did you mean: 

PI 7.3 + JDBC-Adapter -> Invalid column name (apostophes missing)

Former Member
0 Kudos

Hello,

we're about to migrate our XI to PI 7.3. In the old XI we have some fine working IDoc to JDBC szenarios. The IDoc reaches the XI and there the IDoc gets mapped to the XML-Structure of the JDBC-Adapter. After the mapping the JDBC Adapter writes the data into a MS SQL Server. Like I said - this used to work fine.

Now with 7.3 there are some funny errors while writing into the table. The table to write is very simple:

CREATE TABLE [dbo].[ekko](
	[EBELN] [nchar](10) NOT NULL,
	[LIFNR] [nchar](10) NULL,
	[BUKRS] [varchar](4) NULL,
	[BETRG] [decimal](18, 2) NULL,
	[WAERS] [varchar](5) NULL,
	[VERKZ] [nchar](1) NULL,
	[VERDT] [varchar](20) NULL,
 CONSTRAINT [PK_ekko] PRIMARY KEY CLUSTERED 
(
	[EBELN] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

The PI creates the following update-stamement:

UPDATE dbo.ekko SET EBELN=4700002087, LIFNR=0000020922, BUKRS=0001, BETRG= 92.86, WAERS=EUR, VERKZ=U, VERDT=20120106103300 WHERE (EBELN=4700002087)

This doesn't look wrong so far. But when executing this query, the following error occurs in the audit protocoll of the communication channel:

Error processing request in sax parser: Error when executing statement for table/stored proc. 'dbo.ekko' (structure 'STATEMENTNAME'): com.microsoft.sqlserver.jdbc.SQLServerException: Invalid column name 'U'.

I tried to execute the generated query inside the MS SQL Server Management Studio and the problem is, that the values in the fields WAERS and VERKZ are not enclodes with apostrophes (WAERS = 'EUR'). The old XI with the appropiate Adapter/JDBC-Driver was working well. I hope that this problem is because of an option in the Adapter or JDBC-Driver. Does anybody have a good idea for me to get the values of WAERS and VERKZ into apostophed?

Regards

Torsten

Accepted Solutions (1)

Accepted Solutions (1)

udo_martens
Active Contributor
0 Kudos

Hi Torsten,

a very simple, cheap and trivial solution would be to add the apostrophes in the mapping (concatenate). Does not make sense in case of too much interfaces.

Regards,

Udo

Former Member
0 Kudos

Hello Udo,

thank you very much for your reply. This suggestion doesn't work - I'am not sure if I should feel lucky or sad about it. When it would have worked, then I would have to change several mappings. When concatenating EUR to 'EUR' the RFC-Queues are jamming ( "Unable to convert sender XI party http://sap.com/xi/XI / XIParty / DATEV to an IDoc partner" ).

Regards

Torsten

udo_martens
Active Contributor
0 Kudos

Hi Torsten,

this is a pretty surprising error msg

I think something went wrong in your test. "Unable to convert sender XI party .." has actually nothing to do with the message content. May be you created not well formed XML? Can you pick up the message after mapping and check it?

May be you have to map the code & a p o s ; (without spaces) instead of the apostroph?

Regards,

Udo

Former Member
0 Kudos

Hello,

unfortunately neither changing the field format in the target database nor adding apostophes in the message solved the problem. I still hope that this problem is a result of missing or misconfigured options in the JDBC Adapter of the PI. Is anyone using the PI 7.3 with JDBC for MS SQL Server? Are there additional parameters maintained in the communication channel?

Regards

Torsten

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi.

Try this, change the type of [VERKZ] field to varchar(1) or nvarchar(1)

Regards

Luis Ortiz.

Former Member
0 Kudos

Hello Luis,

thank you very much for your help but the error is still present. I'am really wondering if there is an option in the JDBC-Adapter which causes this error.

Regards

Torsten

Former Member
0 Kudos

Hello Luis,

oh no... you are right. I don't know why but the field with the format NCHAR(1) is the cause. I changed it (again) to varchar(1) and it (suddenly) works. I don't understand, why other NCHAR fields are not having the same problems.

Thanks

Torsten

Former Member
0 Kudos

Hi.

I guess is the limitation of nchar..

Check the below link.

http://docs.oracle.com/cd/B19306_01/server.102/b14238/compat.htm#CHDGEJGA

Regards

Luis.

Former Member
0 Kudos

SAP note 1639993 solved the problem.

Thanks for the help!