Created attachment 133516 [details] Screen shot (Preface: Now that I have Base doing some of the hard things I had hoped it would do, I plan to submit a number of simple bug/improvement reports and this is the first. My hope is to take some of the rough edges off for new Base users. There are some little things that could easily be improved I think. I'm going to start with the most basic things that could be improved, that unnecessarily make Base hard to use for the new user.) 1) When creating a new database, and selecting either HSQLDB 1.8 or FireBird, and then when a new table is created in design mode, and an ID field is created as the first field, and set to Integer, and then set as the Primary Key, I think the AutoValue should be automatically set to Yes. Steps to create this: Open LibreOffice and from the menu select: File New Database Create Table In Design View... Set Field Name to "ID" | Set Field Type to "Integer" Right click on green arrow left of ID and select "Primary Key" Result below is AutoValue remains set to "No". I think AutoValue should be Yes. While an experienced person might want to insert their own primary key values, the new user almost surely will want to just have the ID come up working. But even as an experienced user with 40 years of database experience, I find that having to set this to Yes, each and every time I create a simple database for testing purposes is just frustrating and one more unnecessarily click. We've been building computers to help do our work for us. I think this is something the software can do to save a step almost all of the time. It is rare indeed that I have a table that I don't use an AutoValue ID on these days. In the over 100 tables I now use with base I can only think of 2 or 3 that I use where the primary key is not AutoValue. So yes, it's possible to have a valid database with AutoValue off. The one I can think of right now is a small table I have of months, where the ID is the month number. But in all of the other 100+ tables I have the ID is set to AutoValue=Yes. Thanks for your consideration of this.
@Howard : the table creation wizard does this for you with hsqldb, if you don't assign a primary key when setting up your table, then it will ask whether you want to create one or use an existing field. In either case, there is an option (tick box) to set the primary key to autoincrement. Unfortunately, this option isn't proposed by default on table save when you create your table via the table design mode - to the extent that this mode is intended for people who are supposed to know what they are doing, I suppose it is understandable that the user has to make a positive decision to deliberately assign an autoincrement statement in the table design UI, rather than being asked for one, as the counter argument could be made that were I database designer having used the "manual mode", I would find it annoying to be asked each time I defined an ID primary key whether or not I wanted to assign the autoincrement function to that key.
Having said that, I agree with you that I use AUTOINC far more often on an INT column than just specifying an INT column that I have to fill manually with unique values. So, let's add this as an RFE, and see if there are any takers.
Actually, there is even more important use case for this proposal. Comment 0 deals with a case when user creates the ID manually; the program should guess the "AutoValue" setting based on user's provided data. But consider the following scenario: 1. User creates a new table in Design View mode. 2. User *does not* create a key field manually. 3. On "Save", Base detects the absence of a key field, and emits the dialog: > No primary key > > A unique index or primary key is required for data record > identification in this database. > You can only enter data into this table when one of these two > structural conditions has been met. > > Should a primary key be created now? Upon selecting "Yes", a new key field named "ID" is created, of type INTEGER. In this case, the AutoValue isn't set by default, either! But that is clearly wrong, even if one could see the original use case as something arguable. When the key field was created automatically by program, then failing setting AutoValue is absolutely against user's expectations, and just trying to use resulting table as is, without further adjusting the key field, will result in error because of key field not set.
At actual, it is not possible to set an IDxyz-Field to primary-key and Auto-increment at once while building a new table. The setting "auto" will get lost on closing the table. When reopening for to change to auto, field-order changes (== drop+append), which is annoying.
Related, obsolete (its effects were mostly undone later; the comments stay, though): 24940e2c3717ad7b07d43db4f08cf7e09cfcc22f
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c07548447a564b2d142cc439a124b76e6a71dfbd Related: tdf#108057 Use autoincrement for automatically added primary key It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/c94c724d0ba9da6f6bacd6e9c6025ad0759d9658 Related: tdf#108057 Use autoincrement for automatically added primary key It will be available in 24.2.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I am not sure that this is resolved. The original request was to set autovalue when user defines key manually. What I did was setting autovalue in keys created *automatically*. That's why I used "Related:" prefix in the commit message. Howard: please feel free to set to NEW, if you think that this needs further work.