I thought it was a bug because of inconsistent behavior. When you connect
to a MySQL database using Base and Oracle's MySQL connector, you can ALTER,
CREATE, and DROP tables from the GUI in Base. I need to use a reference when
writing SQL so sometimes the GUI is the easiest way to get up to speed,
especially with complex queries.
Hi John,
Good Info.
I thought it was a bug because of inconsistent behavior. When you connect
to a MySQL database using Base and Oracle's MySQL connector, you can ALTER,
CREATE, and DROP tables from the GUI in Base. I need to use a reference when
writing SQL so sometimes the GUI is the easiest way to get up to speed,
especially with complex queries.
Unfortunately, even with the Mysql connector (which is actually pretty
good it has to be said) there will be times where you will have to
resort to SQL. Watch out for bugs / deficiencies in the in-built OOo SQL
parser when executing complex queries, you will have to switch the
parser off to get any meaningful result, even with the Mysql connector,
and there is a strange date calculation issue floating around that makes
adding and subtracting dates error prone.
Alex
I'm suffering the same problem.
OO Base 3.2 workd fine. Having upgraded to LO 3.3 (and tried OO 3.3), any
"date" format field cannot have a default date set.
My prior embedded HSQL database (from OO2.x, used in OO3.2) doesn't work -
the set default date enters nonsense in the field, which obviously then
errors since it doesn't fit the date format. Hence, no new entries can be
made.
Deleting the default date works OK.
However, I don't enter the date in my form - it is always "today" - so I
simply "edit" the table each day before starting data entry. This no longer
works, making LO3.3+ unusable for me.
The workaround of using SQL each day is unsatisfactory (and this was not
necessary for 3.2).
(Tried LO/OO3.3 on Ubuntu 10.10 & 11.04)
Hi
Have you already posted a bug-report about this or is there already one at
http://wiki.documentfoundation.org/BugReport
It might be worth posting one even if you don't have time to search through for
one. Triagers are quite smart about doing that and linking similar bugs
together.
Good luck and regards from
Tom
From: ugm6hr <ugm6hr@hotmail.com>
To: users@libreoffice.org
Sent: Sat, 4 June, 2011 8:59:37
Subject: [libreoffice-users] Re: Base Field Defaut Disables SaveI'm suffering the same problem.
OO Base 3.2 workd fine. Having upgraded to LO 3.3 (and tried OO 3.3), any
"date" format field cannot have a default date set.
My prior embedded HSQL database (from OO2.x, used in OO3.2) doesn't work -
the set default date enters nonsense in the field, which obviously then
errors since it doesn't fit the date format. Hence, no new entries can be
made.
Deleting the default date works OK.
However, I don't enter the date in my form - it is always "today" - so I
simply "edit" the table each day before starting data entry. This no longer
works, making LO3.3+ unusable for me.
The workaround of using SQL each day is unsatisfactory (and this was not
necessary for 3.2).
(Tried LO/OO3.3 on Ubuntu 10.10 & 11.04)--
View this message in context:
http://nabble.documentfoundation.org/Base-Field-Defaut-Disables-Save-tp2890141p3022557.htmlSent from the Users mailing list archive at Nabble.com.
--
Unsubscribe instructions: E-mail to users+help@libreoffice.org
In case of problems unsubscribing, write to postmaster@documentfoundation.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/users/
All messages sent to this list will be publicly archived and cannot be
deleted
Helpful thread - thank you. Any idea why not even the SQL tool will set a
default value for me? I spent lots of time in the Base_Tutorial and created
tables with SQL. The field that follows does NOT have a default value of 1
and, as this thread confirms, I can't set it in design mode.
"FieldName" NUMERIC(10) DEFAULT 1,
All my tables/relationships, etc. execute without fail (after much trial &
error) but when I create entries in this table, I do not get a default value
of 1. Any ideas?
Mac OS 10.5.8
LO 3.4.0
Thanks.
Hi,
Helpful thread - thank you. Any idea why not even the SQL tool will set a
default value for me? I spent lots of time in the Base_Tutorial and created
tables with SQL. The field that follows does NOT have a default value of 1
and, as this thread confirms, I can't set it in design mode."FieldName" NUMERIC(10) DEFAULT 1,
All my tables/relationships, etc. execute without fail (after much trial &
error) but when I create entries in this table, I do not get a default value
of 1. Any ideas?
What was the SQL command you used to create the default values in your
table? It might be a problem of the initiation query.
uhhhh...and so quickly we reach the limits of my understanding here. Whoops.
So I thought I was demonstrating that command with that one line I
referenced. Does it help to put the whole table setup? Or would all the
tables be helpful? Again here I used the Mental Health Clinic Database
(from the tutorial) as a guideline. This table is an intermediary to deal
with a many to many relationship.
CREATE TABLE "Vulnerability" (
"Vuln ID" INTEGER NOT NULL,
"Vulnerability" INTEGER NOT NULL,
"VulnInstance" NUMERIC(10) DEFAULT 1,
CONSTRAINT PK_ISSUE PRIMARY KEY ("Vulnerability", "Vuln ID" ),
CONSTRAINT FK_ISSUE FOREIGN KEY ("Vulnerability") REFERENCES "Issue Type"
("Issue ID"),
CONSTRAINT FK_SCAN_VULN FOREIGN KEY ("Vuln ID") REFERENCES "Scan" ("Scan
ID")
);
Hi,
CREATE TABLE "Vulnerability" (
"Vuln ID" INTEGER NOT NULL,
"Vulnerability" INTEGER NOT NULL,
"VulnInstance" NUMERIC(10) DEFAULT 1,
CONSTRAINT PK_ISSUE PRIMARY KEY ("Vulnerability", "Vuln ID" ),
CONSTRAINT FK_ISSUE FOREIGN KEY ("Vulnerability") REFERENCES "Issue
Type"
("Issue ID"),
CONSTRAINT FK_SCAN_VULN FOREIGN KEY ("Vuln ID") REFERENCES
"Scan" ("Scan
ID")
);
I was able to get the code fragment
CREATE TABLE "Vulnerability" (
"Vuln ID" INTEGER NOT NULL,
"Vulnerability" INTEGER NOT NULL,
"VulnInstance" NUMERIC(10) DEFAULT 1)
to generate a table in Base but it did not accept the default value.
When I copied the table and edited the copy, forcing the default value
to be 1, it did accept the value.
When I created a table by design view, it would not display the assigned
default value.
Testing the query in other databases (MariaDB and SQLite) it worked
erratically, SQLite displaying the default value and MariaDB not
displaying it.
Checking my references, the syntax is correct of Column_name data_type
[column_attributes].
Hi,
Helpful thread - thank you. Any idea why not even the SQL tool will set a
default value for me? I spent lots of time in the Base_Tutorial and created
tables with SQL. The field that follows does NOT have a default value of 1
and, as this thread confirms, I can't set it in design mode.
https://bugs.freedesktop.org/show_bug.cgi?id=38337
Alex