Derek,
Using the Database Connectivity Toolkit, it's as simple as writing the JPG bytes to the blob field in your record, unless there is a need to escape certain characters. I had no such need in my tests.
I tried this out with a simple test database. My table structure consisted of (ID, name, description, image), where ID was an int, name and description were text fields, and image was a blob. I think I limited the blob field to 500,000 bytes when I defined the DB. To update a record, I just used "DB Tools Insert Data" and fed it a cluster of int, string, string, string; the image string was simply the output of "Read Characters from File" where I specified my image via its path on my hard drive. I happened to use PNG images instead of JPG, but it shouldn't make any difference.
I've attached my example (LV 7.0), and I can do a screenshot instead if you want it. One caveat: looking around the Web, most developers seem to discourage the use of blob fields to hold image data in relational databases, suggesting that you store the images on the filesystem instead and use the database for meta information about the images (filename, image type, description, etc.). I know absolutely nothing about the overhead associated with choosing particular field lengths for blob fields, but I'll bet it is typically more efficient to follow this advice and store the images on the filesystem instead--no wasted bytes that way, since that's what a filesystem is made for.
Hope this helps,
John
