R
Rob Fitzpatrick
Guest
Thanks for the details responses everyone. It seems that my takeaway is that I should be able to load .dfs for additive schema changes without disconnecting users, but I might have to disconnect users to commit destructive schema changes. The above is interesting but I feel like there's more subtlety to this. Based on what is written above, any reference to schema objects in a .p should cause the client running (or even compiling?) that .p to acquire and hold a schema lock, for some period of time. find first customer. pause. While this code runs the schema lock is held. The same applies for a read of a meta-schema table, e.g. _file. Without the pause there is no schema lock evident, so it is obtained and released quickly. But when I look at a QA database with users running applications, almost all of them have a schema share lock. Can someone explain the duration that the locks are held? I note that the lock on the _db record doesn't show in _lock. Apart from screen-scraping promon R&D 1 19, is there another way to determine held schema locks?
Continue reading...
Continue reading...