Is Structured FM12 the right solution for this problem?

Question

I've been tasked with solving a tricky problem at my office. Briefly: We've got a technical manual that needs to be printed each time we sell a piece of equipment. Currently, the manual is produced using a combination of MS Access DB and a convoluted Word doc that uses Mail Merge to pull data from the Access DB into the appropriate fields. The DB has a hundred tables or so, and some of the tables are "calculated" values - i.e. the value in the fields is calculated based on values entered in other tables within the DB. The Word doc uses some kind of "if-then-else" logic to determine which tables to use for which fields when building the doc. This whole setup is currently maintained by the engineering, sales, and marketing departments.
We currently use FM11 (unstructured) in the Technical Writing department, and my boss is asking me to figure out a way to migrate the Access/Word doc described above to a format we can use so we can take ownership of the documentation process for this particular line of equipment. I suspect the variables involved here go way beyond what we can do with conditional text and variables within FM, but I'm wondering if Structured FM (either 11 or 12) is more suited to this project, either by using some sort of conduit between FM and an SQL DB, or directly within FM using conditinal text, variables, or some other organizational function present in either FM11 or FM12.
Any guidance here would be appreciated. I'm not even sure what questions to ask at this point to get a proper shove in the right direction.

Answer 1

I love this line: Get that SQL queries into XML directly or into CSV and transform the CSV into XML via XSLT. Reminds me of that bit in "Good Morning, Vietnam" where Robin Williams goes through the routine about the Vice President: "Well, sir, since the VP is such a VIP, shouldn't we keep his ETA on the QT? Otherwise, he might get KIA and then we'd all be on KP." And now, back to work...
I'm going to try to answer all of the questions above, in order, and add a little info where appropriate.
TW dept may or may not take over all maintenance of the doc. That's one of the recommendations I'm tasked with providing. My current thinking is, engineering should remain in charge of entering relevant tool data to the data repository, sales should provide TW with a "spec sheet" of what was sold, and TW should then use the specs to "build" the document for customer release.
Will a DB still be used? Unknown. That seems the best way to catalog and access the data, but I'm open to alternatives if there are any that make sense.
I am totally unfamiliar with structure, XML, DITA, HTML, etc. Literally 100% of my experience with FM has been in the unstructured workspace. This whole structured FM inquiry was inspired by a blurb in my "Unstructured FrameMaker 11" book (from p474: "If you need to use complex combinations of condition tags, consider setting up a workflow in the structured interface of FrameMaker. Structured documents allow you to create versions based on attributes, which are easier to use and more powerful than expressions.") A quick Google of this blurb didn't turn up much useful information, but this seems to jive with Lynne's input above re: attributes.
Data is not currently in SQL - it's in Access DB. We can migrate to SQL if necessary - that's one of the answers I'm supposed to be providing.
The reason this is all currently being done in Word is because that's what the Sales & Engineering departments understand, and currently they're responsible for these docs. I'm sure this started out as a simple, nerdy solution to a small problem - some engineer didn't want to maintain two separate Word docs when he could create a database and then use mail merge to automagically build the same thing. Since then, it's grown to hundreds of tables and thousands of possible permutations.
We already have FrameMaker installations in the department. If we can do this with FM11, great, but if not, no big deal - boss has already said he wants to move to FM12 as soon as possible. In other words, purchasing software - unless it's something additional needed to make all this work - isn't really a budgetary consideration.
As mentioned, I have no skills with using FM for any kind of structured project, but I'm willing to learn if it seems like a good solution. Just need to figure out how to proceed.
Thanks for your input - looking forward to hearing what else you folks have to say.