>Ahh, maybe I should rethink my approach- The business requirement is that first of all, these are control documents. Not just anyone can access them. Even among those who can, changes are NOT allowed - they can't even print them. They can look at them on screen - that's it. Currently I use network security, but that does not disallow the choice of opening a file with read only access to a drive, changing it and saving it to another location on the network where the user has full access. We can't have that with these kinds of documents. They are proprietary (design instruments) and we also don't want to run the risk of someone "selling" them to a competitor. We also can't have someone making unauthorized changes. So I figured I had the most control over them from within VFP if I treated tham as embedded objects. If one is printed I need to log date time and who printed it. If it's changed I need to log that as well. If I link them (by way of general field or just a text field pointer to
their directory/name) that still means someone could open from outside of VFP and circumvent required security. The binary data in a memo might be OK, but I've had far too many memo file corruptions to feel that's a safe bet. Any suggestions?

If you have reall security restrictions, I'd move the data into a database other than VFP that has stronger built-in security capabilities; any VFP table that can be read can be copied to another environment and removed from the system in read/write capable fashion. I'd look at products like SQL Server or Oracle; you could convert your application to use parameterized Remote Views so that your VFP code could be used with the databases with minimal modification, although I'm not sure how general fields are mapped through Remote Views. There are significant advantages, including the ability to log all sorts of transactions at the backend, and wholesale theft of the database is much more difficult.

Again, I don't use OLEBound controls in my own applications, because General fields take up more space than the files that might be embedded and are subject to tremendous bloat. A General field is nothing more than a special case of a memo field, so the same type of data corruption that you're afraid of with memo fields is at least as likely to happen with general fields, and the ability to recover from damage is actually greater than with a normal memo field. Finally, with OLEBound controls, your access to the automation environment is far more limited.