I have been tasked with designing a database that will use an image of a person as the main form of ID.
At the moment I am restricted to Access 97 and 2000 so any code will have to work for these two versions.
What I need to know (without using activeX ) is.
can access 97/2000 be programmed to take an image directly from a flat bed scanner and insert the scanned image into the OleBound image source box. At the moment the only way I am achieving this is to use a thrid party graphics program to do the scanning, save it to the HDD and then import the image into the database. considering the people who are going to use this database are on the simple side of life i want to make it as easy for them as possible
I'm still learning exactly what makes Access tick, so I can't answer this from a programming standpoint. I am however, a graphic design professional so I can answer it from the imaging standpoint. The task that you're trying to accomplish is usually handled by a standard known as TWAIN (http://www.twain.org/) which regulates communication between software applications and imaging devices. Without using something similar to this standard, I don't really see how you can convince Access to communicate directly with the scanner.
You also mentioned importing the image into your DB. From my limited - but growing, mind you - experience with Access, I know that this is bad news and promotes serious DB bloat. I'm thinking it would be a wiser move to scan and save all of your images into a common directory and then link to them from within Access via the file path. Just store the path in a table and use it on your form or report to display the proper image from within your common directory. Details are available here: (http://support.microsoft.com/default.aspx?kbid=210100) This document was written for Access 2000 so it should be relevant. I hope this - in some crazy way - helps you out a little.
smac's solution works for me. I always prefer to store images outside the database itself. Losts of reasons
1) you can refer to images on different machines within your network or elsewhere.
2) the images don't take up space in the db. images tend to be static ie once captured remian the same, so if you are doing a tape back up then they will not get backed up as often as if they were in the db itself.
3) making changes to images is easier - you can redit the image outside the database, or even replace it. The db doesn't care it just wants a pointer to the image
4) the image is available to other applications / users
5) the request for the image itself comes from the client rather than the database, so you can do other performance tricks, like loading a thumbnail quickly and then letting the user select the main image (yoiu may need to store 2 image pointers (ie lowres & hires)
6) you don't need to be too worried about db performance, however if you keep the image inside the db you need to be very concerned as to how much information is retrieved in a query.
I'm sure there are plenty more reasons, the only real negative I can think of is that if someone deletes the image then your link will no longer work, and its easy to miss one or two images out of many
As regards not using activex then I don't see the issue here - if you don't want to use Activex then don't use a microsoft OS or application software.