Created attachment 188442 [details] Base file with different results for view if executed or opended for Editing in SQL and run in editor Open the attached database file. Execute "viw_person". You could see 3 fields. Close the view. Right mouse click on "viw_person" → Edit in SQL view Run query. You could see 4 fields. One field "Street" is visible. Table "tbl_person" has been created with 3 fields. Query and view have been created. Then I have added "Street" to "tbl_person". New added fields won't be shown in the view. Note: Views with internal HSQLDB will change the code while creating a view from a query with SELECT * FROM "tbl_person" to SELECT "tbl_Person"."ID", "tbl_Person"."Forename", "tbl_Person"."Surname" FROM "tbl_Person" So you could see: New added fields to table "tbl_Person" had to be added to the view also. But for Firebird the views will be shown by a code, which doesn't need this separate fields. Bug appears since views could be opened for editing, might be first version of LO 7.3. Detected this bug in LO 7.6.0.1 and could reproduce it with LO 7.3.6.2 also on OpenSUSE 15.4 64bit rpm Linux.
I don't see any erroneous behavior. 1. Execute view viw_person --> Show 3 fields --> As you stated that is correct because the view was defined in that way (when the table had three fields). 2. Show the table --> has 4 field --> correct, the fourth field was added after the view definition. 3. Edit in SQLview. In this case you are doing a *new definition* of the view as the word *edit* suggest. If your *new* definition is "select *" you are selecting all the *current* fields in the table, that is, four fields, and you can see this if you execute the query. You are selecting *now* all the field that are *now* in the database, and fortunately you receive that, and not the fields that were in the table in any other moment 4. If you don't save the edit, the view will continue having 3 fields. 5. If you save the new definition, you will obtain all the fields (four) selected in the new definition
(In reply to Robert Großkopf from comment #0) > Note: Views with internal HSQLDB will change the code while creating a view > from a query with > SELECT * FROM "tbl_person" > to > SELECT "tbl_Person"."ID", "tbl_Person"."Forename", "tbl_Person"."Surname" > FROM "tbl_Person" Who says that my definition should be changed field by field? If I want a field by field definition I can do it by myself, but I may want another approach, and why does the code have to change my definition? Maybe one of the reasons why Firebird is not moving forward is because we want it to do the same thing as HSQLDB *and in the same way*. I don't know if Firebird has more or less capabilities than HSQLDB, but what is surely wrong is to force it to do things the same way as another database, even when the results obtained in its own way are correct.
(In reply to jcsanz from comment #1)> > 3. Edit in SQLview. In this case you are doing a *new definition* of the > view as the word *edit* suggest. No, I don't do anything *new*. I have opened the code for the view. I didn't change anything. So I could close the view, which is opened in the editor, and aren't remembered to save anything. So Firebird does execute something other than SELECT * FROM "tbl_person" when executing the view. Seems also Firebird had saved a view, which contains all fields when created first, not '*' as sign for all fields. Don't know where to find the view definition in Firebird, but execute SELECT * FROM RDB$DEPENDENCIES will show: There are 3 fields bounded with FIELD_NAME. When executing the view I am editing and there are more fields the button for saving should be activated and a warning should appear - not closing without warning.
(In reply to Robert Großkopf from comment #3) > Don't know where to find the view definition in Firebird, but execute... The definitions and attributes of all tables and views are stored in RDB$RELATIONS, so you can obtain by SELECT * FROM RDB$RELATIONS, may be you want to add WHERE RDB$RELATION_NAME = 'viw_person'
(In reply to jcsanz from comment #4) > (In reply to Robert Großkopf from comment #3) > > > Don't know where to find the view definition in Firebird, but execute... > > The definitions and attributes of all tables and views are stored in > RDB$RELATIONS, so you can obtain by SELECT * FROM RDB$RELATIONS, may be you > want to add WHERE RDB$RELATION_NAME = 'viw_person' Thanks! And there is saved the same as it is opened by the editor. The editor executes SELECT * FROM "tbl_person" but Firebird doesn't execute this. It will only execute a query for the fields shown in SELECT * FROM RDB$DEPENDENCIES It is nice Firebird will save the view without changing the code to all existing field names as other databases would do (internal HSQLDB, MariaDB …), but we need the information for the user: Please safe again, not all fields will be shown.
(In reply to Robert Großkopf from comment #5) > It is nice Firebird will save the view without changing the code to all > existing field names as other databases would do (internal HSQLDB, MariaDB > …), but we need the information for the user: Please safe again, not all > fields will be shown. I'll better advise the users to create the view field by field instead of * "If you want fish and seafood ask for fish and seafood, if you ask for everything from the sea you will be covered by garbage" :)
(In reply to jcsanz from comment #6) > (In reply to Robert Großkopf from comment #5) > > > It is nice Firebird will save the view without changing the code to all > > existing field names as other databases would do (internal HSQLDB, MariaDB > > …), but we need the information for the user: Please safe again, not all > > fields will be shown. > > I'll better advise the users to create the view field by field instead of * > OK, I will write it down in the German Base Handbuch. But there is no possibility to advice the user to create a view field by field inside from Base. And users, who know they had to save the views a second time when using '*' in a view and changing the datasource for this view, will miss this "feature". I'm using the '*' very often for queries, which will be filtered by a separate filter-table. So I could use this queries in forms and I will get all the content which is part of the table.
since it seems that the behavior is not incorrect, but different than expected, should we classify the bug as NOTABUG?
(In reply to jcsanz from comment #8) > since it seems that the behavior is not incorrect, but different than > expected, should we classify the bug as NOTABUG? This would implement: Nothing should happen here. Let users find the workaround. It's a problem of the UI. The original buggy behavior comes from Firebird, which says: I will execute SELECT * FROM "tbl_person" but won't execute it with the current fields of the table. But this we couldn't solve. UI needs an enhancement: If SQL-code with '*' has been opened for editing a view the button for saving data should be activated and if I want to close the editor a warning should appear like it appears always for changed (and not saved) content.