Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can we use Access to do this?

Status
Not open for further replies.

BlueShamrock

Technical User
Mar 8, 2001
1
US
I am a technical writer with the most programming aptitude in our small documentation department (which isn't to say I have much, but I do have a proven knack at learning). We are faced with the dilemma of how to support all of our products in a timely fashion. Our company develops an internationally known and preferred database, as well as applications that interface with it. Our database has thousands of data items and we currently support a domestic and global version of it. Soon, there will be a third version of it for us to support, as well, in addition to and in conjunction with, several applications. Needless to say, we do not release documentation according to our database and application product cycles. In fact, we have manuals that haven't been updated for over five years.

There is so much product information that we use in more than one piece of documentation - especially data item definitions. It would be worth our time to backtrack a little and build a content database that we could store such information, but then only have to update it in one place so we could use it in many places. Can we use Access to do this? If so, could we pull the data from our content database into Word, Framemaker, and Robohelp? If this can be done, could you please write a brief synopsis on how and give any good resources that could tell us more?

Thank you.

blue_shamrock@yahoo.com

 
Not the answer you want.

YES, MS. Access is a useful tool for this type of exercise.

No, a "brief" synopsis is not pratical from the description given.

There was - in some version of Ms. Access - a demo of a document tracking database, including versioning, author, date installed, modified, (document) locking and other features for collabrative documentation control.

I, personally, think that such a project - for 'commercial' database applications would be a rather large effort, with the least of the problem being the programming of the database / app. Having dealt w/ even formally (legally) required documentation of large projects, I have found many instances where the 'ownership' of a document was totally unknown, where multiple revisions of a single document were 'controlled' by different agents/agencies and numerous other 'irregularities' existed. This, in an atmosphere which was agressively persuing the legal requirements for the documents, to remain in compliance with federal laws.

In the case where no LEGAL requirement exists, I would think the real issue here would be just to actually collect the 'real' documents and create an atmosphere which recognized and respected the documentation database.


MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over
 
An Access database has a mximum size of 2GB and is poor when it comes to multi-user access. If you have large volumes of text and any more than a handful of users I'd think it isnt going to be suitable - on its own. Forunately for you, Access 2000 has a new feature which lets it function as a front end to SQL Server 7.0, giving you control over unlimited concurrent users and terrabytes of data. Its proved a great combo for us, but you'll have to decide whether you can bear the cost of both products plus a decent server to host sql. I dont know about the other products you mentioned but using VBA you can get all the office products to exchange data pretty easily.
 
In a document control database you would not STORE the data in the data base, just the attributes. Individual items of information would still be palced it their 'appropiate' containers (e.g. Documents in "Word", Tables in ["Access | Excel"] etc. The documents would be 'password protected' through the data base, and available only through the db. This aproach carries "Relational" another step.

MichaelRed
redmsp@erols.com

There is never time to do it right but there is always time to do it over
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top