Issue 112359 - Base broken on armel (The data could not be loaded. Syntax error in SQL expression=
Summary: Base broken on armel (The data could not be loaded. Syntax error in SQL expre...
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 3.2
Hardware: Other Linux, all
: P2 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2010-06-14 08:59 UTC by rene
Modified: 2013-02-07 22:32 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description rene 2010-06-14 08:59:43 UTC
From (actually I saw it
a few days ago already myself):

-- snip ---
I have a very simple (1 table) MySQL database that works fine with isql. When I
attempt to access it using a database under easy-debian/armel
I get the pop-up error message: 'The data could not be loaded. Syntax error in
SQL expression'. When I hit 'More' and look further, the SQL appears well-formed
('SELECT * from "Events"') but it returns 'SQL Status HY000 Error code: 1000'
and the additional message 'INVALIDSYMBOL, expecting $end, Invalid symbol'.

The same Openoffice build (9483) under debian/i686 works normally with the same
so I presume the problem is connected with the armel build.
--- snip ---

Logically, the smoketest also fails to the DB checks.
In fact I saw this using the internal hsqldb and thought it was a Java issue,
but it also happens with the MySQL Connector...
Comment 1 rene 2010-06-14 09:00:30 UTC
reassign away from dbaneedsconfirm (they probably don't have Linux/arm anyways,
so what to confirm there?)
Comment 2 Frank Schönheit 2010-06-14 12:15:58 UTC
dbaneedsconfirm is a pool, "fs" isn't. If we say that this issue cannot be
confirmed, then issues@dba is the right place.

I don't have access to this platform myself, (and by the way, I am not an active
Base developer anymore,) so assigning this issue to me doesn't make sense, too.
Comment 3 rene 2010-06-14 12:21:41 UTC
fs: well, as I said I can confirm it. Saw it even before the Debian bug report
came in.... But thanks, next time I'll assign directly to issues@dba
Comment 4 Frank Schönheit 2010-06-14 12:25:26 UTC
well, issues@dba is our pool for kind of "external" issues. Without access to
such a platform, I cannot do much about this.
Comment 5 rene 2010-06-14 14:56:29 UTC
I am not 100% sure, but I think this actually worked in past releases (prior to
Comment 6 rene 2010-06-22 17:57:03 UTC
setting to P2 (whole module broken!). Anyone who want sto debug this and hasn't
a a arm box, I do and can give you an account if needed
Comment 7 caolanm 2010-06-22 20:31:26 UTC
As a wild stab, are these built with the system unixODBC headers ?, I wonder if
there's anything in that theory worth chasing
Comment 8 rene 2010-06-22 20:56:15 UTC
cmc: yes
Comment 9 rene 2010-06-22 22:13:22 UTC
Comment 10 rene 2010-06-27 23:22:05 UTC
cmc: tried it, (unsurprisingly, as it fails for stuff not involving ODBC, too)
fails still