I have a work project where I need around 600 photos and a description of each, I can put them all in tables and then have them enlarge etc. However I need to allow people to search and find only certain photos and descriptions obviously I don't want them to look through all 600. So search and display. Where do I start? Whats the easiest way to do it? I believe Access data pages don't display images although I could be wrong. The next problem I need to show this working before I can put it on the companies intranet. Can anyone please tell me where to start.
Originally Posted by peterwmartin
instead of storing image in a database why dont you just save the picture in the server and store in the database the link of the picture..in that way you can efficiently call the image using the link and not retrieving it from the database.
Does your company have actual web developers or an IT group? If so, ask them what database to use then build it like creedo says. Access isn't a database; it's a reporting tool that happens to come bundled with a toy database that should never be used in a shared environment.
Thank you both. Interesting your comments about access. I will talk to our IT people at work. For now can you tell me how to load a page with a search criteria. Just a question if I had several pages with the photos and information on them is there a way to load another page with selections from the others????
cant really understand your question..please explain what you want to do..
Originally Posted by peterwmartin
I was asked to make a database of the tools in my works store. I made a simple page. With the photos and descriptions in tables which was ok. Then they told me the need about 600 photos and that would not really be practical to load all 600 every time. So I need to be able to do a search say Hammer and then only show the hammers. Access will not display the photos in .jpg so the size is a problem. And I don't know if the store has access or if the people know how to use it so a webpage was a better option. I could display the photos etc. Until they said 600. I also need to show that this will work before I can put it on the intranet. So now I have the photos in a folder on my computer. I need to know if I can select only some photos and load them into a web page. Similar to ebays search or can it only be done with the photos on server side???
Thanks for your reply
what you want is to have a query that will show only details depending on the category that is being search..correct me if i'm wrong but i believe for example you search for the hammer..it wont show all the pictures on the hammer all you want is to select..well it really depends upon your database for example you have a row with this entry:
id | productname | picture
and there were 600 records you can limit the result on how many result will be shown or you can make a pagination for that purpose..
on server side unless you want to manually display your image on your html..
Similar to ebays search or can it only be done with the photos on server side???
Last edited by creedo; 02-22-2007 at 01:12 AM.
Thanks so much Creedo,
I am new to all of this. I had not heard of Pagination. A quick yahoo search has shown me what I may need.
Oh dear, maybe that is where I've been going wrong for the past nine years.
Originally Posted by ray326
Silly me, writing multiple user databases with Access 97, as it was the only tool available.
No, I didn't have anything sensible like Oracle or Java, they were only for Proper development not for Tactical (cheap) projects like mine.
Not super fast, but at least they worked for dozens of people at a time.
Still, after being laid off, I can now learn to use the proper tools for the job.
Anyway, Access forms and reports do have a picture object that can be used at a pinch.
As has been said, I too have found it better to store a link to the pictures and use that to call up the pictures on the forms and reports.
If price is a concern and the application small they can still be done right essentially for free. E.g. assuming zero cost for server hardware since it's a wash anyway, you can stand up a robust Java+DBMS or LAMP application for $0; considerably less than an Access+OS license.
Of course when it's "the only tool available" you go ahead and drive those screws in with that hammer.
Where I used to work I was near the bottom of the food chain, and as such had no input into the tools available (to me).
Unfortunately, as the years rolled on, my skills became more and more outdated. So, with spare time on my hands now, I look forward now to learning more up to date ones.
I may even get myself a screwdriver.
Last edited by Nanscombe; 02-22-2007 at 04:41 PM.
I highly suggest you store the images as BLOB instead of storing the path to the file. After working on a huge inventory database, you'll soon realize that storing the paths in the DB reduces flexibility--What if you want to move some of the photos to one server and the rest to another server?
In terms of back-ups, if the photos are stored as BLOBs in the DB, then you only have to back-up the database...if you store the file paths, you'd have to backup the database as well as the file folder on the webserver where your images are located.
If it's stored as a BLOB, then you won't have to deal with maintaining the file paths.
you were right sir but here are my reasons why you must not store picture in the database:
1.if there is any chance that you will migrate to a different database platform, your current BLOB format might be incompatible with, or at least a pain to convert to, the new format -- since, like web browsers, each vendor has implemented things with their own slant.
2.when your database really goes south, to the point where even the backup is useless, you still have the files on the filesystem .
3.having the images in the file system allows you to access the images from many different standard applications (FTP, web browser, etc) without having to write application code to pull the data out of the database, since you can't just 'SELECT image FROM table' and have the image appear in Enterprise Manager or Query Analyzer.
4.performance wise, including an <IMG SRC> tag generated by the database and pointing to a file that already exists is going to be faster than pulling the file out of the database, generating a temp file on the web server, and streaming that to the user. Also, table scans take more resources when there is an image datatype as opposed to a varchar that simply holds a 'pointer' to the file's location.
I have to agree with creedo on this one. Blobs are slow and storing the images in the database is actually less flexible than storing them in the database. If moving the files around is a required consideration then the host, path and filename can be stored in separate fields, making them more easily updated.
Also, as a DBA I can tell you that blobs really jack up the complexity of database maintenance.
If he only has less than 1,000 images for a "photo database", then a basic LAMP setup with images stored as BLOBs would perform well.
MySQL is a speed-demon.
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)