FM Importing Figures from Database

[Chris Despopoulos]

>>But I don't understand how a db and FM interact. Is it 
>>possible to
import a figure by reference into a FrameMaker 
>>file from a database?
Can you point to a db directory the 
>>way you would to a regular Windows
Explorer directory?

Unless I missed it, the answers I saw to this question don't seem to hit the specific question -- can you have a Maker document open, put the IP somewhere (or select an anchored frame), and import a graphic *by reference* from a database?  Especially important, I think, would be the notion that you don't have to launch the database and exercise the queries for each image every time you open the document.  Likewise, if you're planning on an intranet or internet database connection, you couldn't be in the position of transferring the image over the wire every time you open the document.

The PDFs that discuss Maker/dB integration are good.  But they seem geared toward last-minute publishing of data that's in the dB.  I don't think that's what this question is about.  Maybe I'm wrong, and the issue is already well understood...  Anyway, I see a few possibilities.  Please set me straight on any of these!

* Use your file system as a database, and just organize it really well.  If you store it on a web server that everybody in your intranet can access through file commands, then you can make web pages that list the graphics.  I did this once for a quasi-doc management system, back in the mid-90's.  I had a dir tree where dir names indicated categories, until the final leaf folders were the names of the books.  Executing a dir command such as "dir myLib\*\productA\features\specs\Japanese_Language_Support" returned a listing of all feature specs for the Japanese Language support of productA. The following command would return all documents for that feature, including marketing docs, design docs, etc. -- "dir myLib\*\productA\features\*\Japanese_Language_Support".  You can wrap this up in a web page, so queries aren't so hard to make. With such a system, you could then get the explicit path to your explicit file, and you're good.  

* Store the files in a shared file system, and track locations in the database. I guess you can use tagging and other tricks to help identify the image records -- do your queries until you find the image you want, then get the true-path field from the record and use that.  I'm sure you could wrap these actions in a FrameScript or plug-in to some degree.  I think actually browsing the images would be important -- hopefully the dB offers that.  If the dB includes a suitable API, you could then call a plug-in process that performs the actual import action in Maker.

* True dB File Access -- I think this is what the original question asked for.  I just don't know enough about how a dB stores things like graphics to answer this.  If the dB uses a file system to store the images, then you have a variant of the above (assuming the tree isn't protected somehow).  If not, I don't know what to say.  Maker needs to import the graphics every time you open the file, so it would be a bit of work to trap that import request and re-execute the query.  And I don't know that it would even be desirable to do so.

Just random thoughts, but that's how I would consider skinning this cat.  Am I overcomplicating the issue?

cud