nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

LLATTRDATA vs LLATTRBLOBDATA

Mikhail_Guskov

Hi!

Enviroment: Content Server 10.0; Database - Oracle 11g.

Some time ago the value attribute categories become stored in LLATTRBLOBDATA instead of table LLATTRDATA. Previously value of column VALSTR (table LLATTRDATA) is an absolute value of the attribute but now value is a reference to LLATTRBLOBDATA.

Query example:

select dt.dataid, dt.versionnum, dt.name, dt.Modifydate, dt.subtype,

l.valstr --Problematic value
from dtreecore dt

join llattrdata l
on l.id = dt.dataid
and l.vernum = dt.versionnum
and dt.deleted = 0
and l.defid = 145539 --Category Id
and l.attrid = 18 --Attribute Id
and l.id = 2108118 --Document Id

Query for LLATTRBLOBDATA:

select * from LLATTRBLOBDATA t where t.id=2108118

All needed values stored in SEGMENTBLOB column now.

On the other stands the attribute values stored in VALSTR as is.
What Content Server's setting controls that behavior?

Find more posts tagged with

Comments

Hans Stoop

Hi Mikhail,

The attribute data is stored in LLAttrBlobData. On storage in LLAttrBlobData the data is also stored in LLAttrData for reporting purposes. The LLAttrData table needs to be considered as ReadOnly, any changes made on that table will not actually change the attribute value.

This has always been the case.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Donnerstag, 10. März 2016 10:55
To: eLink Recipient
Subject: LLATTRDATA vs LLATTRBLOBDATA

LLATTRDATA vs LLATTRBLOBDATA

Posted by Guskov, Mikhail On 03/10/2016 04:50 AM

Hi!

Enviroment: Content Server 10.0; Database - Oracle 11g.

Query example:

select dt.dataid, dt.versionnum, dt.name, dt.Modifydate, dt.subtype,

l.valstr --Problematic value
from dtreecore dt

join llattrdata l
on l.id = dt.dataid
and l.vernum = dt.versionnum
and dt.deleted = 0
and l.defid = 145539 --Category Id
and l.attrid = 18 --Attribute Id
and l.id = 2108118 --Document Id

Query for LLATTRBLOBDATA:

select * from LLATTRBLOBDATA t where t.id=2108118

All needed values stored in SEGMENTBLOB column now.

On the other stands the attribute values stored in VALSTR as is.
What Content Server's setting controls that behavior?

[To post a comment, use the normal reply function]
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Mikhail_Guskov

Thank for answer, Hans!

Problematic machine: CS (http://prntscr.com/adg9jp) and SQL (http://prntscr.com/adg8p8)

Normal machine: CS (http://prntscr.com/adgb5a) and SQL (http://prntscr.com/adgbq5)

Earlier if I wanted to read the data, I could use just table LLATTRDATA, but now I also have to read from table LLATTRBLOBDATA (because value in VALSTR of LLATTRDATA is not what expected). Is this an issue or is it a correct server behavior?

David Templeton

Can you provide the screen shot for all of the rows for that category on the version of the object please? LLAttrData.* for all of the columns

Thanks

David

Error.png

Hans Stoop

If the value in LLAttrData is incorrect then that is an error.

If it is reproducible you can enable the connect logs and see what happens at the database level. Another option is too debug it.

When you look directly in the database is it then correct? Maybe there is an issue with the encoding of the data. You can check that by first entering only English characters in the attribute.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Donnerstag, 10. März 2016 13:35
To: eLink Recipient
Subject: RE LLATTRDATA vs LLATTRBLOBDATA

RE LLATTRDATA vs LLATTRBLOBDATA

Posted by Guskov, Mikhail On 03/10/2016 07:29 AM

Thank for answer, Hans!

Problematic machine: CS (http://prntscr.com/adg9jp) and SQL (http://prntscr.com/adg8p8)

Normal machine: CS (http://prntscr.com/adgb5a) and SQL (http://prntscr.com/adgbq5)

[To post a comment, use the normal reply function]
Topic:	LLATTRDATA vs LLATTRBLOBDATA
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Mikhail_Guskov

David, screenshot in attachment.

Quoted David Templeton on 03/10/2016 04:26 PM:

Can you provide the screen shot for all of the rows for that category on the version of the object please? LLAttrData.* for all of the columns

Thanks

David

problemCS&SQL.png

Mikhail_Guskov

Hans, when look directly into database (valstr in llattrdata) - value is incorrect (numeric value). In attribute is only English characters (string value).

Quoted Hans Stoop on 03/10/2016 05:21 PM:

If the value in LLAttrData is incorrect then that is an error.

If it is reproducible you can enable the connect logs and see what happens at the database level. Another option is too debug it.

When you look directly in the database is it then correct? Maybe there is an issue with the encoding of the data. You can check that by first entering only English characters in the attribute.

Hans

Hans Stoop

Yes, I saw it in your screenshot.

This is very strange. Did somebody install a customization that changes the standard behavior?

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Donnerstag, 10. März 2016 15:24
To: eLink Recipient
Subject: RE RE LLATTRDATA vs LLATTRBLOBDATA 2

RE RE LLATTRDATA vs LLATTRBLOBDATA 2

Posted by Guskov, Mikhail On 03/10/2016 09:21 AM

Hans, when look directly into database (valstr in llattrdata) - value is incorrect (numeric value). In attribute is only English characters (string value).

Quoted Hans Stoop on 03/10/2016 05:21 PM:

If the value in LLAttrData is incorrect then that is an error.

If it is reproducible you can enable the connect logs and see what happens at the database level. Another option is too debug it.

When you look directly in the database is it then correct? Maybe there is an issue with the encoding of the data. You can check that by first entering only English characters in the attribute.

Hans

[To post a comment, use the normal reply function]
Topic:	LLATTRDATA vs LLATTRBLOBDATA
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

David Templeton

I would suggest opening a support ticket to trace this down, but definitely something is going on. I would suggest gathering some connect logs when updating that field to help trace what is really going on.

David