Bug 31399 - LibreOffice Base: autonumber did not work on field
Summary: LibreOffice Base: autonumber did not work on field
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected)
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2010-11-04 17:11 UTC by collura
Modified: 2011-12-23 15:38 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

test file for broken autonumber when add record in table view (3.92 KB, application/vnd.oasis.opendocument.database)
2010-11-12 16:38 UTC, collura

Note You need to log in before you can comment on or make changes to this bug.
Description collura 2010-11-04 17:11:18 UTC
test of update query:


LibreOffice 3.3.0 

OOO330m9 (Build:1)


test file done on mswindows-os

make a table: 

Table1.key, integer, autonumber, primary key

Table1.fld-flag, boolean

Table1.fld-desc, string

Table1.fld-int, integer

populate the table:

(auto number didnt seem to work in key when enter in table view so entered
number manually)

key,    fld-flag,     fld-desc,     fld-int

1,      No,           one,            1 

2,      YES,          two,            2 

3,      YES,          three,          3

4,      No,           four,           4
Comment 1 Petr Mladek 2010-11-12 11:57:25 UTC
collura, could you please create a test document, so we need not create it from scratch? It would help to fix it faster.
Comment 2 Drew Jensen 2010-11-12 12:22:27 UTC
using XP SP3, LibO 3.3 beta 2 and the embedded HSQLdb engine - no problems.
XP SP3, Libo 3.3 beta 2, MySQL Connector 1.0.1
- confirmed the AUTOINCREMENT is not functioning IF the table is created with the LibO GUI, if you watch closely the autoincrement control on the table dialog is actually changing from YES to NO when you save the table structure.
Comment 3 collura 2010-11-12 16:38:53 UTC
Created attachment 40246 [details]
test file for broken autonumber when add record in table view

this database file was made in LibOff-3-2-99-2 in mswin-os.

i just read the observation about a gremlin resetting autonumber->'no' 
when file gets saved [ nice catch :') ].  i think i saw that as well but it didnt register.  i thought that was just an oddity of display, doh.

when i open the database in 'OOo330m13 (Build:9539)' in fedora14 i found the autonumber field as 'no' but could successfully save the field as autonumber-> 'yes' when save file.

passing the save fields wrong maybe?
Comment 4 collura 2010-11-13 01:28:42 UTC
i invite further observation because i am missing some step in the recreation process.  

0) i did have the problem in mswin-os but now cant reproduce.

i originally recreated the problem several times recreating various embedded hsql databases where autonumber failed with each test.

(the test case supplied earlier today in 
was created during the original test)

1) however i went back to mswin-os to reproduce this autonumber fail to look for further information on the autonumber state setting after reinstalling java and LibreO- again but couldnt reproduce.  

--originally i remember having to reset the autonumber to 'yes' repeatedly because it didnt seem to always stick while editing table design.

--i also remember originally getting a 
     'file has changed do you want to keep changes y/n?' 
kind of dialog popping up unexpectedly at times 
but i dont remember what i answered.

2) not sure if updated java since original test but was now 
'java-runtime- environment-1.6.0-update-22' ("jre v 6 u 22") 
which is current version as of checking java.com today.

i am wondering if an update to java or a cache flush cleared the problem or if it is intermittent or if i followed different database creation step this time.

maybe the autonumber issue was quirk of previous libre-o / jre installs and could be closed?  however the previous comment shows that someone else had problem too.

observations welcome.
Comment 5 collura 2010-12-07 15:34:16 UTC
auto-numbering seems to be working well as of

LibreO 3.3.0-release-candidate-1

thank you
Comment 6 collura 2010-12-07 15:37:46 UTC
seems to be fixed so closing for now.

will re-open if still issue for someone else or re-occurs.
Comment 7 sophie 2011-01-13 07:03:17 UTC
Closing - Sophie