Bug Hunting Session
Bug 117527 - Firebird: EDIT: Table wizard does not set field properties "AutoValue" to "Yes" for user selected primary key field.
Summary: Firebird: EDIT: Table wizard does not set field properties "AutoValue" to "Ye...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 122300 (view as bug list)
Depends on:
Blocks: Database-Firebird-Default Database-Wizard
  Show dependency treegraph
 
Reported: 2018-05-09 20:45 UTC by Roman Kuznetsov
Modified: 2018-12-27 17:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot with error (31.71 KB, image/png)
2018-05-09 20:47 UTC, Roman Kuznetsov
Details
firebird test file (3.17 KB, application/vnd.oasis.opendocument.database)
2018-05-09 22:01 UTC, Drew Jensen
Details
screen shots (60.94 KB, image/jpeg)
2018-05-09 22:02 UTC, Drew Jensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2018-05-09 20:45:59 UTC
Description:
In Firebird BD don't changes field properties "AutoValue" to "Yes" for auto created field ID

Steps to Reproduce:
1. Create new Firebird BD
2. Create new table uses "Create table in Design view"
3. Create one or more field
4. Save your table
5. Base asks you "Should a primary key be created now?", Push button "Yes" 
6. In table will add field ID with type Integer, but its field properties AutoValue will equal "No" (see bug 108057)
7. Save table else one (do not close!)
8. Try change ID's field properties "AutoValue" to "Yes". You look warning dialogue with "The column "ID" could not be changed. Should the column instead be deleted and the new format appended?", push button "Yes"
9. You look new dialogue with error "Error while saving the table design"
firebird_sdbc error:
*unsuccessful metadata update
*ALTER TABLE 34 failed
*SQL error code = -607
*Invalid command
*Specified domain or source column SQL_LONG does not exist
caused by
'ALTER TABLE "34" ADD "ID" SQL_LONG NOT NULL' (see screenshot)
10. If you push button "No", then field ID will be remove from table.

If i use master for create a table, then i can't change field properties "AutoValue" to "Yes" in table design view

Actual Results:  
i can't create unique field with auto increment for my table in data base

Expected Results:
i can create unique field with auto increment for my table in data base


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Comment 1 Roman Kuznetsov 2018-05-09 20:47:47 UTC
Created attachment 142000 [details]
Screenshot with error
Comment 2 Drew Jensen 2018-05-09 21:59:51 UTC
So there are really two separate issues here.

First is that the create table wizard does create an auto update primary key fied WHEN the user selects a field defined by the user, either by selecting from a list of predefined fields or by entering a custom field from the start.

I've added another screen shoot for what I mean.

Also added a test database with 3 tables. (4 but one is for the other issue)
tbl_frm_designer - No use of wizard and auto inc, PK, work fine.
tbl_wzrd_add_ID - Created one field in the wizard dlg and let the wizard function add the ID field - that also worked and set auto inc true here.
tbl_wzrd_useFild - create the entry for my ID field on the wizard page 'Set types and formats' and selected that field on the next page 'Set primary key'; here the auto inc setting is not made. 

The problem with changing the PK field in an existing table is a separate issue IMO.

Changing summary to the wizard failure to set auto inc scenario.
Comment 3 Drew Jensen 2018-05-09 22:01:02 UTC
Created attachment 142001 [details]
firebird test file

example tables from different creation scenarios
Comment 4 Drew Jensen 2018-05-09 22:02:14 UTC
Created attachment 142002 [details]
screen shots

wizard settings used for problematic scenario
Comment 5 Howard Johnson 2018-05-10 13:47:17 UTC
Quite related is bug 108057

I think the point is that users are frustrated with it being messy and troublesome to create Base tables.  Especially when they are brand new to Base!

I first reported this issue a long time ago, but it still isn't fixed.  I frankly no longer care if it's ever fixed.  I now use HeidiSQL to create my tables, and only have to deal with Base's foolish table creation defaults when I go to submit a new bug report for some other bug.

MS Access (dare I mention the model that Base was created from, and the 3 versions that I once owned) made it super easy to create a table and get started.  They got that right.

When a new user comes to Base one of two things will happen:  1) they will either get frustrated and leave, or 2) they will spend countless hours and barely get anything done.

It doesn't have to be that way.  I don't get what all of the foot dragging is on this issue. 

It's really very simple.  When a table is created it just needs to work as quickly as possible.  This means 

1) the new table needs a key (note, that in Access it didn't even require a key), and 

2) that new primary key needs to allow the user to start entering data immediately, and  

3) this means the key needs to auto-incrument, for how else is it to work?

I suppose in the more general case 'autovalue' is true, but this is confusing to a new user, so I think it should say simply 'auto-incrument' or 'autovalue (auto-incrument)' (to clarify that the type of autovalue is to auto-incrument.

The choice is this:  We can either make it easy for new users or we can make it hard.  I think it's extremely hard to learn to use Base already, so I'm for making it easier for new users, as much as we can.
Comment 6 Roman Kuznetsov 2018-05-10 14:41:08 UTC
Why did you change heading of this bug? Not only master does not change primary key's value properties in table and mode "Design view" have same problem
Comment 7 Drew Jensen 2018-12-27 17:37:58 UTC
*** Bug 122300 has been marked as a duplicate of this bug. ***