>I am writing a VFP program to gather information on collectibles sold and for sale on ebay. My program uses some techniques presented in the June 2000 FoxPro Advisor article, “Automate Internet Explorer from VFP,” by Erik Moore. (Thanks again, Erik.)
>
>My program is now to the point where it can pull up a page on an auction item of interest. I can grab the table data and the text description no problem. If I had accessed the page using only IE (without a FoxPro program), there would usually be one or more pictures on the computer screen. From the elements of the web page, I have all the picture URL’s in an array. I want to grab and keep the pictures.
>
>I have two questions.
>
>1) How do I write the picture (usually a jpeg) to a file on my hard drive?
Just like any other file on the drive; it needs to be in a virtual directory that can be read and sent over the wire just like any other file referenced by URL.
>
>2) Is there any disadvantage to keeping each picture in a general field in the database, as opposed to cluttering up the hard drive with thousands of individual picture files? (I prefer to keep the pictures in the database to reduce disk clutter.)
>
General fields require far more space than an image itself, and are not easily extracted from the general field back to their typical format. You could save the file into a memo field and extract it to a file on demand using STRTOFILE() to extract it to a name used in your HTML, or simply store the path of the file in your table and insert that string in your HTMLto fill in the name of the image. If you're worried about clutter and space, the images could be stored in a Zip file and extracted on demand when required, compressing the images; the VFP tableholds the name of the image and the file which holds it compressed. In most situations, storing the name of the image file, and having separate filesis easiest to handle; in the event that one image gets mangled, the damage is isolated to a specific file rather than the set as a whole, and requiring extra processing to use. Disk space is cheap, and many fie systems don't degrade as much as FAT from having many directory entries - NTFS uses an indexing scheme to manage entries, Netware uses hash table lookups when searching directories, and caches directory information so that it minimizes disk read time to process directory entries, so using one of these schemes to hold the images may improve the time to search directories and open files, and bot offer file compression through their normal file systems via both LZ compression and file suballocation, so the advantages of zipping may not be large. And working with a smaller data table offers performance advantages, too.
This is not a blanket condemnaton of storing images in tables. I feel General fields in particular are a bad choice, especially here, where you intend to use what you might store in General fields stand-alone without the same OLE Server providing the interface to the embedded object (displaying them outside of the General field in the VFP app). Backup is significantly simpler to define where all data resides in a single, explicitly known file name. Replication is easier. If I want to take a small part of the database home to work on or demo, with separate files, I not only need the database subset, I have to get the specific separate files that pertain to that set of records, too. So there are some reason for retaining them in a common store.
Unless the number of images would have to be extremely large, I'd try to keep them separate. My secodn choice would be to store them in a Zip file and save the name of the entry in the Zip file or files. If I saved them in the database, I'd at least use a memo field rather than a General field to store them, to avoid the headaches extracting data from General fields without the OLE Server for the file type offering a simle way to do that.
>Thanks!
>
>Rick Graves (displaced American currently residing in Hong Kong)
