Jack,

Yeah, it's kind of a hack either way, but the concensus seems to be the job gets done better by just storing paths. Best of luck with it.

>Ken,
>
>These are scanned legal documents and I can split them into separate directories. It just seemed the database approach would be cleaner, but it does seem to have its own problems.
>
>Jack
>
>>Jack,
>>
>>Glad to hear the subf is working out.
>>
>>Hmmm. 28,000 is a lot of files for a directory. If you can split them up without the user being aware of it, it would speed up access.
>>
>>I would figure that when an image is added to the table now, the user has to say something about where it is coming from, be it a floppy, a zip, etc. The thing to do is intercept this information and then, instead of loading into the memo field, copy it over into your directory. Everything else about it would remain the same: user lookups, printing, etc. You would normally not show the user the directory or file name, but it should be available to admins.
>>
>>>Ken,
>>>
>>>Good to hear from you. I am still using the Promatrix subframe work. It has worked great for me. Thanks again.
>>>
>>>They have 28,000 images so far. Do I want to leave them in a directory and use directory access to find them? I certainly can label them with document # and page #. I though it would be faster/safer if they were stuffed in to a memo file.
>>>
>>>Jack
>>>
>>>
>>>>Jack,
>>>>
>>>>How goes it?
>>>>
>>>>To follow up on Sylvain's suggestion, a standard approach is store only the paths to the images, and keep the images out on disk, and never in your table in any form.
>>>>
>>>>>I know DBF files cannot exceed 2g, memo files can't either, can they? I have a memo files that contains images and it is getting close. Does anyone have any ideas on how to solve this besides splitting into multiple data bases? Thanks.
>>>>>
>>>>>Jack