I'm not sure I quite understand the scenario you've laid out. Could you explain it differently and throw in a bit of code to help clear it up?

~~Bonnie



>Recently, there was a thread about a locking mechanism when updating the data dictionary. The point was to make sure that only one instance of the application pool was loading the data dictionary, while the other instances were waiting in lock mode for the process to complete. Then, the data dictionary was made available to all by the use of the Shared object.
>
>A situation I have, which happens very rarely, is when this happens when another hit is in progress. So, as the other hit is in progress, any change that could happen in the locking section of the hit updating the data dictionary, might have an effect on one of the SQL requests in progress.
>
>This makes me thing that the Data class should verify for that. Otherwise, a method in it might try to use a reference to one of the entry in the oApp.oTables collection and, for a fraction of second, it could not be there. This situation could happen when I update a record in the Table table. Thus, a reload of that specific entry in oApp.oTables("MyTable") will be in effect. As I need to reload it, I remove it from the collection and add it back. It is during that timeframe I could have a siutation.
>
>So, the way I see it would be to adjust the Data class to verify for something and proceed when ready. This, of course, happens very rarely and when it will happen it will only last for a fraction of a second.
>
>Any comment on such an approach?