>How would my system know its a pdf (suffix is pdf), but can't tell on the client pc (file is
>also a .pdf)?

This pretty much sums up the stuff that's wrong with general fields. They rely on the existence of a COM object in charge of opening the content. In case of linked content (I forgot that existed too) it stores the path to the file instead of the file itself but again doesn't use ShellExecute() but COM again. The sole purpose of that exercise is that the COM object will run inside the window of your app, and its menu will merge with your system menu. That's how it was supposed to work. However:

- it always stores a preview image along with the content (always a completely uncompressed .bmp, so storing a 20k gif may still make your general field a megabyte in size)

- the purpose of the preview is that you see something while the content loads and the COM object is instantiated

- the other purpose of the preview is that you still see something even when there is no COM server registered on the current machine or the link is broken (i.e. file can't be found at the same (relative?) location. Which is probably what happened to you (the "can't move up, down, or anything" is exactly the behavior, you're looking at the screenshot of the sheet).

The most common hit on the fan is the following scenario:
- all workstations have a COM handler for .jpg
- some evaluation software, or a new version of something, is installed and it takes up the association to .jpg file type
- that software doesn't do COM, the workstations where it is installed report "no class registered" (now why would a COM server be called class is beyond me, who knows what the guys were on 20 years ago)
- that software's evaluation period expires and it gets uninstalled. No COM server takes over the association to .jpg files. Same result as in the previous paragraph.
- you add more file types, and discover that a certain percentage of workstations doesn't have installed software for those types.
- you didn't write a routine to Pack Memo regularly on that table and the memo bloat ruins the performance.
- you try to include these things in a report and discover that they don't really grow as to their actual size... you can't print .rtf or .doc or .xls from a table into a .frx report. You actully can, but you get only the preview printed.

In my 19 years of experience with VFP I have seen general fields used only once (and I worked with nine different teams so far, using 3 or 4 frameworks in three countries). And that wasn't in a table, it was in a cursor built on the fly, and it somehow got into a report (don't remember what and how, it somehow worked... about 80% of the time). And that was in the last century.

The first answer you got in the last thread was correct. What were you doing wrong? You were using general fields.

If there was a way to fix them, it would have been done some time in the last 20 years, but the general fields haven't changed since VFP3. That should be symptom enough.