views:

145

answers:

6

As mentioned I write a lot of proposals to reply to government RFP's. No matter what the RFP is about most require the same information. It is always narrative, charts, graphs, photos, tables, organizational charts, etc.

To save time cutting and pasting and searching old proposals I was wondering if it is possible to create a database in Access to extract the type of data needed?

A: 

It is possible to save anything in an MS Access database that you could save in the file system. However, I don't know that Access is the best solution for this as there are issues inherent in Access with large binary objects.

I would recommend MySQL as an alternative. It's freely available for download and offers a more robust solution than MS Access, in my opinion.

Michael Todd
-1 You can't program a front end in MySQL.
David-W-Fenton
No, but you can program a front-end in anything else that allows you to create a front-end and use MySQL (or any other data store) as a back-end. Lacking front-end creation capabilities via other methods does not excuse Access's limitations and inherent weaknesses. I've used Access since Access 95. I'm not knocking it just because I don't like it; it's fine for a lot of things. But large binary objects is not one of them.
Michael Todd
+1  A: 

You might want to consider saving the objects in the file system and including a link column to them from access.

devSpeed
+1  A: 

If this is something that you will just run on your own computer then Access might be an attractive option. Make sure you keep copies of your material in another folder, in case there are problems.

If you are going to share the information in the database over a network with even one other person, I would select something else for the storage medium. Just my two cents, having worked with Access for many years.

As others have stated, it is a better strategy to store links to documents stored in the file system, rather than storing the documents directly in the database.

If you intend to share the database in a client/server arrangement, consider enlisting the help of a Microsoft Access expert, if you are not one already.

Robert Harvey
Jet/ACE is fine for sharing data in workgroups of up to 25-50 people. But you do have to be efficient in writing your application. Everyone has suggested storing paths, rather than storing the objects in OLE fields, and that's a correct recommendation. Certainly, OLE fields could possibly reduce concurrency and risk corruption, but nobody is recommending using those.
David-W-Fenton
+2  A: 

This seems like the type of application Access was made for, one person app, not a programmer creating it. I would store the file path to objects such as documents, images etc, rather than the actual image. Consider also having a table that stores standard language you might frequently reuse. We did an application to do something like this in my last job and it was quite a bit more work to get it to spit out formatted proposals than you might think (especially if the format varies for RFP to RFP which it can do, same information basically but rearranged). Once it was done, it was easier to do the proposals, but don't think this will be a simple, fast task.

If you separate the backend and the front end and people never work on the same proposal at the same time, you can avoid the problems that Robert mentions. We gave a copy of the front end Access file to each user rather than use a network copy (the backend was on the network, our backend was a SQL server database) and set up a system, so that if they didn't have the most current configuration of the Access front end, they could not open a proposal. That meant everyone had to upgrade when a new version came out and helped keep problems from arising if out of date versions were used. We did this with a local read only table in each person's copy that carried the configuration number of that copy that had to match a backend table that had the most current configuration number in it.

One thing to make sure of is to use a primary key in every table whether you think you need to or not. Access is very picky about updating records unless there is a primary key.

HLGEM
The separation of frontend and backend is always mentioned in these questions. The failure to split the database into a client and server when sharing data must be a far greater problem than I ever thought. This technique seems so obvious to me I just assumed everyone did it.
Robert Harvey
A: 

Access is a relational database, unless you have structured metadata about the various artifacts then Access won't help much with searching, filtering, etc. Also you'll need to build your own UI for everything.

If this application needs to support multiple users, then Sharepoint might actually be a better solution. It provides a reasonable UI out-of-the-box, built in structured and freetext search, and other goodies which may be relevant such as document versioning.

Addys
A: 

I strongly suggested you use the Access2007 version of the Access database engine, known as ACE, and use its Attachment field type:

Attach files and graphics to the records in your database

Attachments also store data more efficiently. [Access2003/Jet 4.0 and earlier] versions of Access used a technology called Object Linking and Embedding (OLE) to store images and documents. By default, OLE created a bitmap equivalent of the image or document. Those bitmap files could become quite large — as much as 10 times larger than the original file. When you viewed an image or a document from your database, OLE showed you the bitmap image, not the original file. By using attachments, you open documents and other non-image files in their parent programs, so from within Access, you can search and edit those files.

ACE is available as a free download from Microsoft: 2007 Office System Driver: Data Connectivity Components.

onedaywhen