New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CREATE OR ALTER VIEW and column type (domain) bug [CORE4844] #5140
Comments
Modified by: Attila Molnár (e_pluribus_unum)Attachment: HIBAS.ZIP [ 12767 ] |
Commented by: Sean Leyne (seanleyne) The attached zip includes only a file with an unknown .gdb3 extension, what does this file represent? |
Modified by: Sean Leyne (seanleyne)description: Hi! running the next command throws error EXECUTE BLOCK "This operation is not defined for system tables. Where RDB$245643 domain comes from? If you see the view source you see specific domain definition, but the view was created with this generated domain. SELECT * As I see there are two bugs : Thank you! => running the next command throws error EXECUTE BLOCK "This operation is not defined for system tables. Where RDB$245643 domain comes from? If you see the view source you see specific domain definition, but the view was created with this generated domain. SELECT * As I see there are two bugs : |
Commented by: Attila Molnár (e_pluribus_unum) It's a Firebird ODS11.2 database file. We use this extension not the standard fdb. |
Commented by: Attila Molnár (e_pluribus_unum) clarification |
Commented by: @asfernandes I reproduced it, but it would be good if you have a simpler test case, with only DDL comands (no execute statement) and no need of a database backup. |
Commented by: Attila Molnár (e_pluribus_unum) Cannot find any workaround for this problem, so from now this is BLOCKER for us. |
Modified by: Attila Molnár (e_pluribus_unum)priority: Major [ 3 ] => Blocker [ 1 ] |
Commented by: Attila Molnár (e_pluribus_unum) The deeper problem is : view depending on view with generated domain Simple test case : CREATE DOMAIN xint AS INTEGER CREATE VIEW view_level1 (id) CREATE VIEW view_level2(id) CREATE TABLE t(id xint) CREATE OR ALTER VIEW view_level1(id) last create or alter view is the problematic Cannot commit transaction: |
Commented by: Attila Molnár (e_pluribus_unum) Hi! What is the state of this bug? We need the fix. |
Commented by: @hvlad I looking into it but there is a lot of other things to do - so no quick solution, sorry. Probably another ugly workaround is to convert direct reference on view fields (from "caller" view) to the expressions, like: But it will make "caller" view not-updatable... |
Commented by: Omacht András (aomacht) Hi All! |
This is still an issue (Tested with FB30 and FB40) |
This is also an issue in case of union usage in view. In this case also RDB domains will be created automatically. Create a dependenc on this view make dependency on the RDB domain also. CREATE OR ALTER VIEW a AS CREATE VIEW b AS ALTER VIEW a AS "This operation is not defined for system tables. Now we have to make an other ugly workaround for this issue also. Thank You! |
Submitted by: Attila Molnár (e_pluribus_unum)
Attachments:
HIBAS.ZIP
Votes: 1
running the next command throws error
EXECUTE BLOCK
AS
BEGIN
rdb$set_context('USER_SESSION', 'VIEW_CREATE_USER', 'SYSDBA');
rdb$set_context('USER_SESSION', 'VIEW_CREATE_PASSWORD', 'masterkey');
EXECUTE PROCEDURE fk_minosites_view_create('*');
END
"This operation is not defined for system tables.
unsuccessful metadata update.
cannot delete.
DOMAIN RDB$245643.
there are 2 dependencies.
At procedure 'FK_MINOSITES_VIEW_CREATE' line: 95, col: 1
At procedure 'FK_MINOSITES_VIEW_CREATE' line: 95, col: 1."
Where RDB$245643 domain comes from? If you see the view source you see specific domain definition, but the view was created with this generated domain.
SELECT *
FROM rdb$relation_fields f
where trim(f.rdb$relation_name) LIKE 'FK_MINOSITES_'
As I see there are two bugs :
#1 : create/alter view not uses the specified domain, but generates a new one and uses that when null casted to domain.
#2 : alter view should not fail ICO domain change (domain drop)
The text was updated successfully, but these errors were encountered: