using LAPI CreateVersion to import docx/xlsx files - are corrupted

[tamaroo]

Our .net web app uses LAPI 9.7.1 to import files into Livelink 9.7.1, the version which is supposed to support Office 2007 file types.

However, my docx or xlsx files are corrupted somehow in the process of importing the file. I know it happens during the import process (rather than when pulling the file back out) from testing each step alternately through our app using LAPI and the Livelink Web user interface.

These Office 2007 docx / xlsx files are really zipped containers of xml files. Review of the 'before' and 'after' file contents show that they're identical. Also, Word 2007 (for example) can repair the file, but that's not an acceptable user experience.

I've found postings relating this issue when importing docx files into SQLServer. They report an extra byte added to the file is causing the problem. However, they're using a stream input process and we're using the File input .net method version of the CreateVersion function.

Any ideas?

 

[ggriffit]

Can you post some code so that we can see what the issue is ?

Greg Griffiths
Livelink Certified Developer & ECM Global Star Champion 2005 & 2006

http://www.greggriffiths.org/livelink/

 

[prantlf]

It sounds strange. You could try something more to find out where the problem really is :

* Test with the Jaa and C++ LAPI. Maybe the problem is specific to the .NET port?
* Test with both the SQL storage and the EFS. Maybe the file system storage works?
* Rename the file. Maybe there is a special processing in te SQL server for the file extension?

I use LES 9.7.1 with MS-SQL 2005 and can create and upload the DOCX documents. At least, the Word has not complained yet...

 

[tamaroo]

Thanks for the replies - here's some code and add'l info:

   [I]Reference is to LAPI_NETp.dll Version 9.7.0.0[/i]

   Imports com.opentext.api

   Friend Const DOC_ID As String = "ID"
   Private m_Session As LLSession
   Private m_Document As LAPI_DOCUMENTS
   Private m_WorkspaceVolID As Integer

   Dim llDocID As Integer
 
   llDoc = (New LLValue).setAssocNotSet()
   llVer = (New LLValue).setAssocNotSet()

   lldocID = llDoc.toInteger(DOC_ID)
 
   '''' Create the initial version
   llVer = ImportVersion(llDocID, filePath)

   Friend Function ImportVersion(ByVal docID As Integer, ByVal filePath As String) As LLValue
        Try
            Dim status As Integer = 0
            Dim verInfo As LLValue = (New LLValue).setAssocNotSet()

            status = m_Document.CreateVersion(m_WorkspaceVolID, docID, filePath, verInfo)

            If (status <> 0) Then Throw New Exception("Error Importing Version, " & m_Session.getErrMsg)

            Return verInfo

        Catch ex As Exception
            Throw New Exception(BuildLiveLinkErrMessage(ex.Message, "Error importing LiveLink version"))
        End Try
    End Function

PS .Net 2.0 / Visual Studio 2005

To clarify, there are no errors thrown. The issue is when you pull the docx back out of LL, Word2007 says the file is corrupt and cannot be opened.

 

[prantlf]

The code does not show any clue.

You wrote that the contents of the files "before" and "after" is the same. What is the difference between the files then?

-- Ferda Prantl

Ferdinand Prantl

 

[tamaroo]

Thanks for the recent post, prantlf. Yes, having the files be identical when looking directly at the xml contents was frustrating.

It turns out we were barking up the wrong tree... it was not a Livelink issue at all. It was an extra byte in the buffer used to stream the file. This had not been an issue with other types of docs, but it does corrupt the new Office 2007 xml file format files. Office 2007 apps do offer to fix the 'corruption' if you open the file directly in, say, Word... but our process is a little different.

We clued in to the real cause of the problem as others were posting issues pulling docx's out of SQLServer and one fellow found an extra trailing byte on the file stream was the culprit.