I'm devoloping a website which is integrated with another system around the organization.
One of them is a microsoft access program that is storing the images in varbinary data type at mssql..
trying to display those images in my website cause broken images and it won't work, when ever I store my own images (sent from my website) it's working fine (converting it to base64 and so).
My guess is that the ms program is storing the images as adodb stream (blob).
How can I display those images? they are extremely important
Related
I want to store images into database using java server pages or struts via html.
time complexity and space complexity should be as less as possible.
which way is effective to store images into database using java server pages through html?
how to do that too?
is there any simple coding using Struts 2.1 for this task
I don't know your exact need, but What I suggest is instead of storing images in DB, just store name of the images as say "abc.png" in table and store the actual image in one folder and make that image folder where you are storing as configurable in properties file.
Now you can read property file and get path then just give name of image like
pathYouGetFromProprtyFile + File.seperator + imageNameYouGetFromDB
Hope this helps.
I would suggest you to convert the image to bytearray or BLOB/CLOB data format and store it in database.
From web tier you can use fileupload to upload the image, store it in temp server location. Change it to ByteArray and save it in database either using JDBC or hibernate.
Hope it will help you!!!!
I am trying to create a business directory application for my area, I am currently trying to create a sql DB with all of the realivant business information (name, address, opening hours etc). I am then plan to have a physical file directory where all logo images are stored, this directory will be stored somewhere on the server.
When the user starts the applicatoin they will be prompted to download all of the information on business listings (because its for a small community), I will then upload all of the data to the phone using NSURLConnection, the data will be Zlib NSData in the form of XML. I will store all of this data into coredata (which will act as the apps cache).
The next step is to download the directory of images I have stored on the DB.. but I have no idea on the best approach for this and would like some guidance, example code etc.
For instance would it be better to store the images into the sqlDB? I have read this is a bad idea so am trying the approach explained above.
I am still in the process of building the sqlDB but the difficulty I am having is comming up with a way to get the images onto the device and relate them to the correct business using an id field or something simlar.. or is there an easier way to do this?
any help would be appreciated.
Instead of storing the image directly in the DB, you could store the URL to access the image binary instead. This would maintain the relationship with the image without storing the large image data directly in the DB. You could then use the URL retrieved from the DB to download the image on the device and similarly store the path to the downloaded cached image in core data.
I am trying to prepare a sample question paper preparation app.
I am using tinyMCE editor and ajax-file-uploader plugin with it - as some questions may need images along with text.
How do I store my questions that have both image and text into MySql using PhP?
I would suggest storing the image on some sort of NAS or some other location, and store the path to the image in the database along with the other data in respective fields.
You can store the image in the DB but it is not good idea to retrieve and present the image from the database to the user (It doesn't perform that great either). There might be a performance hit
MySQL handles images very well. You insert them in BLOBs. On the other hand you could store the image file name and path or a link, as text in your DB.
Which solution is the best depends on the requirements of your application. In general if you have a huge amount of images, your database will become huge and backing up will be slow. There might be a similar impact on your file system in order to store a huge amount of images.
Here is the interesting Microsoft To BLOB or not to BLOB paper, that will give you more information on the topic and even some metrics.
I would echo the answers already given by #harigm and #Costis Aivalis but if you really wanted to go "all out" and store both the HTML content and the images in the same BLOB why not have a look at RFC 2557 which allows you to place binary data (like images) in the document itself using the url scheme data:. To make this work you will need to parse your HTML once it gets back to your server and base64 encode all the images to be placed in the HTML, quite a lot of work for what would probably turn out to be little reward.
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
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).