Unless you are referring to a SQL database blob field, I the 2Gb limit will rear its ugly head very quickly in a Foxpro table when dealing with pictures.

I have an application I built for a medical situation where users took pictures of the patient for future reference and better customer service. My solution was to allow the user click in the photo display area to add a photo and then using getfile open a window for them to select the correct photo. Once the original photo was selected, I generate a random file name using SYS(2015) and copy the original file to a subfolder under the application folder where all patient photos where stored with the randomly generated filename. Finally, I stored the full path & filename of the picture in a character field of 254 characters in the patient table.

By using the subfolder, I could insure the pathnames are never too long and by using the randomly generated filename, if someone opens the storage folder, they cannot easy connect any photo to a particular patient. Because we copied the original file to our preferred location, I didn't have to depend upon a user to a) name the file, or b) put it in specific location. And, because I only store the path to the file, I get around the 2Gb limit regardless of the size of the pictures. If I had it to do over again, I might even consider doing a resize on the files during the copy process to keep the files as small as possible. Within the application, when a user pulls up a patient, if we find a path in the table and the file exists, we display the photo (never the path or filename). If the user wants to upload another pic, they just click on the photo and we provide a menu to them to replace or delete the file. If a path has not been saved or a file does not exist, we display a standard "Photo Not Available" graphic and if they click on this, they can add a photo.

It is may not be a perfect solution, but it seems to work for this situation.

Paul H. Tarver Tarver Program Consultants, Inc.

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Jürgen Wondzinski Sent: Tuesday, August 16, 2022 4:07 AM To: profoxtech@leafe.com Subject: AW: Pictures in a table

Hi Ken, There is now that funny thing called BLOB-Field. Your advice was relevant for those dark times where we only had that General fieldtype. Now, the BLOB is a Memofield like the General-Field, but it just stores Binary data without any OLE-Information. You basically write the picture-file content into that field, therefor you can always restore it to a real picture file or just bind it to the PictureVal property of an ImageControl.

Create table Pictures (title C(50), content W) Insert into Pictures (title, content) Values ("My Picture", GetPict("JPG") )

On your form you just add an image control and set Pictureval = "Pictures.content")

-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von Ken Watkins Gesendet: Montag, 15. August 2022 20:36 An: ProFox Email List profox@leafe.com Betreff: Pictures in a table

Hi ProFoxers.

I haven't posted in a decade or two, but I'm still hanging around.

I am writing an app for my son to manage his business. He's a therapist and routinely jots down notes on a small notepad during his client sessions. He later adds typewritten notes into the client record but he also takes a picture of his handwritten notes and copies/pastes it into the client record. He's been using OneNote to accomplish this but he wants to move away from that. So I started my app and it creates the client records and the memo fields needed for the notes but I can't figure out what to do with the picture.

Now I know that the standard advice is "do not store the picture in a General field, store the path to the picture..." But I'm wondering if there is a device or third party app that I could use to link the picture to the client record. I even thought about him using a tablet with an electronic pen to store his scribblings and somehow tie that into my Foxpro table.

Just looking for ideas on how to incorporate images with Foxpro records elegantly.

Thanks.

Ken Watkins

-- This email has been checked for viruses by Avast antivirus software. www.avast.com

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

[excessive quoting removed by server]

In some environments, you have to store the document in a db because you are on a large network. That path may not correspond to others say viewing an XRay and getting an opinion from a team in Japan, Australia, etc.

You also have to have killer backups of that folder where they are kept as well.

Our rule is to convert all "visual" objects to pdf and insert that into the db. I have to store vendor publications on carcinogens with our raw materials, and have plants all over the world have access to that if a customer asks for it.

On Tue, Aug 16, 2022 at 9:33 AM Alan Bourke alanpbourke@fastmail.fm wrote:

IMO don't ever store binary objects in a relational database table. Store a relative path and filename from a root disk location.

-- Alan Bourke alanpbourke (at) fastmail (dot) fm

[excessive quoting removed by server]

Ken:

Welcome back, long time no see.

HackFox talks about general fields here: https://hackfox.github.io/section5/s5c1.html

As a general rule (pun intended), general fields were all part of the grand plan of Object Linking and Embedding, which is such a great idea they renamed it several times. It depends on a document type like ".JPG" being linked to a specific application, say Paintbrush or Microsoft Photo Editor, via the Registry. If you install a third party tool for image manipulation, it might overwrite the registry association, and if one user saves a file now associated with "Fred's Awesome Editor" the next user, still using Paintbrush, won't be able to use it. To help this process along, sometimes a major update or replacement with a new version can break (er, "reset to default") the associations. Or the Registry itself can become corrupt and the link is lost. So, OLE can be fragile.

Hope that helps!

On Tue, Aug 16, 2022 at 3:57 PM Ken Watkins kwat2235@gmail.com wrote:

Thanks everyone for the suggestions. I have a lot to think about. I like w00dy's idea if it doesn't bump into the 2gb limit Paul mentions, and even then I'm sure I can figure out a work-around.

And for the record I did create an app a few years ago where I ignored the common advice and used General fields for images. My company's admissions department had 26 separate forms that were filled out when a patient was admitted and they were doing it all with pen and paper. So, I scanned each form into a separate General field. Then I created 26 separate screens and used the images as the background for the screen (OLE) and superimposed text input fields over the image. And finally I created 26 separate reports (FRX) to print them out. This app has been on a network share and used by two endusers every day for over 5 years without a problem.

I'm not sure where the problem is regarding General fields and images. I've never experienced it.

Ken

------ Original Message ------ From: "Stephen Russell" srussell705@gmail.com To: "ProFox Email List" profox@leafe.com Sent: 8/16/2022 11:33:58 AM Subject: Re: Pictures in a table

...

In some environments, you have to store the document in a db because you are on a large network. That path may not correspond to others say viewing an XRay and getting an opinion from a team in Japan, Australia, etc.

You also have to have killer backups of that folder where they are kept as well.

Our rule is to convert all "visual" objects to pdf and insert that into the db. I have to store vendor publications on carcinogens with our raw materials, and have plants all over the world have access to that if a customer asks for it.

On Tue, Aug 16, 2022 at 9:33 AM Alan Bourke alanpbourke@fastmail.fm wrote:

...

IMO don't ever store binary objects in a relational database table. Store a relative path and filename from a root disk location.

-- Alan Bourke alanpbourke (at) fastmail (dot) fm

[excessive quoting removed by server]