Making e-mail attachments directcly from a BLOB/OLE data field using VBA/MS Access
I have the e-mail attachments working in my built in e-mail module, but the user has to identify the attachment by file location, so to attach any embedded documents requires them to open and save them to their hard drive first.
The client wants to attach documents already embedded by means of a file loaded through MS Access/OLE and stored in the BLOB field of a MySQL database. The client naturally wants to just identify that document in the software and have the software make the attachment to the e-mail without having to export and identify it in a file location first.
Since the app can have any manner of file types embedded, although most are MS Word documents, are there any viable options to improve the user experience around making e-mail attachments directly from the OLE field, or by pulling it out of the MySQL database and orchestrating the attachment behind the scenes based on having the user just identify the document in the application?
I think loading them through OLE puts a wrapper around the data in the BLOB field so it has to come out via OLE as well?
If they were linked, I imagine we could just use the same path, but this isn't a viable solution as embedding the documents solves other issues for the client, and we don't want to throw the baby out with the bathwater... :)
Thanks!
The client wants to attach documents already embedded by means of a file loaded through MS Access/OLE and stored in the BLOB field of a MySQL database. The client naturally wants to just identify that document in the software and have the software make the attachment to the e-mail without having to export and identify it in a file location first.
Since the app can have any manner of file types embedded, although most are MS Word documents, are there any viable options to improve the user experience around making e-mail attachments directly from the OLE field, or by pulling it out of the MySQL database and orchestrating the attachment behind the scenes based on having the user just identify the document in the application?
I think loading them through OLE puts a wrapper around the data in the BLOB field so it has to come out via OLE as well?
If they were linked, I imagine we could just use the same path, but this isn't a viable solution as embedding the documents solves other issues for the client, and we don't want to throw the baby out with the bathwater... :)
Thanks!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Curious why you graded this a B? The link I provided to the EE solution is the way to write out contents to a disc file. I realize it's not the simplest thing to do, but if you needed help implementing this, you should write back here and ask.
ASKER
Hi Scott, didn't mean to short change anyone, it's just that a functional solution would need to address all the functionality built into the OLE Field, such as what type of file it is. The code assumes the file type is known, which in my current app is handled by the OLE functionality. The needed solution, if one exists, would have to start with an embedded Word document, automatically take it out, place it in a folder and pass the path with filename and extension to the e-mail code to include as an attachment. Even this is a partial solution, as it might not be a Word document as it could be a .doc instead of a .docx, or a .pdf, or .xls or .xlsx, etc, etc.
My point is this: Without responding to Expert comments to give us a chance to help you flesh this out, you instead closed this with a B grade. That's not the way EE works - you're expected to post back here and continue working with the Experts to come to a more complete solution. If you don't do that, then we don't know you need extra help.
As far as identifying what's in a BLOB - that can be very difficult to do, and is somewhat of a moving target. There are "magic numbers" stored in the first 20 characters or so, but these can be deceiving as well, and they sometimes change - so you cannot reliably use those to determine the file type. The only tried-and-true way to do this is to store the FileName and FileType data when the BLOB data is inserted.
As far as identifying what's in a BLOB - that can be very difficult to do, and is somewhat of a moving target. There are "magic numbers" stored in the first 20 characters or so, but these can be deceiving as well, and they sometimes change - so you cannot reliably use those to determine the file type. The only tried-and-true way to do this is to store the FileName and FileType data when the BLOB data is inserted.
ASKER
Thanks Scott, I understand the intent of EE. It was just that for this particular issue, I basically had to determine if there was an easy solution, or if the solution was going to be too much work to tackle right now, as I would have to redesign a major component of the software. I guess it was counter intuitive to give an A for "there's no easy answer, and you'd have to build it yourself," even though that is probably the correct answer, and maybe deserves an A nonetheless.
Yup, sometimes "there is no answer" or in this case, the fact that it's an answer you don't like is the correct answer.
As the old saying goes...don't shoot the messenger<g>
Jim.
As the old saying goes...don't shoot the messenger<g>
Jim.
ASKER