>Brings me to the same point, however. If it is yesterday's technology then there must be a better way that offers the same features. I don't know of a better way; perhaps someone else knows of one and can assist me on this one. I want users to be able to interact w/ the information embedded (not having to open another application and switch windows and such) ESP, I want to be able to display a word file (preferably w/ a scroll bar) driven by a grid listing of reports on the file.
>
>I also want to be able to manipulate the data that is embedded. I don't see much alternative to embedding the data as there are 86228 reports currently in the DOS version of the file that takes up over 1.5 gig. This file is currently a text representation of a WP file and a PKZIP'd Word Perfect file. also a filename, a date and an internal Company file number. Many of these will have very similar if not the same name and even if we weren't still limited to the 8.3 (Novell 3.11, we are moving to NT as soon as this DOS->VFP port is complete) we still could not expect the user to have a different name for every single report. Especially since most of the reports are outsourced to typists and they name the file. We then load the disk into the system (usually 10 or so reports per disk).
>
>even if we standardized on filenames, it would be a mess and would be far from foolproof.
>
>The WORD manual implies that you CAN automate embedded data, but it doesn't really tell you how (other than activating the Word.Basic object via the application object, and then it makes some reference to making sure that the embedded object is first activated. Neither the Excel example nor the VB example give a clue as to what will work with VFP)
>
>
>Is there another approach that I am missing that will not kill our file system, strain our users or otherwise make the DOS version more feasible??? Perhaps there is a USENET group that might be more suited to this discussion? All ideas and pointers will be greatly appreciated, I am at an empass right now.

You really have a problem here because of the number of files. Would it be possible to divide them into subdirectories? The actual name is not a big deal. You can store that in a table and automatically go to it and ole automate it. If you have more than 5000 files in a directory or so, especially not on an NT machine, look up may be slow.

I think if you have that much data embedded you are taking a real risk here. FPT files are notoriously unstable, especially when filled with general field data. Any crash and your bound to the backup copy. In addition every time you change data in the embedded field the fpt file grows bigger until it is repacked which locks everyone out while it does this. For a table your size that could be hours.

I would still recommend getting your data out of the embedded fields and into separate files. Use a small table to control names and locations.
Then ole automation to pull up and do what you want to them.

If data is lost it is only on one file and that can be restored independent from all other files and everyone else working.