I have a base64 encoded image stored in my database as a blob, and I want to insert it into a Crystal Report without a fileupload field. I looked all around the internet and can only find ways with a file upload field.
I read somewhere that you need to load a binary code in sql if you want to display an image.
So I have a binary code in MSSQL/MySQL server with varbinary(max) that I load into the crystal report, but the image is still not showing. I do see that it's an image though because I see the red X.
Should I still convert the binary value that I have from sql server to something? Is what I'm trying to do even possible? If so, please describe the way to do it.
Related
A table containing almost four thousand records includes a mediumblob field for each record that contains the record's associated PDF report. Under both MySQL Workbench and phpMyAdmin the relevant DOCUMENT column displays the data as a BLOB button or link. In the case of phpMyAdmin the link also indicates the size of the data the Blob contains.
The issue is that when the Blob button/link is clicked, under MySQL Workbench opening any of the files using the SQL Editor only displays the raw Blob data and under phpMyAdmin th link only allows the Blob data to be saved as a .bin file instead of displaying or saving the data as a viewable PDF file. All previous attempts to retrieve the original PDFs using PHP have failed - see related earlier thread: Extract Pdf from MySql Dump Saved as Text.
The filename field in the table shows that all the stored files are PDF files. Further research and tests indicate that the mediumblob data has been stored as application/octet-streams.
My question is how can the original PDFs be retrieved as readable PDFs? Is it possible for a .bin file saved from the database to be converted or used to recover the original PDF file?
Any assistance would be greatly appreciated.
In line with my assumption and Isaac's suggestion the only solution was to be able to speak to one of the software developers. It transpires that the documents have been zipped using an third-party library as well as the header being removed before then being stored in the database.
The third-party library used is version 2.0.50727 of Chilkat, available from www.chilkatsoft.com. That version no longer appears to be available, but hopefully at least one of the later versions may do the job.
Thanks again for everyone's input and assistance.
Based on the discussion in the comments, it sounds like you'll need to either refer to the original source code or consult with the original developer to determine exactly how the data was stored.
Using phpMyAdmin to download the mediumblob data as a file will download a .bin file in many cases, I actually don't recall how it determines content type (for instance, a PNG file will download with a .png extension, but most other binary files simply download as a .bin when phpMyAdmin isn't sure what the extension should be, PDF included). So the behavior you're seeing from phpMyAdmin is expected and correct, but since the .bin file doesn't work when it's renamed to .pdf that means something has probably gone wrong with the import and upload.
BLOB data is often stored in a pretty standardized way, but it seems your data doesn't follow that method.
Without us seeing the code directly, we can't guess what exactly happened with storing the data and would only be guessing.
When I import a csv to Tableau, it gets the same format of the original csv file (a single column with every label on it). How can I make Tableau separate the columns based on commas?
I can't see why this is happening, since in every tutorial I checked Tableau already converts the .csv to a tabular format.
Here's what I get
Note: I'm using Tableau's trial version.
Sometimes when you open a csv in Excel it can mess with the formatting like your image shows. If you think you opened it in Excel before connecting, try downloading your source again and connecting first with Tableau. If that doesn't work, I happen to have this dataset in a .tde if you would like to use that. vgsales.tde
Edit: Thinking regional settings might be a factor.
Click the dropdown on the right of the data source. Select Text File Properties
To get this window:
Can you match these settings?
Looking for some guidance here. I am building Nodejs/Express app with MySQL Database. I want to be able to click on the users image on the web page (initial image is generic), select a different image and upload/save new image into MySQL database. I using:
$('#file-input').trigger('click').change (function(){
alert($('#file-input').val());
})
I get C:/fakepath... for image location. I would like to how to upload/save selected image to the MySQL database. Connection to database is established, and routes for regular data work just fine.
Before answering your question will suggest you to not save image into your MySql or any database, use IPFS, local application directory/folder, or best AWS s3 bucket.
You can use busboy.js NPM module or multer.js NPM module for file upload to server, there's lots of good reason to not save any kind of file in local database.
Now back to how you can save image in database. You can do so by first converting your image to a data format your MySql understand. By default image is binary and depending upon image selected some image binary is so big that even MySql text datatype is small for them. Converting binary to hexadecimal does help but still too big for MySql text datatype. Also you will need multipart/form-data for file upload.
You can easily find "How to upload file in nodeJs?" in a google search. Still if need an example here's one "Upload file using multer.js"
I use Access 2007
I have created an OLE field to store JPEG, so I can easily drag them into DATABASE.
That works. Trouble is: This field does not dispaly the JPEG but the generic JPEG thumb and I need to double click to open the JPEG and preview it.
Is there a way to preview JPEG without having to double click on it ?
regards
Have you considered storing your images entries for your database as 'text', and simply store the path for the image(//pics/mypic.jpg), rather than the image object itself? If your database is on a shared drive, you can create a folder in the same folder as your database to hold your images. When inserting an image, you can have a textbox and simply type the relative path to that image. This will prevent your database from inflating in size. From there, it is just some simple code to display the picture.
After setting your database up to just store the path names of the images, you can follow these easy instructions on how to display these images on forms : Microsoft Knowledge Base
I recently switched a couple of my databases from using OLE's to text fields with the path name of the picture and am really satisfied with it.
You will need to use an Attachment data type to display anything other than bmps. Only bmp images will display in an OLE field (see the Northwind sample database for an example, the Employee form shows bmp images stored in an OLE field).
Alternatively, you can store the path to the image and show it in your form with some VBA. In general, it is best to store paths to images, rather than images, even with databases that have much higher size limits.
We're converting a legacy, SQL Server 2000 database to SQL Server 2008. Both store binary files (JPG, BMP, DOC, and PDF) in an IMAGE column (I know the datatype has been deprecated, but changing this is not an option).
The data is inserted the new system with a basic
INSERT INTO [image] Values (SELECT [image] from legacy_db);
basically a straight IMAGE to IMAGE push.
The conversion had been going well. On the new system, the JPG, BMP, and DOC file types opened without problems. The PDFs have been a nightmare.
We've found that for the PDF records, many of the rows that have been moved into SQL Server 2008 have a longer DATALENGTH() than the same rows did in the SQL Server 2000 database.
Does anyone have any clue as to why this is?
I'm not sure about the DATALENGTH() issue but as a workaround, if the PDF files are correct in the 2000 database (I assume you've verified this), you could try pulling those values from an app and re-saving them in the new table from the app, instead of just doing an INSERT/SELECT.
Resolved this issue by writing functions to locate the PDF's BOF marker and EOF marker(there can be multiple EOF markers so you have to find the last one). Stuff the bytes between the two offsets, inclusive, into a new byte array and UPDATE the BLOB field with the new byte array. After this, the PDFs open in the new system.