Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Don,

Seems like a reasonable request to me, and I'll up the ante.

Where the &^%$ is the management - The Document Foundation - in all this, right now, today? Do they even watch this list? In short, do they give a damn that the only theoretically viable alternative to Access (for ordinary users) is in real trouble? Why aren't they showing up here with some clarifying position statement?

I'm desperate for time, a fix, and vision of a long-term solution to this mess. I have work to do today, a lot of it, and I can't do it. I can't solve the problem, and other than by implementing the regress-your-java solution idea (which I have yet to be successful with). No one else is solving it, either. For some, migrating to another backend is not a challenge. For the rest of us, it's unknown territory. I researched this a bit, and while there certainly IS stuff out there about how to do it, there's not a lot, and there are multiple levels of challenge with this solution anyway.

Personally, I'm definitely up for taking this on (what option do I really have?), but do we really have to straggle through the mountains one by one, eventually meeting on the other side, those who make it, to talk about the experience?

So, I propose two things:

1. Anyone who has TDF connections - please get on the phone and update them. The question is this, I think: how important, going forward, is Base, to them? If they are going to support it, today would be a very good day to do it. If not, yank the code, stop telling people they have a db component in LO, and start getting honest.

2. If LO's in trouble with the current sun-Java, so's OO. Where's Apache in this situation? Again, where's *TDF*? Why aren't they and Apache working together on this? Looks rather like a leadership problem, to me.

2. On the assumption that those of use who need a working db are going to have to find the way home ourselves (as I said, I need to get work done TODAY, and I'm not kidding) -

a. Can someone more Linux-clever than I lay out clearly the steps involve in implementing the solution found at the end of this thread - http://www.oooforum.org/forum/viewtopic.phtml?t=125253&postdays=0&postorder=asc&start=0 <http://www.oooforum.org/forum/viewtopic.phtml?t=125253&postdays=0&postorder=asc&start=0>. As I pointed on in another post last night, I tried it and simply got in over my head. This is a decent short-term solution.

b. Can we work together to lay out the steps to set up an alternative back end? I'm going to start on sqlite, Others may wish to work on a different db engine. Then let's get the procedure out where it can be seen and used by others.

c. Let's get altruistic about the poor bloke who, this morning, is about to set up a Base db using a java-run backend: Could someone put a notice in the documentation updating people about the current situation? It's not right for us to keep this information only on this list.

Now I'm off to fully regress my java (I don't see a problem with this), while I work on getting sqlite and Base to play together.

Tom

On 07/28/2011 09:16 AM, Don C. Myers wrote:
Hi Tom,

When the first problems showed up for me about 6 months ago, it was recommended to go back to the Java 1.6.0.22 from 1.6.0.24. I have my database on 4 computers, and could never make things work with getting a previous version installed, so I gave up and just tolerated the situation. Also, I had security concerns going backwards since, as I understand it, among other things updated Java versions have have security issues fixed. I'm relatively good with Ubuntu, but far from an expert. What we all know is that Java is the problem. Can someone give us instructions on how to use the LibreOffice front end with a database that doesn't require Java. I see that you had said that LibreOffice may be moving to sqlite? Is that a solution that anyone could help us with?

Don

On 07/28/2011 04:04 AM, Tom Cloyd wrote:
, On 07/28/2011 12:53 AM, Tom Cloyd wrote:
On 07/28/2011 12:44 AM, Alexander Thurgood wrote:
Le 27/07/11 18:14, Tom Cloyd a écrit :


That command appears to have cut 5 seconds off the record pointer move
test, and also off the full db search test I ran previously.

Well better than nothing I suppose, but I do sympathise. Did the JDK/JRE
change suggested by someone else help any further ?


Alex



Am just about to make the switch - will let you know asap! I'm very hopeful. And I've decided to switch to sqlite when I'm not so rushed. Have heard that that's where LO's going anyway.

Tom

Ug. This is getting ugly really fast. I'm really not on home ground here at all.

After 15 minutes of trying to make sense of what I found at
http://archive.canonical.com/ubuntu/pool/partner/s/sun-java6/, I downloaded
sun-java6-bin_6.22-0ubuntu1~10.04_i386.deb and

sun-java6-jre_6.22-0ubuntu1~10.04_all.deb, following the thread at http://www.oooforum.org/forum/viewtopic.phtml?t=125253&postdays=0&postorder=asc&start=0 <http://www.oooforum.org/forum/viewtopic.phtml?t=125253&postdays=0&postorder=asc&start=0>.


Then I did this at a console, with the following result:


tomc@LDT:~/software_archive$ sudo dpkg --unpack sun-java6-bin_6.22-0ubuntu1~10.04_i386.deb
[sudo] password for tomc:
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 38010 package 'amaya': error in Version string 'wx-11.3.1-1': version number does not start with digit dpkg: warning: parsing file '/var/lib/dpkg/available' near line 40706 package 'amaya': error in Version string 'wx-11.3.1-1': version number does not start with digit dpkg: warning: downgrading sun-java6-bin from 6.26-1natty1 to 6.22-0ubuntu1~10.04.
(Reading database ... 190655 files and directories currently installed.)
Preparing to replace sun-java6-bin 6.26-1natty1 (using sun-java6-bin_6.22-0ubuntu1~10.04_i386.deb) ...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend requires a screen at least 13 lines tall and 31 columns wide.)
debconf: falling back to frontend: Readline
sun-dlj-v1-1 license has already been accepted
Unpacking replacement sun-java6-bin ...
Processing triggers for desktop-file-utils ...
Processing triggers for menu ...
dpkg-query: warning: parsing file '/var/lib/dpkg/status' near line 38010 package 'amaya': error in Version string 'wx-11.3.1-1': version number does not start with digit

Most of this is just garble to me,


THIS is scary: "dpkg: warning: downgrading sun-java6-bin from 6.26-1natty1 to 6.22-0ubuntu1~10.04." I said UNPACK, not INSTALL. What's this "downgrading" nonsense? Then this: "Preparing to replace sun-java6-bin 6.26-1natty1" Huh? All this on an "unpack". This is beyond scary. This is nuts. What's up with this???


Then, and this is the main problem - where's the result of the command? I expected the unpack to put files in a dir, in the same dir as the DEB file. Isn't this usually what happens when one unpacks a file? But there's nothing there.


I'm in freefall right now. Don't know what just happened, don't know what to do next. Can anyone help?


Guess I'm not going to get any db work done tonight, after all. Not a good day.


Tom





--
Unsubscribe instructions: E-mail to users+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.