I see the alter view interface is unavailable for views under team coding control when not checked out. That’s good, but I can open the view script in the editor and freely edit and compile the code there, and I’m not prompted to check out the code as I am for packages and triggers. That’s not good.
I don’t know if this behavior exists for other types as the three I mentioned are the only types we have in team coding.
We are able to reproduce this issue in-house. Toad does catch it if you press F5 to execute it as a script, but it doesn’t catch it when you press F9. We’ve created a bug internally and will attempt to correct it soon.
I see the alter view interface is unavailable for views under team coding control when not checked out. That’s good, but I can open the view script in the editor and freely edit and compile the code there, and I’m not prompted to check out the code as I am for packages and triggers. That’s not good.
I don’t know if this behavior exists for other types as the three I mentioned are the only types we have in team coding.
I see this has been corrected in beta, but there is a related follow-on problem. In testing with a co-worker, if I check a view out to edit, she is also able to edit the view. She should get a message saying it is checked out and can’t be changed.
I cannot replicate this last issue. When I try to check out a view as User2, I see the object as being locked (see icon on left) and in the Schema Browser there is a message saying that it must be checked-out to edit.
Can you provide any other information on this? When you have the view check-out and your co-worker goes in to the TC Manager - does she see the object as locked?
btw…the only way I can think of where she would be able to edit the view when you have it checked out, would be if she was logging in as the same Oracle user as you are.
Yes, she sees it as locked exactly as you show it. If I see correctly, it looks like your arrow is pointing to the Alter View icon. That is not the problem. As I said in my first message above, that works fine. The problem is when the code is in the editor, that is where it can be compiled (F9).
We do all use the same Oracle user, but of the three types we have under TC control: views, triggers, and packages, views are the only one that doesn’t lock it. Triggers and packages both put up a message that the code is locked by someone else.
I also responded to support in email with the steps to take to replicate this. If you don’t have access to that, I can repost it here if you need it.
I thought your original issue had been fixed in the beta back on Nov 16th – at least, that’s what I gathered from your post on Nov 19th. I think Dennis is trying to address the secondary issue you raised in that post.
You mentioned that you all use the same Oracle user. Since that’s the case, Team Coding would allow the second user to change the view since it believes the same person has checked the database object out.
Yes, it was fixed. After verifying that, I found this problem that is closely related, which is why I tacked it on to the same thread.
As for being the same user, I might say “Oh, OK then”, but both triggers and packages lock out the 2nd user, so I would think that views should be able to also.
Roddy - please send me the steps offline - Dennis.Paulus@quest.com. I think we’re missing something here, because what you are describing is not what I see and is not what I would expect. If you are all logging in as the same exact Oracle user, then the second user would not see a lock on an object that is checked out - they would see the checked-out image. Also, if you are using the same user, then you would have access to modify all the objects, not just the views, because that is the user that checked the object out. It’s only when you login as a different user that you wouldn’t be able to modify anything, and see the items as locked (as in my print screen). If you send me the information, we’ll try to figure this out. Thanks.