failed to upload documents to Documentum

We have a .net program to upload documents into Documentum. 1 day ago, the uploading failed suddenly with the following error message:

Successfully Logged into docbase: BSSDOCPROD01

1 P-14-090107 GP-1-P-14-090107 090076eb808c3179 090107-N-GP-1

2 P-14-090107 P-10-P-14-090107 090076eb808c317a 090107-N-GP-10

3 P-14-090107 P-11-P-14-090107 090107-N-GP-11

Error! Failed to upload to Documentum - [DCTMUpload(createDocument)] - System.Runtime.InteropServices.COMException (0x80004005): DfException:: THREAD: main; MSG: [DM_SYSOBJECT_E_CANT_SAVE]error: "Cannot save P-11-P-14-090107 sysobject."

[DM_STORAGE_E_TURBO_SAVE_FAILED]error: "Database and/or network error occured while saving turbo content"

[DM_OBJ_MGR_E_SAVE_FAIL]error: "save failed for object with handle 640076eb8000e6ce of type dmi_subcontent: table on which save failed was DMI_SUBCONTENT_R; error from database system was ORA-01401: inserted value too large for column

"; ERRORCODE: 100; NEXT: null:

at com.documentum.fc.client.DfSession.convertToDfException(DfSession.java:3351)

at com.documentum.fc.client.DfSession.apiExec(DfSession.java:169)

at com.documentum.fc.client.DfTypedObjHelperSessionBased.apiExec(DfTypedObjHelperSessionBased.java:321)

at com.documentum.fc.client.DfTypedObject.apiExec(DfTypedObject.java:168)

at com.documentum.fc.client.DfPersistentObject.save(DfPersistentObject.java:712)

at Documentum.Interop.DFC.IDfSysObject.save()

at SAUploadProcess.DCTMUpload.createDocument(String objectName, String title, String aclName, String aclDomain, String destination, String fileName, String contentType)

4 P-14-090107 P-12-P-14-090107 090076eb808c317c 090107-N-GP-12

5 P-14-090107 P-13-P-14-090107 090076eb808c317d 090107-N-GP-13

6 P-14-090107 P-14-P-14-090107 090107-N-GP-14

It looks like SAUploadProcess.DCTMUpload.createDocument is trying to save content of the file to turbo storage. This is not correct because all documents are scaned image files. Any idea how this happened? There should be no changes in the program. And we have no space issue on both filestore and database.

Find more posts tagged with

Comments

aflowers001

Look up the error DM_STORAGE_E_TURBO_SAVE_FAILED. Turbo storage is limited.

Content stored in turbo storage MUST be ASCII and, quoting from the content server manuals,

"Content in turbo storage is stored in the repository. Turbo storage is most useful if
you are granulating the content of documents; for example, it works well for SGML
documents. It also provides enhanced performance for content retrieval.
Turbo storage areas are not represented by storage objects. The content is stored in the
i_contents property of the dmr_content object. You can store up to 2000 bytes in the
property if the RDBMS is Oracle or DB2. If the RDBMS is MS SQL Server or Sybase, you
can store up to 255 bytes in the property. If the content exceeds those limits, the excess is
stored in one or more subcontent objects. Each subcontent object can store an additional
2000 bytes (for Oracle or DB2) or 255 bytes (for MS SQL Server or Sybase).
Content stored in turbo storage must be in ASCII format.
You can use any of the content manipulation methods, such as getFile, setFile, and
setContent, to manipulate content in turbo storage. However, the server cannot
automatically generate renditions of content in turbo storage. If you want a rendition
of a file in turbo storage, you must create the rendition externally and add it to the
repository using an addRendition method."

I guess you might have gone over a limit for each turbo stored block or reached the limit for turbo storage

liaozho

Thanks for the reply.

I think I understand the error message. The question for me is why it suddenly changed to save content to turbo storage. It should not happen. The documents are all scaned image files, they should be saved to regular file system instead of turbo storage in db. If no changes in the program, any other thing could make this happen? I mean it automatically saves content to turbo storage?

mszurap

Hi,

Maybe somebody changed the default storage for the affected formats (tif or pdf, don't know). If I remember well, the default storage area can be also be changed in the object type, or in the server config also... Look after these.

Mike

aflowers001

Hi,

I'd go with what Miklos said as a start, but one experience I can relate is that in one of the installations we had there were a random set of content objects that were in turbo store even though we specifically do not use it, and random by means that for example version 1 and 3 were where expected but version 2 was in turbo store. We never got to the bottom of the issue, but the assumption was a 'feature' of the version we were using.

Might be worth checking powerlink, or raising a support call?