Largest Provider of Commercial Smalltalk
Cincom is one of the largest commercial providers of Smalltalk, with twice as many customers and partners as other commercial providers.

Tom Nies

Get Started

Store – Chaining Multiple Records

Posted on in Categories SupportTags , , , ,

Resolution 99975 corrects two methods to restore the correct “chaining” of multiple records in the TW_Blob table.modifies.  They are:

  1. Store.Glorp.StoreDescriptorSystem>>tableForTW_BINARYBLOB: aTable
  2. Store.Glorp.StoreDescriptorSystem>>tableForTW_BLOB: aTable

Blob Chaining

When a package is published, many of the associated Smalltalk objects are encoded as byte arrays and stored in one or more rows of the TW_Blob and/or TW_BinaryBlob tables.  The objects stored as “blobs” include:

                  defineSharedVariable definition that are executable "workspace snippets"
                  property values
                  associated files

One row is used when the size of the byte array is 32,000 bytes or less. Otherwise, multiple rows are used. Except for possibly the last one, each holds 32,000 bytes.

The blobType field of the table does double duty as either a type indicator for single-row-only blobs and for the last row of multiple-row blobs. 

Valid blobTypes are:

  1. any other object
  2. instance of ByteString
  3. instance of TwoByteString
  4. instance of ByteArray

A negative value in the blobType field is the negated primary key of the row it “points” to.  For example, a large TwoByteString with TW_Blob table primary key 296 might be stored as:

(second 32,000 bytes)
(first 32,000 bytes)
(trailing <= 32,000 bytes)

The bug in Cincom® VisualWorks® 7.8 that is corrected by this resolution could cause a negative blobType field value to be left as nil when publishing to a Microsoft SQL Server-backed repository.  If that happens, the write to the database would try to INSERT a row into the TW_Blob table that had an SQL NULL value for the blobType field.  If the repository was created with VisualWorks 7.8, then the blobType field has a NOT NULL constraint, and a constraint error occurs preventing the write.  However, if the repository was created with a VisualWorks version before 7.8, the NOT NULL constraint on TW_Blob.blobType is not present and the INSERT succeeds without a warning or error message.  When reading from the database, the entire chain will not be followed and therefore the (partially) reassembled byte array will be truncated.

Querying the Repository Database for NULL blobTypes:

Use the “Store” menu “Store Workbook…” menu item.  In the resulting workspace, the expressions that can be used to determine whether the blob tables have had any such rows with NULL blobType field are inserted.

session accessor executeSQLString: 'SELECT *


session accessor executeSQLString: 'SELECT *

We hope you find this useful. 

“Smalltalk is fun!”