Bug 117527 - Firebird: EDIT: Table creating in Design mode does not allow to change field properties "AutoValue" to "Yes" for suggested automatic default primary key field.
Summary: Firebird: EDIT: Table creating in Design mode does not allow to change field ...
Status: RESOLVED DUPLICATE of bug 112491
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: 2022-02-04 21:15 UTC (History)
7 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. ***
Comment 8 Julien Nabet 2020-11-01 19:46:46 UTC
It seems that, like tdf#112491, the pb is it's not possible to enable Autovalue once the table has been created, so shouldn't it be a dup of tdf#112491?
Comment 9 Robert Großkopf 2022-02-04 14:43:48 UTC
Could be this bug has been gone with integration of Firebird 3.

I started Table Wizard.
Step 1: Business → Tasks → All fields selected
Step 2: Changed nothing
Step 3: Create primary key → Automatically add primary key → Auto Value (Yes)
Step 4: Changed nothing
Pressed Finish and could start to input data. 

I will get a AutoValue field called "ID" here.

All tested with LO 7.3.0.3 on OpenSUSE 15.3 64bit rpm Linux.

Could anybody else confirm the buggy behavior of the wizard for tables has been gone? So we should close this one as WORKSFORME.
Comment 10 Roman Kuznetsov 2022-02-04 16:33:09 UTC
(In reply to Robert Großkopf from comment #9)
> Could be this bug has been gone with integration of Firebird 3.
> 
> I started Table Wizard.
> Step 1: Business → Tasks → All fields selected
> Step 2: Changed nothing
> Step 3: Create primary key → Automatically add primary key → Auto Value (Yes)
> Step 4: Changed nothing
> Pressed Finish and could start to input data. 
> 
> I will get a AutoValue field called "ID" here.
> 
> All tested with LO 7.3.0.3 on OpenSUSE 15.3 64bit rpm Linux.
> 
> Could anybody else confirm the buggy behavior of the wizard for tables has
> been gone? So we should close this one as WORKSFORME.

The origianal description said about problem in Table creating Design mode.

It's stll repro for me and I see:

firebird_sdbc error:
*Dynamic SQL Error
*SQL error code = -104
*Token unknown - line 1, column 48
*GENERATED
caused by
'isc_dsql_prepare'

in 

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: d140817428cdbb519efa496f578bf6c054c94361
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: ru-RU (ru_RU); UI: ru-RU
Calc: CL

Just someone smart did change the Summary to wrong
Comment 11 Alex Thurgood 2022-02-04 18:09:10 UTC
(In reply to Roman Kuznetsov from comment #10)


> The origianal description said about problem in Table creating Design mode.
> 
> It's stll repro for me and I see:
> 

Me too, reproduced with 

Version: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 8; OS: Mac OS X 12.2; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

I am changing the title to reflect the original poster's bug report.
Comment 12 Robert Großkopf 2022-02-04 20:31:10 UTC
(In reply to Roman Kuznetsov from comment #10)
> 
> The origianal description said about problem in Table creating Design mode.
> 
> It's stll repro for me and I see:
> 
> firebird_sdbc error:
> *Dynamic SQL Error
> *SQL error code = -104
> *Token unknown - line 1, column 48
> *GENERATED
> caused by
> 'isc_dsql_prepare'

But this will be a duplicate of
https://bugs.documentfoundation.org/show_bug.cgi?id=112491
Comment 13 Roman Kuznetsov 2022-02-04 21:15:05 UTC
(In reply to Robert Großkopf from comment #12)

> But this will be a duplicate of
> https://bugs.documentfoundation.org/show_bug.cgi?id=112491

a nice catch!

*** This bug has been marked as a duplicate of bug 112491 ***