Many applications currently use Microsoft's OLE Container Control as means for storing objects into binary fields. While this approach has proven effective for the desktop database and thick client environments, it is problematic for the Web environment.
Inorder to overcome these problems Gatsby Database Explorer has introduced the Gatsby Object Embedding and Linking format.
Every facet of Gatsby Object Linking and Embedding including configuration and updating or retrieving content can be accessed programatically using DBDOM. Configuration settings can be updated using the Gatsby Design Assistant. It is recommended that you use those mechanisms for manipulating binary fields. However, we have documented them here for completeness.
Gatsby Database Explorer 3.0 will automatically expose binary fields (OLE Object or dbLongBinary in Microsoft Access and image in Microsoft SQL Server) for Gatsby Object Linking and Embedding. The default configuration allows all object types to be embedded. This configuration can be overridden by several settings.
For Microsoft Access databases these settings are stored as properties of the field. For other types of databases these settings are stored in the data sources file. See the Gatsby Database Explorer Data Sources File Format Reference for more details.
|
LinkThreshold |
If an object exceeds this number of bytes, it will be stored as a linked file rather than embedded in the database.To store all objects as linked files set this value to zero. To embed all objects set this value to 0x7FFFFFFF. The default value is 0x7FFFFFFF. To disable Gatsby Object Link and Embedding set the LinkThreshold value to -1. |
|
LinkedFileFolder |
The file folder where linked files are stored. The linked file folder can be an absolute or relative location. If the location is relative it resolved against the base location. If a base location is not specified, it will be relative to the data sources file. For Microsoft Access databases, it will be relative to the location of the database. Gatsby uses a naming strategy for the files that prevents name collisions in the folder. |
|
MediaType |
The media type that the content is restricted to. If blank, all media types are allowed. The default is to allow all media types. |
|
MediaSubtype |
The media sub type that content is restricted to. If left blank, all sub types of the media type are allowed. The default is to allow all media subtypes. |
The binary image of the field contents contains a header followed by the contents. The header is defined as follows.
| Name | Type | Description |
|---|---|---|
| Signature | short | Should always be 0xEA20 |
| HeaderLength | short | The total number of bytes up to the content |
| ContentLength | int | The number of bytes of content. |
| Created | FILETIME | Date that the field was first populated as a Win32 FILETIME. |
| LastModified | FILETIME | Date the field was last updated as a Win32 FILETIME. |
| OriginalFileNameLength | short | The length in bytes of the original filename string. |
| OriginalFileName | char[] | The original name of the file before it was attached to the field. |
| LinkedFileNameLength | short | The length in bytes of the linked file name. |
| LinkedFileName | char[] | If the file is linked, the relative filename where it resides. |
| ContentTypeLength | short | The length in bytes of the content-type string. |
| ContentType | char[] | The MIME type of the content. |
| LastUpdatedByLength | short | The length in bytes of the LastUpdatedBy string. |
| LastUpdatedBy | char[] | The name of database user who last updated the content of the field. |
| Content | byte[] | If the file is embedded, the actual bytes of the file. |
shorts are 16-bit integers and ints are 32-bit integers.