Base/Firebird Queries broken

users
#1

I have shifted one of my database to Firebird using the advanced 'migration' tool as a test.

One query I am testing is a join of 4 tables.

Series
  Series

  Date
  Date Date

  Time
  Time Time

Criterion: Series 134, Select True

I do have Alias fields, but understand from net search that they are disregarded by Firebird.

I have waited 5 minutes for the query to process, but it only results in a blank screen or not responding.

Windows 7 64 bit. LibreOffice Version: 6.1.3.2 (x64)

The query did work with HSQLDB.

Any hint as to where I'm going wrong.

Thanks

Paul

#2

To begin with, what is the query's SQL. Someone might be able to discover the problem from there. In addition, knowing the properties of each one of the tables could also help solve it.

#3

Hi Paul,

as Dan wrote:
Post the code of the query (opening SQL-view and copy).

There are functions, which will work in HSQLDB, but won't work, with the
same name, in Firebird.

Regrads

Robert

#4

Without the query definition, it is going to be like gazing into a
crystal ball...all sorts of things might not work in the same way, the
time values, the date values (especially if there are calculations),
subselects, unions, joins, etc...

Alex

#5

Here is the query...

SELECT "Equipment"."ID", "Equipment"."P_Model", "Equipment"."P_Model_No", "Equipment"."Power Meter", "Equipment"."Power_No", "Equipment"."Ion Meter", "Equipment"."Ion_No", "Equipment"."Series", "Equipment"."Power Meter 2", "Equipment"."Power_No 2", "Equipment"."Power Meter 3", "Equipment"."Power_No 3", "Equipment"."Vendor_PO_No", "Ions-IM"."Model", "Ions-IM"."Tube", "Ions-IM"."Position", "Ions-IM"."Date", "Ions-IM"."Time", "Ions-IM"."Ions", "Ions-IM"."Select", "Ions-IM"."Series", "Volts-High"."Time", "Volts-High"."Reading" "Vo-Hi-Reading", "Volts-High"."Type" "Vo-Hi-Type", "Volts-High"."Series", "Volts-High"."Setting", "Amps"."Reading" "Am-Reading", "Amps"."Type" "Am-Type", "Amps"."Series", "Amps"."Setting" FROM "Ions-IM", "Equipment", "Volts-High", "Amps" WHERE "Ions-IM"."Series" = "Equipment"."Series" AND "Volts-High"."Series" = "Ions-IM"."Series" AND "Volts-High"."Date" = "Ions-IM"."Date" AND "Volts-High"."Time" = "Ions-IM"."Time" AND "Amps"."Series" = "Volts-High"."Series" AND "Amps"."Date" = "Volts-High"."Date" AND "Amps"."Time" = "Volts-High"."Time" AND "Equipment"."Series" = 134 AND "Ions-IM"."Select" = TRUE ORDER BY "Ions-IM"."Date" ASC, "Ions-IM"."Time" ASC, "Ions-IM"."Ions" ASC

I have several others that continue to work correctly.  I am going to try to see if the failure applies to a particular table(s).

Thanks

Paul

#6

Hi Paul,

Have a look at

"Ions-IM"."Select" = TRUE

Did the migrationtool set the field "Select" to a BOOLEAN-field?

"Equipment"."Series" = 134

Did the migrationtool import the field as a INTEGER field?

There is no function in the query, only 4 tables connected ...
The only possibility to find the reason why Firebird couldn't execute
the query at this moment is to delete some parts of the query and try if
it will work without this parts.

By the way: There are only tables connected in theis query, not a view
connected with tables?

Regards

Robert

#7

Hi Paul,

SELECT "Equipment"."ID", "Equipment"."P_Model",
"Equipment"."P_Model_No", "Equipment"."Power Meter",

Check that the space in the field "Power Meter" isn't causing an issue.

There was a known bug about spaces being misinterpreted by the parser.

"Equipment"."Series", "Equipment"."Power Meter 2", "Equipment"."Power_No
2", "Equipment"."Power Meter 3", "Equipment"."Power_No 3",

Same here for "Power Meter 2" and "Power Meter 3"

"Ions-IM"."Ions", "Ions-IM"."Select", "Ions-IM"."Series",

Also check that the field name "Select" in Ions-IM.Select isn't being
misinterpeted.

"Volts-High"."Time", "Volts-High"."Reading" "Vo-Hi-Reading",

What is "Vo-Hi-Reading" - is this supposed to be an ALIAS ? Maybe check
whether that is correctly supported.

"Volts-High"."Type" "Vo-Hi-Type", "Volts-High"."Series",

Same here with "Vo-Hi-Type"

"Volts-High"."Setting", "Amps"."Reading" "Am-Reading", "Amps"."Type"

Same here with "Am-Reading"

"Am-Type", "Amps"."Series", "Amps"."Setting" FROM "Ions-IM",
"Equipment", "Volts-High", "Amps" WHERE "Ions-IM"."Series" =
"Equipment"."Series" AND "Volts-High"."Series" = "Ions-IM"."Series" AND
"Volts-High"."Date" = "Ions-IM"."Date" AND "Volts-High"."Time" =
"Ions-IM"."Time" AND "Amps"."Series" = "Volts-High"."Series" AND
"Amps"."Date" = "Volts-High"."Date" AND "Amps"."Time" =
"Volts-High"."Time" AND "Equipment"."Series" = 134 AND
"Ions-IM"."Select" = TRUE ORDER BY "Ions-IM"."Date" ASC,
"Ions-IM"."Time" ASC, "Ions-IM"."Ions" ASC

Not sure about how many left join conditions you can currently have.
That would probably need checking by removing them one-by-one until you
get something that works.

As Robert has mentioned, perhaps the migration didn't convert the data
types correctly, so your comparisons in the join conditions are no
longer working.

Good luck !

Alex

#8

See below...

Hi Paul,

Have a look at

"Ions-IM"."Select" = TRUE

Did the migrationtool set the field "Select" to a BOOLEAN-field?

Yes

"Equipment"."Series" = 134

Did the migrationtool import the field as a INTEGER field?

Not quite. Series is set to Number [Numeric]

There is no function in the query, only 4 tables connected ...
The only possibility to find the reason why Firebird couldn't execute
the query at this moment is to delete some parts of the query and try if
it will work without this parts.

By the way: There are only tables connected in theis query, not a view
connected with tables?

Not sure what you mean. These queries are developed to be linked to a Writer document as test data documentation. It is used to check the quantity of readings per unit at two each. Incorrect quantities of records prove data missing or inaccurate on import to Base.

Regards

Robert

Thanks

Paul

#9

I am receiving the following error when opening a query.

firebird_sdbc error:
*Dynamic SQL Error
*SQL error code = -104
*Invalid usage of boolean expression
caused by
'isc_dsql_prepare'

The table names are: Amps       Volts-High

The two tables involved both have one boolean field each, so I removed them from the query. The error still occurs.

I am taking this to mean that there is a boolean comparison happening that is not in the SQL generated by Base.

Is this possible?

Thanks

Paul

#10

I have replaced blanks with underscores in field names in tables.

I have removed alias named fields from queries.

It did not appear to make a difference.

I should note that tables Amps, Volts-High and  Volts-In have the same or more field names.

As each table name is prefixed to a field, I would not think this a possible error. Am I correct in this assumption?

Thanks

Paul

#11

This bug perhaps ?

http://tracker.firebirdsql.org/browse/CORE-5367?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel

Not sure which version of Firebird we are using in LO - 3.0.1 or 3.0.2 ?

Alex

#12

Hi Paul,

I would remove

"Ions-IM"."Select" = TRUE

and

"Equipment"."Series" = 134

and try the query again.

Both commands are right in the internal Firebird-Database. I could test
it with with LO 6.1.4.2 here. But could be there is something wrong with
the fields ...

Is there another Boolean field part of the query?

You could also send me the database with some dummy-data as private
mail, so I could have a look. Would be good to see the reason for
writing a bug and describe it in Base Handbook.

Regards

Robert

#13

Found this at https://stackoverflow.com/questions/31611233/determine-firebird-version-with-sql-version-2-1

SELECT rdb$get_context('SYSTEM','ENGINE_VERSION')... -- ENGINE_VERSION

>= 2.1 Only problem is, when run as "Execute SQL Statement" menu item, it errors as

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

I'm sure it's buried somewhere. Any hints anyone? I am by no means an SQL expert, Thank you for being patient. Paul |

#14

Howdy,

Yes, I have a suggestion - there is a property in the Base file which is
incorrectly set during the Migration Assistant run and must be fixed. The
error message looks like this is what is biting you.

The fastest way to fix it is at follows:
Close the base file and exit LibreOffice.
Rename the base file from <filename>.odb to <filename>.zip
Now open the file with your favorite zip tool.
You fill find a file named content.xml in the root of the file.
Open that with a text editor.
Search for this string: db:parameter-name-substitution="false"
Edit that so that it reads db:parameter-name-substitution="true"
Save your changes.
Close the zip file, it should ask if you want to update the file with the
change and answer yes.
Change file name back to <filename>.odb and you should be good to go.

Best wishes,

Drew

#15

Also - if you would prefer you can make this fix with a small basic macro.

If you would rather go that way here is what you do.

Open the Base file in Libreoffice.
From the menu select: Tools -> Macros -> Organize Dialogs.
On the Organize Dialogs dialog select the 'Libraries' tab.
On this tab there is a drop down list for 'Location'
Pull that down and you will see your ODB file listed, select it.
Click on the button 'New'
Default name should be 'Library1', choose that DO NOT PUT THIS CODE IN THE
STANDARD LIBARARY
With the basic editor open copy and past the following into the editor

Option Explicit
Sub ensureConnection()
Dim DBDocUI as Object
on error resume next
DBDocUI = ThisDatabaseDocument.currentController
if not DBDocUI.isConnected then
DBDocUI.connect
end if
on error goto 0
End Sub

Sub Main
ensureConnection()
ThisDatabaseDocument.DataSource.Settings.ParameterNameSubstitution = true
End Sub

Execute the macro - the property will be updated.

Now you can remove the 'Library 1' basic library you added, it is no longer
needed.

PS the reason for not updating the standard library is that in Libreoffice
once the Standard library is updated with anything it is difficult to drop
it completely and the file, even if you remove all the code, will form then
on act as if it has embedded macros when it doesn't. If you add a library
with a different name however you can remove it and if standard is also
empty at that time it is also removed and the file will open without the
embedded macro complaint.

#16

Ok, things are narrowing down on this issue.

I have a Query Design view in which I have a field Series set to 134.

I remove the 134 and press enter.

Run Query (F5)

It works.

Add back in 134 to Series field.

It works

Save it and save the database.

Double click on the query to run it.

Result in:

Error code: 1

firebird_sdbc error
*Dynamic SQL Error
*SQL error code = -104
*Invalid usage of boolean expression
caused by
'isc_dsql_prepare'

It appears that the run function is adding an operation that is not in Query Design view.

Any suggestions?

Thanks

Paul

#17

So, can you open that Query definition, the one that raised the error when
you double clicked on it, in design view and Run it and it works?

Is that what you are saying?

Thanks

#18

Before I forget - the files used for to gather these runtime numbers are
found here:
https://gerrit.libreoffice.org/#/admin/projects/benchmark

There are five xls files with an explanation as to what the spreadsheet is
evaluating.

They are 4 years old it looks like but seem to be as good as I've found for
example files for this feature.

Seems to me it might be worthwhile to offer them for download (maybe as a
zip file) and reference that download location in the video and/or
associated posting text.

#19

Sorry - that last email wen to the wrong mailing list - please disregard it
here.

#20

Hello Drew

I assumed that you are answering the question on error 104.

I changed the file as per your instructions to

db:parameter-name-substitution="true"

, but error 104 is still there.

Do I have to go back to my original file a migrate again with this fix or am I fixing

SELECT rdb$get_context('SYSTEM','ENGINE_VERSION')... -- ENGINE_VERSION
Thanks

Paul