Background: We have an old (but business-critical) SQL Server database with an MS Access ADP front-end; this was originally upsized to SQL Server from a series of Access databases.
This database tracks hazardous materials for our customers, and stores a large number of images. These images are inserted from MS Access, and get put into the database as OLE Objects.
The problems are:
These are a pain to read out in anything except Access/Office
There's a MASSIVE storage overhead - ~10GB of images takes up 600+ GB of storage space(!)
My question is this: what way would you recommend to convert these bloated objects back into simple JPEGs? Once we do this we can finally migrate our front-end from Access and onto a simple web-based system, and our backup times will become manageable again!
Take the *.bas file from here http:http://stackoverflow.com/Content/img/wmd/ul.png//www.access-im-unternehmen.de/index1.php?BeitragID=337&id=300 (unfortunately it is German).
It uses the GDI+ lib from MS (included in Win standard installation) to import/export pics to/from Access OLE.
Rough translation of interface:
IsGDIPInstalled: Checks for installation of GDI+
InitGDIP: Init of GDI+.
ShutDownGDIP: Deinit of GDI+ (importand to be used!)
LoadPictureGDIP: Loads pic in StdPicture object (bmp, gif, jp(e)g, tif, png, wmf, emf and ico).
ResampleGDIP: Scales pic to new dimensions and sharpens if needed.
MakeThumbGDIP: Makes thumbnail and fills border with color.
GetDimensionsGDIP: Get dimensions in TSize-Struktur in pixel.
SavePicGDIPlus: Saves Picture objekt in file as BMP, GIF, PNG or JPG (jpg with given quality)
ArrayFromPicture: Returns a byte array of picutre to put pic into OLE field of table
ArrayToPicture: Creates byte array of OLE field of table containing a picture
Here is the link again: http://www.access-im-unternehmen.de/index1.php?BeitragID=337&id=300
Use Access MVP Stephen Lebans ExtractInventoryOLE tool to extract the OLE objects from a table to separate files.
http://www.lebans.com/oletodisk.htm
According to Lebans: "Does NOT require the original application that served as the OLE server to insert the object. Supports all MS Office documents, PDF, All images inserted by MS Photo Editor, MS Paint, and Paint Shop Pro. Also supports extraction of PACKAGE class including original Filename."
Also, Access 2007 stores OLE objects much more efficiently than the historical BMP formats of previous versions, so you would have a smaller storage space and be able to keep your Access app if you converted it from the 600+GB storage of SQL Server to Access 2007 accdb format. Your backup times would be manageable and you wouldn't need to spend time converting an Access front end to a web front end.
I think the reason your database becomes so bloated, is that the JPGs are also stored as bitmaps inside the "OLE object" structure, or so I've seen, depending on the method the JPEG was inserted.
This is not optimal, but: for every image in the database, I would programmatically create a dummy .doc containing just the image, then pass it through OpenOffice conversion, and extract the JPEG from the images subfolder of the produced OpenOffice document (which is a ZIP file).
I would then replace the OLE documents in the database with the raw JPEG data, but then I have no way for you to plainly display them in a custom application (unless it's a web app).
Related
Just for some background, I'm a mechanical engineer at a company and the older folks here created a database in Access 2003 which basically takes an AutoCAD Drawing or a Picture OLE and plops it in a nicely framed report with a bunch of other information. I've been making some modifications to that database, one of which is to store all OLEObjects as links to actual files in our shared network. Every new file that has been added to the database for the past week or so has been linked and the guys seem to have gotten the hang of it.
My problem at this point in time is to try and retrieve all the Objects that are embedded in the tables. I've tried Lebans OLE to Disk but that doesn't seem to work with AutoCAD Drawings (which are .dwg and .dxf files) nor does it work with "Picture".
I know this is a quite controversial topic seeing as how I'm not providing any code to start with, but I think this is too complicated for me to even begin doing and I'm in over my head. Extracting the OLEObjects by hand isn't feasible since there's over 8000 of these spread through several databases. Is there any way to automate the extraction via code?
Thanks in advance,
Rafael.
If you access the Object property of the Bound Object Frame control, for an AutoCAD Drawing this should return the AutoCAD Document Object. You can then invoke the SaveAs method of the Document object to save the file to a known location.
For example, something like:
With Me.MyBoundObjectFrame.Object
.SaveAs "Drive:\YourPath\YourDrawing.dwg"
End With
Where MyBoundObjectFrame is the name of your Bound Object Frame control.
This works successfully in my limited testing.
I have a website which is using SQL SERVER 2008 which allows user to upload files like excel, word, txt, pdf, media files and other format also. (Just like Rapishare, Megaupload)
What is the best way to store them into SQL SERVER ?
FILESTREAM or VARBINARY(MAX), but you should consider the pros and cons of doing so versus storing the files on the file system and just a pointer to the file in the database.
Pros for storing files in the database:
transactional consistency
security (assuming you need it and that your database isn't wide open anyway)
Cons:
much larger database files + backups (which can be costly if you are hosting on someone else's storage)
much more difficult to debug (you can't say "SELECT doc FROM table" in Management Studio and have Word pop up)
more difficult to present the documents to users (and allow them to upload) - instead of just presenting a link to a file on the file system, you must build an app that takes the file and stores it in the database, and pulls the file from the database to present it to the user.
In SQL Server 2012, FileTable will offer a more usable hybrid.
Since you use SQL Server 2008 you might look into the filestream feature. This should be an efficient way to store binary data from files with sizes over 1 MB file size.
I am using Sencha Touch to capture data from a user on an iPad. This includes a standard form (name, email, etc.) as well as the customer's signature (see the plugin here).
Essentially, the plugin takes the coordinates from the user's signature and gives me back Base64 PNG data.
Once I have the signature data, I want to store it. My two questions are:
Should I store the Base64 data in my
(MySQL) database along with the rest
of the user's information, or should
I create a static file and link as
necessary?
If storing in the
database is the way to go, what data
type should I use?
There's no need to base64 encode the image. MySQL's perfectly capable of storing binary data. Just make sure you use a 'blob' field type, and not 'text'. text fields are subject to character set translation, which could trash your .png data. blob fields are not translated.
As well, base64 encoding increases the size of text by around 35%, so you'd be wasting a large chunk of space for no benefit whatsoever.
However, it's generally a bad idea to store images in the database. You do have the advantage of the image being "right there" always, but makes for absolutely huge dumps at backup time and all kinds of fun trying to get the image out and displayed in your app/web page.
it's invariably better to store it externally in a file named after the record's primary key for ease of access/verfication.
Just save files in BLOB field. Such PNG file shouldn't be larger than 1KB if you turn some optimizations (grayscale or B/W).
Storing files outside DB seems easy but there are things to consider:
backup,
additional replication if multi-server
security - access rights to files dir, but also to files,
no transactions - e.g. DB insert ok but file write fails,
need to distribute files within multiple directories to avoid large dir listings (depends on filesystem capabilities)
Blob will store Base64. It will get you what you need. Storing it in the database gives you built in relational capabilities that you would have to code yourself if you stored it in a static file. Hope this helps. Good luck sir.
Edit: mark's right about binary v. base 64
Set your field as Blob data type, it stores perfectly base64EncodedString
ORIGINAL QUESTION (How can I display images from a MySQL database in an Access 2007 form?)
I would like to use Access 2007 to interface to a MySQL database and display pictures and other data in a form.
I already have an Access 2007 application that I don't want to change much, if I can help it. I'm just not sure what data type will work. "Attachment Data Type" is not supported in MySQL. Also, my client wants to be able to open and edit the image.
SOLUTION to UPDATED QUESTION
(How can I work around the 2GB database limit of MS Access (for displaying images)?)
(1) Store the filenames of the images in MS Access
(2) Use VBA to dynamically display them in a form (see How to display images from a folder in a form, a report, or a data access page).
To make the images editable:
(1) Make sure the file type (e.g. ".jpg") is associated with the image editor of choice.
(2) Using the same variable names as in the article mentioned above, add the following code to the form in which ImageFrame is located (see How to open a file in its default application using VBA)
Private Sub ImageFrame_Click()
Application.FollowHyperlink (txtImageName)
End Sub
A few other sources that may be useful
Perl, MySQL, and Blobs
VB, MySQL, and Blobs
Using images in Access
Using MS Access as a front end to PostgreSQL.
A special thanks to MindStalker for his comment that got me started on yet another round of "Googling".
See the solution mentioned in the question above.
I have a .NET webforms front end that allows admin users to upload two .xls files for offline processing. As these files will be used for validation (and aggregation) I store these in an image field in a table.
My ultimate goal is to create an SSIS package that will process these files offline. Does anyone know how to use SSIS to read a blob from a table into its native (in this case .xls) format for use in a Data Flow task?
In my (admittedly limited) experience with SSIS, it is quite good at rapidly getting something up and running, but frusteratingly limited in getting something that "feels" like the most elegant, efficient solution to a programmer.
Since the Excel Source Editor seems to take only files as input, you need to give it a file or reimplement its functionality in code that can take a blob. I understand that this is unsatisfying, but in the end, this is a time saving tool.