FM Importing Figures from Database

[Art Campbell]

It's been a while since I did this, but from memory, once you have the
database set up, you make a (typically) SQL call to whatever db object
you want to include/import. And it pops. This is the way most FM shops
would paginate catalogs -- making calls to different text and image
objects in the database, although I think most automated publishing
would compose the files as MIF and then finish the pages in FM.

For run of the mill tech pubs manual publishing, you could get away
with using something simple like Access on a server, but it would only
make sense (IMHO) if other people are constantly changing images and
information w/o your knowledge, but you need to publish whatever the
latest and greatest version is, no matter what. If you have to
manually check the images and confirm the information they carry or
twiddle the words... you're already doing the work manually, so the
payback would be minimal.

If you're simply trying to organize a library of images, I'd look at
image management/db solutions like Adobe Bridge, IMatch from
photools.com (which also supports SQL calls, I think, so you could go
further), or even something like Piccasa.

But I'd only go further if you have a real problem that you face every
day and must solve... otherwise it's likely to be a time  and energy
sink because any of the image databases or a number of the other
solutions already mentioned could solve it.

Art Campbell
               art.campbell at gmail.com
  "... In my opinion, there's nothing in this world beats a '52
Vincent and a redheaded girl." -- Richard Thompson
                                                      No disclaimers apply.
                                                               DoD 358



On Wed, Jan 27, 2010 at 8:30 AM, Chris Despopoulos
<despopoulos_chriss at yahoo.com> wrote:
>>>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
>
>
>
> _______________________________________________
>
>
> You are currently subscribed to Framers as art.campbell at gmail.com.
>
> Send list messages to framers at lists.frameusers.com.
>
> To unsubscribe send a blank email to
> framers-unsubscribe at lists.frameusers.com
> or visit http://lists.frameusers.com/mailman/options/framers/art.campbell%40gmail.com
>
> Send administrative questions to listadmin at frameusers.com. Visit
> http://www.frameusers.com/ for more resources and info.
>