Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version
Alter Table "MYTABLE" Alter Column "DATEFIELD" set default '2016-12-31'

Alter Table "MYTABLE" Alter Column "DATEFIELD" set default '2016-12-31' '2016-12-31'

Edit 12/02/2016

Based upon @Quarto Die comment, I did some further testing. The testing was done using an embedded DB, a split DB and a MySQL DB. The only field type of concern here is a Date

type.

If a table is created without a default date, the ALTER statement above works time after time.

Embedded DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (see this post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The answer is to delete the default by editing the table. Then the ALTER statement works (although you can't view it by editing the table - another bug).

Split DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default. Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used SQL Workbench/J) there was NO problem with an initial default date and the ALTER statement worked.

MySQL DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default. Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used MySQL Workbench) there was NO problem with an initial default date and the ALTER statement worked.

So the problem always occurs, and the ALTER statement has no affect (even with YYYY-MM-DD format), if the default is set in the original design of the table. The problem definitely lies within LO Base.

In the next day or two I will check bug reports and if none, submit one.

Alter Table "MYTABLE" Alter Column "DATEFIELD" set default '2016-12-31'

Edit 12/02/2016

Based upon @Quarto Die comment, I did some further testing. The testing was done using an embedded DB, a split DB and a MySQL DB. The only field type of concern here is a Date type.

If a table is created without a default date, the ALTER statement above works time after time.

Embedded DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (see this post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The answer is to delete the default by editing the table. Then the ALTER statement works (although you can't view it by editing the table - another bug).

Split DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default. Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used SQL Workbench/J) there was NO problem with an initial default date and the ALTER statement worked.

MySQL DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default. Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used MySQL Workbench) there was NO problem with an initial default date and the ALTER statement worked.

So the problem always occurs, and the ALTER statement has no affect (even with YYYY-MM-DD format), if the default is set in the original design of the table. The problem definitely lies within LO Base.

In the next day or two I will check bug reports and if none, submit one.

Edit #2 12/02/2016 - Have further info on default values. When using Base to create and set the default for a table field, it is stored in the content.xml file of the .odb while using an external source, the default is stored in the database itself.

What this means is with an embedded DB you can simply edit the table and remove the default. Then use the ALTER statement to set a new default.

With split or external DB, open the .odb with an archive manager, open the content.xml file with a text editor, find the faulty date (format will look correct) and delete the date leaving the quote marks intact. Then the ALTER statement works (tested).

Alter Table "MYTABLE" Alter Column "DATEFIELD" set default '2016-12-31'

Edit 12/02/2016

Based upon @Quarto Die comment, I did some further testing. The testing was done using an embedded DB, a split DB and a MySQL DB. The only field type of concern here is a Date type.

If a table is created without a default date, the ALTER statement above works time after time.

Embedded DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (see this post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The answer is to delete the default by editing the table. Then the ALTER statement works (although you can't view it by editing the table - another bug).

Split DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default. default(see below) Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used SQL Workbench/J) there was NO problem with an initial default date and the ALTER statement worked.

MySQL DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default. default(see below). Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used MySQL Workbench) there was NO problem with an initial default date and the ALTER statement worked.

So the problem always occurs, and the ALTER statement has no affect (even with YYYY-MM-DD format), if the default is set in the original design of the table. The problem definitely lies within LO Base.

In the next day or two I will check bug reports and if none, submit one.

Edit #2 12/02/2016 - Have further info on default values. When using Base to create and set the default for a table field, it is stored in the content.xml file of the .odb while using an external source, the default is stored in the database itself.

What this means is with an embedded DB you can simply edit the table and remove the default. Then use the ALTER statement to set a new default.

With split or external DB, open the .odb with an archive manager, open the content.xml file with a text editor, find the faulty date (format will look correct) and delete the date leaving the quote marks intact. Then the ALTER statement works (tested).

Alter Table "MYTABLE" Alter Column "DATEFIELD" set default '2016-12-31'

Edit 12/02/2016

Based upon @Quarto Die comment, I did some further testing. The testing was done using an embedded DB, a split DB and a MySQL DB. The only field type of concern here is a Date type.

If a table is created without a default date, the ALTER statement above works time after time.

Embedded DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (see this post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The answer is to delete the default by editing the table. Then the ALTER statement works (although you can't view it by editing the table - another bug).

Split DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default(see below) Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used SQL Workbench/J) there was NO problem with an initial default date and the ALTER statement worked.

MySQL DB - If a default date is declared, it gets screwed up unless you use the format of YYYY-MM-DD (same post). Any other format gets really messed up. The ALTER statement executes but has no effect on the default. The ONLY answer found is to delete the field by editing the table and adding the field again without the default(see below). Then the ALTER statement works (although you can't view it by editing the table - another bug). If the table is created outside of LO Base (in this case used MySQL Workbench) there was NO problem with an initial default date and the ALTER statement worked.

So the problem always occurs, and the ALTER statement has no affect (even with YYYY-MM-DD format), if the default is set in the original design of the table. The problem definitely lies within LO Base.

In the next day or two I will check bug reports and if none, submit one.

Edit #2 12/02/2016 - Have further info on default values. When using Base to create and set the default for a table field, it is stored in the content.xml file of the .odb while using an external source, the default is stored in the database itself.

What this means is with an embedded DB you can simply edit the table and remove the default. Then use the ALTER statement to set a new default.

With split or external DB, open the .odb with an archive manager, open the content.xml file with a text editor, find the faulty date (format will look correct) and delete the date leaving the quote marks intact. Then the ALTER statement works (tested).

Edit 12/03/2016: Bug report submitted Bug 104375.