Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

First, the Captcha problem has been around for a while - no sign of when it will be fixed. Language varies each time.

You don't mention anything about your setup. I'll guess you have a fairly recent version of LO and are dealing with an embedded DB. The embedded version of HSQL (the database) is 1.8 whereas the current version is 2.3 or maybe higher. What you are looking for with your time field is precision. I don't see this defined in v1.8 but I see it in the v2.3 documentation. You would define it as FIELD-NAME TIME(X) where X = 1 to 6 decimal positions. The default is 0.

Tried to set up a new table using direct SQL entry (since there is no way to do this in the regular table definition). It is rejected in HSQL v1.8 with a numeric value out of range error. Then tried with a split DB using HSQL v2.3 and it came back with a successful creation. However, upon testing, the decimal positions were always zeroes when the field entry was made. I also tried using SQL Workbench/J to enter the data but got an invalid date field error.

Next I tried a Base file connected to MySQL. Again direct SQL to create table was OK but field never displayed decimal positions. Then went to SQL Workbench, set up the table and records entered worked. Using this table in Base it still displayed zeroes for the decimals even though digits were in the records. This is a bug in Base and you should report it (click here). I don't see one reported currently.

As for the other fields. The 0.900, 0.925 etc - set field as DOUBLE in table with format of one leading zero and three decimal positions.

The characters after the numbers? Once you mix numbers & letters this is a TEXT (VARCHAR) field. What seems appropriate is a DOUBLE field for the number and VARCHAR(2) for the text. In form data entry for the characters you can limit the selection by using a list box and have only allowable entries as a Valuelist. You can place the two fields together if necessary for various displays or reports by concatenating them in an SQL statement as one field.

First, the Captcha problem has been around for a while - no sign of when it will be fixed. Language varies each time.

You don't mention anything about your setup. I'll guess you have a fairly recent version of LO and are dealing with an embedded DB. The embedded version of HSQL (the database) is 1.8 whereas the current version is 2.3 or maybe higher. What you are looking for with your time field is precision. I don't see this defined in v1.8 but I see it in the v2.3 documentation. You would define it as FIELD-NAME TIME(X) where X = 1 to 6 number of decimal positions. The default is 0.

Tried to set up a new table using direct SQL entry (since there is no way to do this in the regular table definition). It is rejected in HSQL v1.8 with a numeric value out of range error. Then tried with a split DB using HSQL v2.3 and it came back with a successful creation. However, upon testing, the decimal positions were always zeroes when the field entry was made. I also tried using SQL Workbench/J to enter the data but got an invalid date field error.

Next I tried a Base file connected to MySQL. Again direct SQL to create table was OK but field never displayed decimal positions. Then went to SQL MySQL Workbench, set up the table and records entered worked. Using this table in Base it still displayed zeroes for the decimals even though digits were in the records. This is a bug in Base and you should report it (click here). I don't see one reported currently.

As for the other fields. The 0.900, 0.925 etc - set field as DOUBLE in table with format of one leading zero and three decimal positions.

The characters after the numbers? Once you mix numbers & letters this is a TEXT (VARCHAR) field. What seems appropriate is a DOUBLE field for the number and VARCHAR(2) for the text. In form data entry for the characters you can limit the selection by using a list box and have only allowable entries as a Valuelist. You can place the two fields together if necessary for various displays or reports by concatenating them in an SQL statement as one field.