Peter,
>I couldn't agree more on what you say above. But let's say that the way we do it originates from the principle of the really self contained functions ("objects" ...) as we have them from 1987.
I'd argue here that your object is not self contained. Your object is dependent on an external entity (the ON ERROR handler) to do some of its work.
In this case I'd say it's better to have all this code encapsulated in a cTableHandler class. Its Error() method can take on the onerous task of opening tables that had not been opened before USE. Now this error handler only has to deal with one or two little possible errors that can happen in the context of a table. The Error() method can probably be coded in 20 lines. If it encounters an error it can't recover from then it can pass the error off to this.parent.Error() to follow a containership delegation of errors, or pass the error off to something like oApp.Error(). By doing this you don't have to have a ON ERROR handler that has hundreds of lines and tens of CASE statements.
>Think of it as "header-info" in the function (it's the block of documentation btw), listing all the tables that
could be touched somewhere down its lines ... Combine this with the sole fact that back then (FoxBase+) we were all able to open the huge amount of 10 tables at the time. Some late this became the far more huge amount of 25 ... So what to do when you really needed over 50 ? (right now one object may use 80 tables in the one transaction). So see it as the FIFO principle, the one table needed implicitly closing the other.
So this list of needed tables can be an object property. The Error() method can see if the table in error is in the list it can open it. If it isn't in the list then you could throw an error that should happen in design time testing to tell your developers that they've not properly setup the object.
>So yes, our Open routine is some 5,000 lines already to control all this.
>When back then the limit was 10 (25), today we limited it ourselves to 80, implying some 220 filehandles open at the time, and allowing for some more for other apps. This limit of 80 is still too few, and the FIFO is still doing it's (very good) work (the app consists of over 1,000 network tables).
>Also please note that there is some smartness in the opening of groups of tables, knowing that opening a table is the far-most slow process of all of the Fox, and hence this should be avoided whenever possibible.
Sounds like you need a sophisticated TableManager class to keep up with this.
>Again, I couldn't agree more that the errorhandler shouldn't be used for explicit code. OTOH, it's (IMO) just needed anyway in order ro deal with locking issues (and some more). Rememer, a record being locked is not an error, and just "functionality" to be dealt with properly. And you know, the code behind that could error too. But I agree, this is different.
So the cTableHandler class Error() method can deal with locks errors. But once again you've helped to encapsulate all the highly related code to a single class. It's not spread all over and some of it in the global ON ERROR code block.
>But in case you are interested : in order to capture the exclusive use of tables properly (or it is used exclusively, or you want to use exclusively), there is this oter sneaky means involved : opening the table low level in order to find out this status in advance. It's just another level of error trapping ... Squeeze squeeze squeeze. But at the same time, this is the fun of it all.
There is still a finite probability that another user will open the table between the execution of the fclose() and the USE statement.
>Sidenote :
>I think there could be some other (error level) possibility in making a class for the open routine and use the Error-method. I never tried it, but maybe I should do that now.
I really think you ought to look in this direction, I think you'll end up with a better system because of it.
