System domains blocking dropping of objects [CORE2442] #2856
Comments
Modified by: Hannes Lowette (hanneslowette)description: Here's the story: During rapid development, I tried to generate a bunch of stored procedures based on RDB$RELATION_FIELD using the field names and the domains. ...until I hit the only computed field in our database. This field has RDB$1 as its domain. I successfully created a stored procedure parameter with 'parameter type of RDB$1' But now I have the following problem: I cannot drop the stored procedure any more, nor alter it. As the engine gives me: This operation is not defined for system tables. Changes will be rolled back... Now I know I should not be using a system generated domain to create stored procedure params. Because I know this was not good when I saw it, I wanted to fix it. But it seems impossible now. => Here's the story: During rapid development, I tried to generate a bunch of stored procedures based on RDB$RELATION_FIELD using the field names and the domains. ...until I hit the only computed field in our database. This field has RDB$1 as its domain. I successfully created a stored procedure parameter with 'parameter type of RDB$1' But now I have the following problem: I cannot drop the stored procedure any more, nor alter it. As the engine gives me: This operation is not defined for system tables. Changes will be rolled back... Now I know I should not be using a system generated domain to create stored procedure params. Because I know this was not good when I saw it, I wanted to fix it. But it seems impossible now. Obviously, the other dependency is the original table where the computed field resides. |
|
Commented by: Sean Leyne (seanleyne) This doesn't seem to be a real engine problem but your own poor implementation... Just because the domains already existed doesn't mean that you should not have defined your own (i.e. you should not have used the 'system domains'). |
|
Commented by: Hannes Lowette (hanneslowette) Sean, I think we will all agree that I should not do what I did. And this is also the exact reason why I tried to throw away the STP to make a decent one. When I wrote the generator scrip I just didn't think of the computed field and assumed all our database fields had correct domains. My point is just that I was not able to fix it without rescripting my database, because the engine did not allow any changes to the STP, because it would try to throw away the domain, which it could not because it was still linked to the table. In my opinion, the engine should either not allow the re-use of a system-generated domain, which would have thrown an error upon my STP creation, or check dependancies before trying to delete it, so when it is in fact re-used, people can still alter their objects. I guess the choice for the method depends on if you want to allow people to re-use system-generated domains. I just feel that the current setup is not consistent: In the creation of my STP I am allowed to use it, but then you're basically screwed if you want to change anything because the engine acts on the assumption that system generated domains are never re-used. P.S. (I really want this off my chest) Comments like Sean's above are not constructive. I said myself (in my original post) that this is not a good way of doing things. I KNOW THIS. I just wanted to point out the inconsistency of the implementation and report it to you guys. I took the time to do this and contribute to a better product. If you treat people who take the effort to report things like this ... they won't do it next time, so bugs will stay unreported. If you decide not to fix this, because it's not a priority or you don't agree with me that it's a bug, that is fully OK. Just tell me that you won't be fixing this for that reason. But just bashing the people who take the time and effort to contribute gets us nowhere. |
|
Commented by: @asfernandes Did you ever see how Linus Torvalds treat "his guys"? :-) FWIW, I agree that the engine should not allow to use the system generated domains. |
Submitted by: Hannes Lowette (hanneslowette)
Here's the story:
During rapid development, I tried to generate a bunch of stored procedures based on RDB$RELATION_FIELD using the field names and the domains.
This all worked wonders ...
...until I hit the only computed field in our database. This field has RDB$1 as its domain.
I successfully created a stored procedure parameter with 'parameter type of RDB$1'
But now I have the following problem:
I cannot drop the stored procedure any more, nor alter it. As the engine gives me:
This operation is not defined for system tables.
Unsuccessful metadata update.
cannot delete.
DOMAIN RDB$1.
there are 1 dependencies.
Changes will be rolled back...
Now I know I should not be using a system generated domain to create stored procedure params. Because I know this was not good when I saw it, I wanted to fix it. But it seems impossible now.
Obviously, the other dependency is the original table where the computed field resides.
The text was updated successfully, but these errors were encountered: