Home » Asset Suite & PassPort » Object embedding & linking (OLE) » Miscellaneous object embedding and linking (OLE) topics

Replacing a TIDBLOB entry (e.g., fixing a slow OLE)

Figure out what the Ole_Object_Id and Ole_Object_Type are.

For example, for X293 data, use the following SQL to get Ole_Object_Id:

select * from passport.tidtpcol
where owner_code_50 = '0000102234000' -- X293 Owner Key
and notes_topic = 'MAINTENANCE HISTORY' -- X293 Notes Topic

Use this SQL to get OLE_OBJECT_TYPE:

select * from passport.tidblob
where ole_object_id = '877777914451'

Extract the TIDBLOB object.

Open a Windows command prompt and change directory to the location of the readBlob.class location. Make certain a directory called output exists.

Run program readBlob.class similar to the following to read TIDBLOB entry out of database. You will be prompted for a user ID, password, database name, Ole_Object_Id and Ole_Object_Type. Output is written to the output directory as OLE_OBJECT_ID.txt.

c:\oracle\ora111\jdk\bin\java -Xmx350m -cp .;c:\oracle\ora111\jdbc\lib\ojdbc5.jar readBlob "PROMPT"

Note that readBlob.java is compiled similar to this:

c:\oracle\ora111\jdk\bin\javac -classpath .;c:\oracle\ora111\jdbc\lib\ojdbc5.jar ./readBlob.java

If you extract an object of Ole_Object_Type=b, then open the file with a hex editor like Ultra Edit and add the two bytes x1F an x9D to the beginning. FTP the file to a Unix box and uncompress it with the uncompress command. FTP the resulting file back to the PC for editing.

The application to edit the file with can be determined by TIDOBLOK.Ole_Object_Class or by the file having a recognized magic number.

If you extract an object of Ole_Object_Type=B, rename the file by adding the appropriate suffix.

Let's say it is a MS Word document with embedded pictures. Use the MS Word Picture Toolbar, Compress to shrink all of the pictures in the document to 200 dpi. This can reduce the file size by a factor of 10.

Rename the existing TIDBLOB object for safe keeping using SQL similar to this:

update passport.tidblob
set ole_object_id = 'PassPortGeek'
where ole_object_id = '877777914451'
and ole_object_type = 'B'

If the file is to be uploaded as Ole_Object_Type=b, FTP the file to a Unix box and use the Unix compress command as follows to perform LZW compression with "bits per code" of 12: compress -b 12 filename. FTP the file back to a PC and use a hex editor to remove the first two bytes of x1F and x9D.

Load the TIDBLOB object.

In the Windows command prompt, run program writeBlob.class in a manner similar to the following to write a file into TIDBLOB. You will be prompted for a user ID, password, database name, Ole_Object_Id, Ole_Object_Type, and file.

c:\oracle\ora111\jdk\bin\java -Xmx350m -cp .;c:\oracle\ora111\jdbc\lib\ojdbc5.jar writeBlob "PROMPT"

You should be good to go. If the OLE is accessed fine in Asset Suite, delete the TIDBLOB entry where OLE_OBJECT_ID = 'PassPortGeek'

‹ Convert from LONG RAW to CLOB IE8 PROBLEM.trying to get to work with PJ 9.2, JRE 1.4.2, Office 2003 ›
By webmaster | | add new comment

OLE containing MS Word containing Adobe pdf files

We are having some issues with embedded invoices taking an extremely long time to open up. The invoice is in the N350 NOTES panel. Sometimes they open quickly and sometimes hang up for an extremely long time.

If you have an explanation please let us know. User is having the same issue with the majority of the invoices she does CPA’s for.

Thanks

Hello,

I tried to access the Ole from the Notes tab on the CPA and I got the following message:

"Previous Object Owner Detected The Object [123456789012] has been previously locked for update by [userID]"

I Examined the lock and then had to forcibly override it, I did notice that it took approximately a minute and a half to open. The embedded OLE doc is over 5 MB so it would be expected that it would take longer than usual, but almost 2 minutes is a long time to wait. I also remember something from a long time ago (when prior analyst was in charge of the Contracts module) about this lock having to be cleared by the technical team.

I was talking to another analyst and she mentioned that you helped last time with a similar issue - do you recall what you may have done to fix this?

Any help you can provide would be great!

Thanks,

Hi,

Asset Suite is taking care of the OLE locking using TIDOBLOK.Ole_Object_Status. It would appear user somehow ungracefully left Asset Suite and left a lock on the OLE. Your forcing the lock should be OK. It could also be removed via SQL.

This particular OLE is 5.6MB. It is an OLE containing a Word Doc containing an email that contains 3 Adobe pdf files. The 3 pdf files are 3MB, 1.2MB, and 1.2MB. Asset Suite uses a compression algorithm known as Lempel-Ziv-Welch which is unable to substantially compress the OLE so it doesn't attempt it. The OLE is stored as 1422 rows of 4000KB each. What this all means is that retrieval is slow.

Suggested method of speeding things up is:

Use Adobe Acrobat to edit the files and use: File, "Reduce File Size" to reduce the file size and then replace the files in the MS Word document. Experimented using Adobe Acrobat 7 on one of the files and reduced the size to 15% of the original.

Note 1: Portal/J 10.0.7 (HTTP instead of TCP) responds much faster with large OLEs.

Note 2: Experiment was done of removing the email layer of the OLE by putting the pdf files directly in the Word Doc. This did n0t make a difference to file size nor retrieval time.

Note 3: Windows Zip was attempted on individual pdf files and size reduction was minimal.

By Anonymous | reply

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.