The database connection functions in openOffice Calc have stopped
functioning for me after running for years. When I select from the menu
(View -> Data Sources) or simply use the F4 shortcut key, Calc simply rolls
over and dies.
System: openOffice 3.1.1.4/5, openSUSE 11.2 X86_64, KDE4.3.1 or 4.3.3.
History: function currently works with oS 11.1 and OO 3.1.1.5. A fresh
install of 11.2/KDE4 works as well until I update the system at which point
it rolls over.
Methodology: Attempting to isolate the problem, I installed a clean copy of
11.2 to clean partitions, skipping the updates during installation. Selected
Data Sources and OO worked as expected. I next updated OO from the initial
3.1.1.4 to 3.1.1.5. Using either yast or zypper to update, OO still worked
as expected from both the menu and shortcut. I let yast update the entire
system and OO failed - selecting data sources caused it to simply die with
no immediate error notifications.
The failure after updating the system with working OO installation suggests
that the problem is in the system somewhere, not OO. I have tried the
solutions offered in the various forums with no results. I have 3 questions
before I spend any more time with this.
Anybody got a solution at hand?
Where the heck would OO log any errors? I don’t even know where the
crash is happening at this point.
Can someone check me on this? The test is simple: open a Calc window and
select Data Sources from the View->Data Sources item or with the F4 key.
Any result other than an immediate termination will tell me it’s a local
problem and I can go back to the drawing board
> Hi
> Works fine on 32bit with 3.1.1.4 so where is 3.1.1.5 coming from? If
> it’s not from the standard update repository this would be an issue.
>
> Can you post the output from;
>
> zypper lr -d
>
> Note: the above command is the trademark of caf4926
>
Good catch - this only affect the 64-bit versions here as well. The couple
of 32-bit installations are still good to go. The OO 3.1.1.5 comes from the
build service OO repo. I tried that on the off chance that there was some
screwy dependency problem between the updated system files and the initial
OO 3.1.1.4 version but no go - either openOffice version works equally well
until I update system code.
From the last test version - bone stock except for Nvidia video so I could
read it.
I have confirmed the behavior. Here is a trace for the standard 3.1.1.4 build: http://pastebin.com/m68adbdba. The behavior also exists in the 3.1.1.5 build from the OpenOffice.org:STABLE repo. (Both 64-bit.)
Arrrggh! Now I know why I lost so much hair during those years as a
developer!
Trying to get a good clean test case, I re-installed 11.2 to two clean
partitions. To make sure I had a repeatable test case, I installed w/o
updating during the installation. Ran Calc and all worked as I expected so
I had a clean trace file. Ran the online update which had always exposed
the problem before - but this time Calc ran correctly for the data source
test. First time it has done that since I started messing with 11.2. I
still have a data problem with loading dBase (.dbf files) but the data
source issue was not there on this installation. I’ll compare the trace
files with what david posted to see if anything pops out but… You can’t
fix what you can’t find. Whatever the source of this issue is, it isn’t a
clear cut problem at this point since find a case where it didn’t repeat.
Given all the problems with 11.2/KDE4.3.1 I’ve pretty much decided to keep
everyone on 11.1, skip 11.2, and concentrate my time on 11.3 for the next
upgrade here. If I’m going to beta test, I might as well do it with the
next unit to come down the pike instead of one likely to be superceded
before the problems are all resolved for 11.2. I’ll keep records of this
latest install and post back if I can isolate the problem then file a bug
report. Right now, I’ve spent way more time than I want to on this
already.
I do appreciate the comments here - this is the first major debug effort
I’ve had to make using Linux so the strace pointer was much appreciated.
maybe that will pay off yet.
