Please give more information on your OOo version, linux distribution. From what
source you installed OOo? 
What database type this happens? Built-in or connected to external source?
What does you means under "database doesnot seem to be saved".
http://qa.openoffice.org/issue_handling/basic_rules.html#reproducibility

  

Running under KDE 4.3, OpenSuse 11.1, OOo Build 9319, i.e. 310m21.
I installed from the OpenSuse Openoffice repository. 
It's a built in database.
What happens:
I work on a database (let's say I add a report, or a query, or change a form).
Then I work on other documents too, which remain open. Since I don't trust the
autosave (I have weird results there, too, but that's another issue), I click
from time to time on "save all" in the file menu.
All documents are being saved, the appropriate icon for saving the document is
greyed out on all documents except the database. It remains unsaved, the save
icon is still in full colour, only when I click on it, it's being saved.

Hope that clarifies it. Ask if there are further questions.

Opensuse OOo version supported by other source, this is not a right place to
submit issues here with that version only for OOo downloaded from openoffice.org
site. Use https://bugzilla.novell.com/index.cgi. Closing.

Checked w/ DEV300m_60 and XP 

To reproduce:

Open any ODB file.
Create a new query definition, close the query designer but DO NOT save the odb
file.
Open a new OpenDocument Text document.
Edit the file so that the menu item File>Save All is available and execute it.
The Base file does not save.

OK - first I changed the sub-component on this issue to 'none' as it is common
to Base files not just MySQL connector.

Second - there are questions, IMO, as to what is the correct way to handle open,
modified, Base component windows - but I can't see how in this use case (only a
modified Base file main windows is open when Save All is executed) the Base file
should not be saved.

Confirming, assigning to developer, setting initial target and adding keyword
usability.

seems two of us looked at this at ~the same time.

r4zoli - please note that this is not a situation limited to a particular
distribution per my comments

congratulations, you found code piece no. 154.235 (approximately) which cares
for SFX-based documents only, and ignores Base.

fs->atjensen: when you target and assign an issue (thanks!), then please do not
forget to also confirm it. UNCONFIRMED issues have a much bigger chance to slip,
since they do not appear in usual queries and statistics.

fs->mba: /me thinks SfxApplication::MiscState_Impl/MiscExec_Impl should care for
the non-SFX documents, too. Which could turn out to be difficult, since it seems
there's no UNO API equivalent for SfxObjectShell::ExecuteSlot (each modified doc
is currently saved by executing a SID_SAVEDOC request), at least no
*synchronous* one. Which makes the proper handling for storing previously
unsaved documents, which are expected to open a "Save As" dialog, cumbersome.

I always wanted to move the code handling dispatches on a global ("application")
level outside of sfx2, not only because of bugs like this one, also because I
don't see sfx2 as something that should be involved in such global
functionality. I will take this issue as a good reason to move that forward. :-)

Reset assigne to the default "issues@openoffice.apache.org".