I regret that I don't seem to have  a  visible "attach"ment"  button, so the
carefully cut down example does not appear here at this time.

The use case is as follows. Given an existingg spreaddsheet with fairly
elaborrate costing calculations, a writer document was constructed for a related
family of proposals. Then the "new database" button  was selected, I choose
"existing database" type spreadsheet and then  dragged the appropriate fields to
the right spots in the writer document.  This was on a Macintosh running
NeoOffice 2.1 patch3, but I replicated the results with OpenOffice 2..1 as well.
All was right with the world. However, iI work in a distributed group. So prior
to "releasing" this lashup upon my group, I  transferred the files over to a
Solaris x86 sysetem  (running SXDE, not that it seems  to matter much) and
StarOffice 8 update 5). On  the solaris  side, the database needed registration
(hence the title, aboluute paths considered harmful, relative pathing would have
been far handier) after registration,  StarOffice8 PU5 *crashes* upon any and
all attempts to  work witth the database file. Hence I have labeled this a defect.

I also moved the files to a Ubuntu 6.10  system  which has OOO 2.0.4 i
installed. While it doesn't crash, just registering the database  fails  to
provide any useful value, as any attempt to access the database fails silently.

I think there are two issues here:

1) Due to the lack of relative addressing, absolute adddresses are  put into the
database definition. This is unhelpful.  I defer to the  maintainers judgement
whether that should be a separate RFE (I will happily enter itt if so desired).

2) Given that the absolute paths don't exist on the  "client" systemss it would
appear that there is both a lack of appropriate error checking /handling and a
missing facility to fix "incorrect" paths.  since this results in crashing on at
least one platform, I think it is safe to call this a defect.

As the issues are very tightly connected, I have filed them togehther.