Hey Guys and Gals!
I need some assistance with a database related idea.
I built an inventory database system for our office which allows us to track and order office and medical supplies when needed. Recently, I decided that I'd like to associate an image with each item in the database. Ultimately, the goal is for upon performing a lookup for an item, that along with pricing and item information, that also an image of the item is displayed as well.
This is something that I've never tried to do before, but wanted to see if anyone had an idea how to do that. I'm using MS Access 2007.
Thanks!
See if you can't use LOB Large objects in MS Access, I know you can in larger databases Oracle etc. If not the next alternative is to just store a link to a picture of the item so people can look it up if they have too. For the link if you use single storage location and make sure there are no spelling mistakes.
cheers
humm....
I'd rather not use a link if I can avoid it - takes away from the "magic" of what the system can do.
I'll see if I can do something with LOB.
Thanks!
Other ideas??
http://office.microsoft.com/en-us/access-help/store-images-in-a-database-HP005280225.aspx (http://office.microsoft.com/en-us/access-help/store-images-in-a-database-HP005280225.aspx)
Now why hadn't I thought to look to Microsoft for the answer....
[roll]
Thanks. [thumbsup]
One thing to note is that ACcess stores the image as a BMP which will inflate the size of the database -- no compression format.
If you use small images or a standard size with a reduced palette you might be able to control it a bit.
Quote from: ducatiz on May 13, 2011, 11:37:44 AM
One thing to note is that ACcess stores the image as a BMP which will inflate the size of the database -- no compression format.
If you use small images or a standard size with a reduced palette you might be able to control it a bit.
That's a
really good point. Especially since I'm planning on using it for a LOT of items.
Quote from: Monster Dave on May 13, 2011, 11:42:27 AM
That's a really good point. Especially since I'm planning on using it for a LOT of items.
I use this fun little photo program called Paintshop Pro which has a macro function -- so you can automate shrinking and converting photos if you want. I did it once for a catalog a friend made -- converted all her pics to 64 pix high and only 32 colors in the palette. This shrunk the per-image size to around 3k
Quote from: ducatiz on May 13, 2011, 12:07:26 PM
I use this fun little photo program called Paintshop Pro which has a macro function -- so you can automate shrinking and converting photos if you want. I did it once for a catalog a friend made -- converted all her pics to 64 pix high and only 32 colors in the palette. This shrunk the per-image size to around 3k
I've got this nifty little suite called CS5 that may do something along those lines...
[cheeky]
Quote from: Monster Dave on May 13, 2011, 12:17:48 PM
I've got this nifty little suite called CS5 that may do something along those lines...
[cheeky]
Suiiiite
I thought you were asking about databases, not Access. :)
Quote from: sugarcrook on May 13, 2011, 02:08:13 PM
I thought you were asking about databases, not Access. :)
OH SNAP!! [roll]
If you have multi-users , then you will hate access due to locking issues when many users are accessing rows located nearby. Page level locking, table level locking , row level lockings are issues to think about.
If you can swing it, why not use SQL Server and write an aspx web form or even better MVC framework.
Quote from: ab on May 15, 2011, 05:50:29 AM
If you have multi-users , then you will hate access due to locking issues when many users are accessing rows located nearby. Page level locking, table level locking , row level lockings are issues to think about.
If you can swing it, why not use SQL Server and write an aspx web form or even better MVC framework.
I've split the database so that as many users as needed can use it without any problems.
Quote from: Monster Dave on May 15, 2011, 08:51:15 AM
I've split the database so that as many users as needed can use it without any problems.
there's something to be said for ingenuity....
however, there's
also something to be said for using the right tool for the job. ;D
Two things FWIW:
1) I can only use the tools at my disposal.
2) I can only use the tools that I know how to use.
We don't use Oracle, so that's not even a consideration. I do use SQL to some degree - but I know how to best integrate a slick GUI with Access. There's no sense in changing what's already been built to accommodate SQL as a back-end unless there was something major in the pipeline to warrant that sort of a change.
Quote from: Monster Dave on May 15, 2011, 06:50:53 PM
I do use SQL to some degree - but I know how to best integrate a slick GUI with Access.
who says you can't use access as a front end for a sql database? ;D
Quote from: Monster Dave on May 15, 2011, 06:50:53 PM
There's no sense in changing what's already been built to accommodate SQL as a back-end unless there was something major in the pipeline to warrant that sort of a change.
well, the "right time" for that was probably when you broke it out into multiple databases to prevent issues with locking.
not that what you've done is "bad," just the further down that road you go, the more work it's going to be when you eventually
have to move it to SQL. ;D
(just speaking from ~20 years of IT experience)
Quote from: derby on May 15, 2011, 07:33:40 PM
who says you can't use access as a front end for a sql database? ;D
Quote from: Monster Dave on May 15, 2011, 06:50:53 PM
Two things FWIW:
1) I can only use the tools at my disposal.
2) I can only use the tools that I know how to use.
We don't use Oracle, so that's not even a consideration. I do use SQL to some degree - but I know how to best integrate a slick GUI with Access. There's no sense in changing what's already been built to accommodate SQL as a back-end unless there was something major in the pipeline to warrant that sort of a change.
teach him massah derby... ;D
Quote from: derby on May 15, 2011, 07:33:40 PM
well, the "right time" for that was probably when you broke it out into multiple databases to prevent issues with locking.
not that what you've done is "bad," just the further down that road you go, the more work it's going to be when you eventually have to move it to SQL. ;D
(just speaking from ~20 years of IT experience)
meh, i have a VB script somewhere that merges Access databases. It requires a lot of tweaking.. I wonder if it will still work, it was for Access 97
I really don't see what the problem is with Access. It's a very useful system and I've not run into many problems with it.
Derby, I'm sure you know what you're talking about with that much IT experience, but splitting the database wasn't anything hard and really all it did was create a bunch of linked tables from those that I had already built. A transition to SQL would have been a lot more work. It took me all of 5 minutes.
[roll]
derby is offended by technological inferiority.
why use a hammer if you can use a pneumatic nail driver? i mean, even if you only want to hang one measly little picture on the wall. why?
Quote from: Monster Dave on May 16, 2011, 09:13:41 AM
I really don't see what the problem is with Access. It's a very useful system and I've not run into many problems with it.
there's nothing wrong w/ access. it's a good tool until it isn't. ;D
Quote from: ducatiz on May 16, 2011, 09:26:52 AM
derby is offended by technological inferiority.
why use a hammer if you can use a pneumatic nail driver? i mean, even if you only want to hang one measly little picture on the wall. why?
it probably comes from the environments i've worked in. traditionally, the database admins/developers tend to use oracle/SQL and the "end-users" use access.
the access databases are usually "off the grid" without any official sanction from the MIS departments and, as such, aren't properly backed up. "we" usually find out about those when the "developer" gets in over their head and requests help from one of the (oracle/SQL) dbas or they bork it up to the point that they need to revert to a backup (which doesn't exist because "we" didn't know about it).
Gotcha!
Quote from: derby on May 16, 2011, 11:05:13 AM
it probably comes from the environments i've worked in. traditionally, the database admins/developers tend to use oracle/SQL and the "end-users" use access.
the access databases are usually "off the grid" without any official sanction from the MIS departments and, as such, aren't properly backed up. "we" usually find out about those when the "developer" gets in over their head and requests help from one of the (oracle/SQL) dbas or they bork it up to the point that they need to revert to a backup (which doesn't exist because "we" didn't know about it).
and you should be thanking Bill Gates for that because it results in the perceived need to have a large IT staff on call 247. jobs jobs jobs!