Opentext Documentum Server 16.4 released

Who the hell creates database indexes through DQL? Please, show me that idiot.

Alvaro de Andres' Blog

You can find it in the downloads section.

New features:

  • Independent JMS
  • OpenText Directory Services integration with Documentum
  • Support for parallel indexing
  • Support for Amazon S3 store
  • Audit Trail enhancements
  • Support for + (concat) operator in Oracle databases
  • Removal of sticky bit

View original post

Software company vs Apache License

Pro Documentum

A month ago I got impressed how software company manages knowledge: as all we know when Documentum was under EMC wing there were two public forums: Documentum Support Forum and Documentum Developer Forum – both are inaccessible for now because OpenText had partially moved their content to OpenText community forum and restricted access to customers only – here I have now idea why do they think that ECN forums weren’t public:

At ECD, the two forums you mentioned were separated because one was an open forum and the other (Dev) was closed and available to developers only. Here, we do not have the distinction of open and closed forums within our product membership.

Today I got another interesting case: it seems that OpenText decided to rebrand Documentum products but doing it in extremely weird manner, for example:

View original post

Opentext Documentum is coming next month

Alvaro de Andres' Blog

I didn’t realize that roadmap documents were updated last month. It looks like the February release is still going to happen (and I’ve been told a definite date, so it looks it won’t be delayed). After reviewing them (haven’t seen any changes :D), I can say:

  • Not much features regarding CS, the pattern/usage visualization and the s3 support (which, as far as I know, can be already done without official support) are the new features.
  • No word about DFS, and I know for a fact that several customers have actively asked for updates to current libs and extended support for application servers.
  • Clients get barely any changes (D2, Webtop, xCP).

I’m curious to see how many bugs are found in this first release from Opentext (and the brave customers that go first into the unknown :D), considering that some of the experienced Documentum staff left the company and the changes…

View original post 19 more words

Eradication of Illiteracy

What talented team had defined as “the information to retrieve” has a special name: projection, and, for most relational databases, names of attributes, presented in projection, are case-insensitive.

It seems that some members of talented team think that they are smart enough to read this blog and make some conclusions about security:

API> ?,c,select user_password from dm_user where user_name=USER
(1 row affected)

API> ?,c,select * from (select user_password from dm_user where user_name=USER)
(1 row affected)

But all their attempts are doomed to failure:

API> ?,c,select USER_PASSWORD from dm_user where user_name=USER
AAAAEAjkr5it6wBqYfLetO/ob9j+75axyTIlb6WpnS8vLcP58ppmenSigXCm4pT1Q3nG ...

API> readquery,c,select * from (select * from dm_user where user_name=USER)
API> next,c,q0
API> get,c,q0,user_password
AAAAEAjkr5it6wBqYfLetO/ob9j+75axyTIlb6WpnS8vLcP58ppmenSigXCm4pT1Q3nGK ...

Q & A. XVI

I will work, maybe, in a D2 implementation project that could be released in a public site. I do not have updated information regarding D2 4.7 security holes: I need an independent point of view and you are probably the only person that has a clear understanding of what I am talking. Can you help me to understand what has not yet been fixed just in the D2 layer?

Current D2 security status: any authenticated user may gain superuser privileges 🙂

Unicode support

Yesterday I discovered a funny blogpost about unicode support in Documentum (have no idea why it is named “DOCUMENTUM PROBLEMS AND HOW TO FIX THEM: #1” if it does not contain any solution), and now I would like to share my vision on the problem.

It is not clear why that blogpost is referring to “CS-49851 – “Server does not recognize a UTF-8 enabled database and unnecessarily errors on attribute length””, because I have seen other related CRs dated by 2005 or so, however I can explain why OpenText will never implement a proper unicode support in Documentum.

At current moment Documentum supports four database engines:

  • Oracle
  • DB2
  • PostgreSQL

What do you think, which database is the most problematic from unicode perspective? To answer this question we must understand what does “varchar(n)” mean for every database:

database data type description
MSSQL varchar(n) Variable-length, non-Unicode string data. n defines the string length and can be a value from 1 through 8,000. max indicates that the maximum storage size is 2^31-1 bytes (2 GB). The storage size is the actual length of the data entered + 2 bytes. The ISO synonyms for varchar are charvarying or charactervarying.
nvarchar(n) Variable-length Unicode string data. n defines the string length and can be a value from 1 through 4,000. max indicates that the maximum storage size is 2^31-1 bytes (2 GB). The storage size, in bytes, is two times the actual length of data entered + 2 bytes. The ISO synonyms for nvarchar are national char varying and national character varying
Oracle varchar2(n) The VARCHAR2 datatype stores variable-length character strings. When you create a table with a VARCHAR2 column, you specify a maximum string length (in bytes or characters) between 1 and 4000 bytes for the VARCHAR2 column. For each row, Oracle Database stores each value in the column as a variable-length field unless a value exceeds the column’s maximum length, in which case Oracle Database returns an error. Using VARCHAR2 and VARCHAR saves on space used by the table.
DB2 varchar(n) Varying-length character strings with a maximum length of n bytes. n must be greater than 0 and less than a number that depends on the page size of the table space. The maximum length is 32704.
vargraphic(n) Varying-length graphic strings. The maximum length, n, must be greater than 0 and less than a number that depends on the page size of the table space. The maximum length is 16352.
PostgreSQL varchar(n) SQL defines two primary character types: character varying(n) and character(n), where n is a positive integer. Both of these types can store strings up to n characters (not bytes) in length. An attempt to store a longer string into a column of these types will result in an error, unless the excess characters are all spaces, in which case the string will be truncated to the maximum length. (This somewhat bizarre exception is required by the SQL standard.) If the string to be stored is shorter than the declared length, values of type character will be space-padded; values of type character varying will simply store the shorter string.

So, in order to implement proper unicode support Documentum must:

  • Do nothing for PostgreSQL
  • Change string semantics from byte to character in case of Oracle (i.e. alter table dm_ysobject_s modify (object_name varchar2(255 char)))
  • Change string datatype from varchar to vargraphic in case of DB2 (I believe something like ALTER TABLE DM_SYSOBJECT_S ALTER COLUMN OBJECT_NAME SET DATA TYPE VARGRAPHIC(255), though I’m not sure it will work)
  • Discontinue support of MSSQL because this database wrongly assumes that the maximum length of any UTF-8 character is 2 bytes (compare: é (C3 A9) and é (65 CC 81))

So, it is clear that it is not possible to implement proper unicode support in case of MSSQL, so OpenText will do nothing because otherwise Documentum will behave differently on different databases.