hello every body
i want to know how to import and export picture from Database using DAO control?
thanks
Printable View
hello every body
i want to know how to import and export picture from Database using DAO control?
thanks
Suz
My suggestion would be to NOT try to place a picture in a database.
Instead, create a field called PicPath (or whatever) and place the file path there
Then you can go to that record, get the path, and load the picture to wherever you need it.
Spoo
but the advantage of database is your picture is save and can't lose it..... i know it will take more space and maybe also picture loaded slowQuote:
Originally Posted by Spooman
but i think it's better to use database
The DB FAQ: Database - How can I store images (or other files) in a database?
Link uses ADO, but with little effort DAO can be used. ADO vs DAO? That's a different topic.
Suzoki,
You can stuff pictures into a memo field of a database. And there are several threads floating around in these forums on how to do that (some posted by me).
However, two things. First, I'm assuming that you're thinking about some MS-Access database. If that's the case, don't forget that those file sizes are limited to 2GB. And that's still true of the latest MS-Access formats.
Secondly, if/when you figure out how to get your pictures into the database, make sure it's done in some way that doesn't do Unicode expansion. Otherwise, each picture may wind up taking twice the space necessary to actually store it.
Personally, I'd tend to use some Zip/Unzip technology rather than a database. Tanner has a nice set of ZIP-like compression algorithms in the codebank.
If it's a static set of pictures, yet another alternative is to throw them into your project's resources, and then compile them into the EXE. Done that way, you're certain that they won't get lost.
Good Luck,
Elroy
If memory serves you can bind a picture box to your DB and the process becomes very simple.
thanks i will try and tell youQuote:
Originally Posted by LaVolpe
thanks Elroy i will check thatQuote:
Originally Posted by Elroy
what you mean (memory serves)?Quote:
Originally Posted by DataMiser
He means his brain's memory, which may not be serving him well (he could be forgetting).Quote:
Originally Posted by Suzoki
I would not be storing images into the DB, unless it was a couple of minor small passport photos or such.
I always have a sub folder in the same location as the DB.
Your program knows where the DB is, so you don't even have to store the path to your images.
You just have the name of the file (eg "mypicture01.jpg") in your DB, and your program can find it with both eyes closed.
Rob
+1 here, that's how I would do it alsoQuote:
Originally Posted by Spooman
regards
Chris
A 2GB database can store 40,000 50KB images just by rough calculations. Call it 20,000 to be conservative.
This means that in most cases you can safely ignore Chicken Little advice like that above. Unless you do something foolish like store uncompressed BMP format images you'll be fine. If they are compressed then a ZIP archive buys you nothing.
If you are really planning to store larger quantities than that then sure, another strategy might make more sense.
so I'am a careful Chicken thenQuote:
Originally Posted by dilettante
regards
Chris
also,you can use more then 1 database at the same timeQuote:
Originally Posted by dilettante
if you are using access, what version ?
from 2007 onward there is an attachment type, that compresses the file on loading and decompresses it on storing (if it is not already compressed)
and makes it very simple to do so (loadfromfile and savetofile methods)
https://msdn.microsoft.com/en-us/lib...ffice.12).aspx
https://docs.microsoft.com/en-us/sql...ile-method-ado
but i refrain from giving *any* advice
Without knowing specifics it is hard to make recommendations. You can take the most clumsy solution as a one-size-fits-all it just might not be optimal for several reasons.
For example storing the images as external files you can't directly use data binding any more. Of course it is quite possible to create your own UserControl supporting image data binding based on file names too.
The biggest problem with using a bizarre private data type is lack of portability. That's why Microsoft discourages the use of ACCDB formats for anything but simple MS Access applications.
Quote:
The Access Database Engine 2010 Redistributable is not intended:
1.As a general replacement for Jet (If you need a general replacement for Jet you should use SQL Server Express Edition).
2.As a replacement for the Jet OLEDB Provider in server-side applications.
3.As a general word processing, spreadsheet or database management system -To be used as a way to create files. (You can use Microsoft Office or Office automation to create the files that Microsoft Office supports.)
4.To be used by a system service or server-side program where the code will run under a system account, or will deal with multiple users identities concurrently, or is highly reentrant and expects stateless behavior. Examples would include a program that is run from task scheduler when no user is logged in, or a program called from server-side web application such as ASP.NET, or a distributed component running under COM+ services.
Personally I like storing images in a database.
1) Single suitcase for data and images aligns nicely with disaster recovery
2) Images stored in a share can be inaccessible (permissions, hardware failures, AD problems - the list goes on)
3) Mobile devices can get to the images without having to open additional holes in your firewall
and I'm sure some more could be added to this list.
Check this thread out - get down to post #35 for good info
http://www.vbforums.com/showthread.p...-DB-datasource
This will allow you to display the image WITHOUT a bound control and also without having to save it to disk first.
Suzoki,
1. will every record contain a pic?
2. what size are the pics?
Answer the above first. I'd suggest NOT storing the pics with the data unless they're small (~2-3KB each). Store the path to an image file instead.
1- yes but totally picture not more 50Quote:
Originally Posted by Bob_too
2- size of picture not more 50 kb
i already use DAO so what's the code for this optionQuote:
Originally Posted by LaVolpe
i am already success to save picture to database but when i want to import to image i can't
Code:Private Sub cmdAddPicture_Click()
Dim BytData() As Byte
If cmbPictureName.Text = "" Or Len(CommonDialog2.FileName) = 0 Then
MsgBox "error", vbCritical, "error"
Exit Sub
End If
Open CommonDialog2.FileName For Binary As #1
ReDim BytData(FileLen(CommonDialog2.FileName))
Get #1, , BytData
Close #1
F_P_P.AddNew
F_P_P("Name") = cmbPictureName.Text
F_P_P("Picture").AppendChunk (BytData)
F_P_P.Update
End Sub
Chicken.Quote:
but i refrain from giving *any* advice
Really? Never knew one didn't need to include the path! I'm going to give THAT one a try.Quote:
Your program knows where the DB is, so you don't even have to store the path to your images.
You just have the name of the file (eg "mypicture01.jpg") in your DB, and your program can find it with both eyes closed.
OK Rob....I typed in a jpg filename into a short-text field in a table. The actual image is located in a sub directory to where the program is being run. Without putting in a pathname, I get the old 'can't find filename xxx'. So, can you explain the 'both eyes closed' comment?
(error on last line, of course.Code:cmd.CommandText = "Select * from newtablename"Set rs = cmd.Execute
Picture1.Picture = LoadPicture(rs!pic)
Sammi
@sammi - I think you are missing the point here. If you CLOSE BOTH eyes you would never even see the error!
You took it out of context ... by removing the line before "I always have a sub folder in the same location as the DB" ... so the Images folder is always in the same location as the DB... if you know where the DB is (and you should), then you know where the images folder is. With that you can build the path, no need to explicitly store it.Quote:
Originally Posted by SamOscarBrown
-tg
Okay...in IDE mode, with pic in subdirectory or even in directory from which the project is run, I get the error.
When in .EXE mode, it works when the file is in the same directory as the .exe file, but NOT if it is located in a sub (separate) directory.
Is that what you meant...works if file is in .EXE directory when running in EXE mode???
Yeah....I miss a lot reading these posts, even with both eyes wide open!!!! Happens to all as we get older!
Cute response, szl!
Always happy to lend a hand!Quote:
Originally Posted by SamOscarBrown
As useless as that might be sometime!!
Hi,
well I supply always a INI-File with my Programs.
Inifile starts with the first run and the Folder(s) must be selected (created)
for Database Location (could be )Network
for Helpfiles
for Pictures
for Backup Location
regards
Chris
! Rooster !Quote:
Originally Posted by samoscarbrown
Regarding "no need to store the path" -
When the program loads, it gets the path to the DB, from an INI file
My program stores that into a global string, say globPathToDB
If the program is told to do something with say "Img001.jpg" it computes the path
RobCode:Dim sPathAndFile as string
sPathAndFile = globPathToDB & "Images/" & "Img001.jpg"
Hi Rob,Quote:
Originally Posted by Bobbles
I do it more or less the same way. I also use the main ID in the Form(Autoincrement of Mastertable) and
format that as Picture ID to the Database table and it is saved to the FotoDirectory with that
number
here part of the Format..
regardsCode:......
Msg = "Foto in Archiv übernehmen ? "
If vbYes = MsgBox(Msg, vbYesNo, "Foto") Then
zFile = "VO_" & Format(txtNr, "000000") & _
Mid(FotoFileName, InStrRev(FotoFileName, "."))
' lblFoto.Caption = zFile
txtFoto.Text = zFile
On Error GoTo Fehler
zFile = FotoDirectory & "\" & zFile
Me.MousePointer = vbHourglass
FileCopy FotoFileName, zFile
......
Chris