I did some poking around once in the EA.exe binary, and it definitely appears that the BinContent field in t_document is zipped. BTW, the StrContent field in the same table appears to be completely unused.
An alternative to direct database access is to use the AI methods to save and load a linked document to and from a file. You could use a randomly generated temporary file name, save the RTF in the temporary file, then load the contents of the file into whatever container you would use to manipulate the file using direct database access. Once done, you can do the same thing in reverse to get the RTF back into the linked document, then trash the temporary files you created as a housekeeping measure. Along the way you might have the need to make use of a FileSystemWatcher (or its non-.NET equivalent) and some judiciously selected time delays to allow file operations to complete. It ain't pretty, but I've done it (as have others in this forum before me - cheers Geert!) and it works.
I was once pretty gung-ho about getting at the data directly, but eventually became convinced after some back and forth on these forums to use the AI, imperfect and incomplete as it is, in order to avoid the possibility that Sparx might hack the database schema (again!) in future to add some new feature, making my add-ins incompatible.
Ultimately, Sparx should provide AI methods to permit direct manipulation of the RTF text in a linked document (I already sent in a feature request to that effect) as well as a whole bunch of other things not yet implemented.
