Type update fails on Hana database due to bad sql grammar

[Former Member]

Hi,

We are using SAP Commerce 6.6 on top of Hana database. We used to do type updates fine, but since last deploy the below exception is happening. There are no item updates to addresses but to other items. The exception is blocking the update, and no item changes is reflected in database.

I have tried to deploy an earlier version of our codebase - where I know the type update was successfull. Thats also failing now.

We are using the default schema on database, matching the user.

Anyone have an idea about what could be the issue?

org.springframework.jdbc.BadSqlGrammarException: StatementCallback; bad SQL grammar [CREATE COLUMN TABLE ADDRESSES_ ( HJMPTS BIGINT, CREATEDTS TIMESTAMP, MODIFIEDTS TIMESTAMP, TYPEPKSTRING BIGINT, OWNERPKSTRING BIGINT, PK BIGINT NOT NULL, SEALED DECIMAL(1,0), P_ORIGINAL BIGINT, P_APPARTMENT NVARCHAR(255), P_BUILDING NVARCHAR(255), P_CELLPHONE NVARCHAR(255), P_COMPANY NVARCHAR(255), P_COUNTRY BIGINT, P_DEPARTMENT NVARCHAR(255), P_DISTRICT NVARCHAR(255), P_EMAIL NVARCHAR(255), P_FAX NVARCHAR(255), P_FIRSTNAME NVARCHAR(255), P_LASTNAME NVARCHAR(255), P_MIDDLENAME NVARCHAR(255), P_MIDDLENAME2 NVARCHAR(255), P_PHONE1 NVARCHAR(255), P_PHONE2 NVARCHAR(255), P_POBOX NVARCHAR(255), P_POSTALCODE NVARCHAR(255), P_REGION BIGINT, P_STREETNAME NVARCHAR(255), P_STREETNUMBER NVARCHAR(255), P_TITLE BIGINT, P_TOWN NVARCHAR(255), P_GENDER BIGINT, P_DATEOFBIRTH TIMESTAMP, P_REMARKS NVARCHAR(255), P_URL NVARCHAR(255), P_SHIPPINGADDRESS DECIMAL(1,0), P_UNLOADINGADDRESS DECIMAL(1,0), P_BILLINGADDRESS DECIMAL(1,0), P_CONTACTADDRESS DECIMAL(1,0), P_VISIBLEINADDRESSBOOK DECIMAL(1,0), P_SAPCUSTOMERID NVARCHAR(255), P_SAPADDRESSUSAGE NVARCHAR(255), P_SAPADDRESSUSAGECOUNTER NVARCHAR(255), ACLTS BIGINT DEFAULT 0, PROPTS BIGINT DEFAULT 0, P_DUPLICATE DECIMAL, PRIMARY KEY (PK) )]; nested exception is com.sap.db.jdbc.exceptions.BatchUpdateExceptionSapDB: Error in batch command number 1: SAP DBTech JDBC: [288] (at 20): cannot use duplicate table name: ADDRESSES_: line 1 col 21 (at pos 20)

[Former Member]

Hi, could it be that some attributes for a specific type (in the case the OOTB address type?) have been changed, with the upgrade?

[Former Member]

There is no changes to the address type in the release.

[Former Member]

How did you resolved it ?

[Former Member]

Hi Thomas,

How did you resolve this?

Thanks, Sid

[Former Member]

We noticed that duplicate attribute for some addresses was N/A, even thought there should be a default value of 'false', so we tried to update duplicate attributes on all these addresses from HAC with impex script.

One address could not be updated. We removed the entire address, and the issue was solved.