With a Split database, is it necessary to register the DB if all associated files are in a common directory?
The question arises from an error about a missing/cant find class path (there are none) when trying to do a Data > Refresh in a Calc file where the source table is part of the Split DB. This is happening to a person I have sent the DB directory to via Drop Box.
Thanks in advance,
Joe
Just encountered this on a different question. The related Calc or Writer documents connect to a database via the registered DB name. If the ‘package’ is moved/copied to a different system these related files are trying to access the DB to refresh via the registered name. If that specific name is not registered to the correct DB you get the error.
Simple enough to fix. On the relocated system, simply register the DB with the same name as was originally used.
Edit 9/24/2017:
To insure not screwing up anywhere, just performed another test as laid out in both questions.
- Used portable split DB (as you have) in Dropbox folder.
- Created Calc file linked to this .odb in Dropbox folder & placed in split folder. All works OK.
- Copied split folder to new location.
- In new location, opened .odb & deleted a record.
- Opened Calc in new location & refreshed data. Still shows record I supposedly deleted.
- With the Calc file still opened, changed Registered name location to point to new location of .odb.
- Again, using still opened Calc file, refreshed data. Deleted record was now not in list.
It is all in where the registered name is pointing to.
BTW - I know this area of conversation briefly arose in a past Q&A and I know it wasn’t full addressed at the time. Apologies for that. For more on my escapades with this and Dropbox, see my answer in this post.
That’s my guy. On my system, I have the Drop Box location as the registered DB. I then copied the Drop Box folder to another folder name/location that I use for testing before making changes to the Drop Box DB. I have not registered this testing location, however it works fine and I am able to refresh the data in the .ods files without issue. Is it because John changed the name of the DB (just learning this)? Or am I also missing something?
Referring to your answer above, if John were to just copy the Drop Box folder to a new location, leaving everything else the same (specifically the DB name), will this problem be solved, or is this a bigger obstacle than I’m understanding? When the 3rd user begins to get involved, will this same problem John is having recur? Again, going for clarification of your above answer.
Thanks again for all you do.
@JoeCastor I believe you are leading yourself into problems. When dealing with this situation it helps to look at results just as the programs do.
Your DB is registered in the Dropbox location. The Calc file there looks at the data in the registered location - Dropbox folder. Now you COPY the folder to a new location. At the new location you use the Calc file & refresh the data. This data is being refreshed from the DB in the Dropbox folder & NOT the new location. Registered location.
In the case of the other answer, it was not having the database registered at all & then registered with the wrong name.
When using Base & an associated Calc file with Dropbox, each user of Dropbox must set their system to the same registered name as was originally used in the creation of the Calc file. The location on each system is important only for the correct access of data. It can be different on each system. The registered name, however, is the way the Calc file finds the DB.
In the case of the other answer, it was not having the database registered at all & then registered with the wrong name.
When using Base & an associated Calc file with Dropbox, each user of Dropbox must set their system to the same registered name as was originally used in the creation of the Calc file. The location on each system is important only for the correct access of data. It can be different on each system. The registered name, however, is the way the Calc file finds the DB.
I understand what you’re saying, but referring to: [Wizard] Create a new ‘split’ HSQL 2.x database
by DACM, end of page 2 and following the conversation about DB portability, is this then still limited regarding the Calc files ability to maintain their connection to the DB table(s)?
I’ll have John try first to register to the Drop Box location, then copy the folder and register there, leaving all else the same.
Thanks again.
I do believe I lost connection somewhere. Are you saying JohnD in the post I mentioned is the problem you are having? If so, his question did state renaming the .odb which is totally unnecessary. Also, if not going to work out of the Dropbox folder itself, then there is no need, and actually a waste of time, to first register it there. You would only be changing that same registration to point to a different location after the copy. Again, the registered name is what Calc needs.
Calc looks up the registered name, then uses the location associated with it to get the data from the database.
Not sure what you are getting at with the split reference. There are no page numbers and one page down for you can be different for everyone else depending upon many things. At any rate, the DB created with that is portable and requires no changes when moved around. But all this has nothing to do with Calc files linked to them through the registered name
I believe I found the split reference. If so, it simply states the .odb can be registered. This has nothing to do with the portability of the split DB. If the DB is moved, the internal macro keeps it working properly in its’ new location. But this internal macro does nothing in regard to any database registration.
Okay, I’ve got it. The DB portability is different than the Calc link, which needs to know where to look. Be nice if that could be linked up with the split portability, but… Next, yes, JohnD is my user. Since your above answer and explaining the linkage, I asked JohnD to make a new folder, copy the Dropbox folder to the new location, register that location and change nothing else. Everything works now. I think this problem is solved. Thank you again for all your guidance and support.
Really glad both questions are now answered. In actuality, the changing of the registration could probably be done within the same macro process as used in the split DB. However I would highly recommend against anyone doing this.