A copy of an .odb won't run for me on 2nd PC

English
#1

Lots of “situtation” data for you at the start of this.

Eventually I get to “I copied an .odb file from one machine to another (Both Windows), and it won’t work on second machine. (“Connection to the data source [name given] could not be established”.)”

I had a little .odb on a Win 10 machine. Created using embedded Firebird. (I have set the LO Advanced Option to Enable Experimental Features.)
LO 7.1.1.2

I closed the LO session. Used just the basic OS “File Explorer” to copy JUST the .odb file to a new directory. Double clicked on it… database opened just fine. A separate copy of it, I think. I don’t think it was accessing anything in the .odb it “descended from”.

Made a few changes… deleted some records from a table. Changed the contents of some fields in some of the tables.

Closed it. (Later: It reopens, works, just fine… THERE. Yesterday, before I’d encountered today’s problems. Still works fine there today.)

Today, I tried USING a copy of the “derived” .odb on a second Win10 machine.
The 2nd machine has just been updated to LO 7.3.7.2. (The “Tools/Options/LibreOffice/Advanced” still shows Experimental Features enabled.)

I also updated the second machine’s Java today. It is now at 1.80_351, and the “blob” on the Libre Office Tools… Advanced dialog is “filled in”.

The file is called “FDB042-BooksShrt.odb”. There’s a table in in called “BooksShort”.

Dbl-clicked on the .odb. Usual main Base dialog opened. Selected “Reports”. Saw what I expected to.

Dbl-clicked on report I wanted to run, and go…

“Connection to the data source FDB042-BooksShort could not be established.”

Said “OK” to that.

Clicked on “Tables” in the Base main dialog. Immediately got same dialog.

I’m writing this after going around and around for a while. When this started…

On the second machine, after starting the .odb, went to “Tools/Options/LibreOffice Base/ Databases” and registered the database on the machine it won’t run on. (Apparently unnecessarily. In checking this step, I now discover that it is NOT “registered” on the first machine. But it wasn’t working BEFORE I registered it, either.)

The .odb, by the way, is the one uploaded as part of…

#2

Hello,
Appears to be caused by this now corrected tdf#144163.
.
Works on first machine because it has the incorrect code.

1 Like
#3

@MSPhobe : Please report the complete error-message.

#4

Using LO v 7.4.3.2 the error I got was:

Screenshot at 2022-12-02 10-01-00

.

Using LO v7.1.1.2 the Base file opens without error. Just need to find the error itself.
.
Edit:
Error is in

Screenshot at 2022-12-02 10-09-14
Screenshot at 2022-12-02 10-09-14738×601 90.4 KB

.
BookID field defined as length of 6 but clearly see 8 or maybe more.

1 Like
#5

Sorry, Robert… THANK YOU for getting back to me so soon!.. see comment to Ratslinger’s second post?

#6

@MSPhobe
Was able to create a new table with the field set as 8 characters and all is OK.
.
Here is a copy → FDB042-BooksShrt.odb (26.5 KB)

#7

Ratslinger! You are a STAR! AGAIN!.. Thank you.

For the very quick answer. For the considerable trouble you had to go to in order to confirm your guess.

My “faith” in LO/Firebird remains… It is shaky, but I am determined that the commercial alternatives should not win. These things try my patience, dedication… but the FABULOUS support from the LO community when it comes to getting past the problems MORE than makes up for all of that.

Scary, though. Glad I work on two machines. Glad I still have the old one, where I can now try to find all of the too-long field entries, trim them. Sigh.
.
I hate updating, because of things like this… but I know it is the right thing to do.
.
Ah well.

Tom, England.

#8

Be aware it may not be that simple. In the sample I repaired the problem field which was part of the primary key field. Can’t simply change the field size - not allowed. Created new table definition and then copied data from one to the other.
.
Also, two machines may be nice but I find regular backups of my data to be highly valuable.

#9

Understood… but thank you for checking! And I hope that others will read this thread in the future: your advice on both points is important.
.
In fact, though I “understood”, and was working on the rebuild, something in what you said helped steer me past a bad approach that might, eventually, have led to a successful rebuild… but your comment opened my eyes to a better route to attempt.
.
Experiences like this reinforce one of my basic principles: Keep it simple. (In everything, of course, but particularly in using Base.) I avoid “fancy” data types, in the hopes that my general use of just simple text and integers helps make getting out of messes easier. (The above is simply meant as advice to others reading this thread, should that arise later.)
.
(And thank you for showing how to achieve a blank line between paragraphs… I only spent 20 minutes trying to find THAT before seeing the answer in your posts! Sigh.)

#10

You can also use <br> as


done here

#11

A little hint: “BooksShort”.“BookID” is VARCHAR(100) while “BookWhere”.“BookID” is VARCHAR(8). You could connect this as Primarykey → Foreignkey in Tools → Relationships, but you couldn’t save all values of “BooksShort”.“BookID” in “BookWhere”.“BookID”. I would prefer to set both field with the same length.

#12

“BooksShort”.“BookID” is VARCHAR(100)

was carelessness! (As was setting “BookWhere”.“BookID” to only 6. A few needed 7, and under the not-out-of-date-so-very-long version of LO that accepted the 7 char field entries, the problems arose. ARGH.

#13

.
As the image in my above comment posted shows, seems most, if not all, needed 7 & some needed 8. :slight_smile:

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.