Hi George,

>It seems to me that we have enough "hammers" to drive this "nail". Between creating our own routine to open the table, to private datasessions, to subclassable dataenvironments, what more do we need here?


Stability. There are many cases where its difficult to validate that a table is open, for instance, when you allow users to create a SELECT statement, when files are damaged, or when a table usually is open, but some rarely executed method closes it under some specifc circumstances. It shouldn't happen, but it does happen.

In a desktop application this causes a dialog to appear. While it's annyoing to the user and certainly causes support calls, it's not really a big deal. However, when there's no desktop available, the application hangs. For me there's not much of a difference if VFP crashed or hangs, the result is the same: I've to kill the task. In VFP, as a high level language, I don't think that any VFP command should crash or hang VFP. Neither calling API function that cause exceptions, nor passing an invalid pointer to SYS(2600) crashes VFP. A SELECT statement shouldn't, neither.

This is even more an issue, if you only provide the infrastructure, but the actual code is written by someone out of your control. Think of a web product like AFP that runs as a service and executes VFP code written by our customers. It's their code that is wrong, but our product that hangs.


--
Christof