smells like bug 33173 but for Base

Sounds like a "start from scratch" task.

The problem described only arises when using an embedded database (HSQLDB, Firebird). The database is unpacked when the document is opened, the data reside in the local storage, where all changes are stored immediately. But they are only saved permanently when the document is closed or saved, by zipping the database. (It's not a question of "opening the main window", this must be open, because otherwise no forms ... can be open.) So there's no need to do anything in addition. The only possible problem is a crash before the document is saved/closed, then the changes are lost.
But tabs instead of separate windows would change nothing at this situation.
By the way: forms and reports are sort of separate Writer documents, I think it would be a difficult task, requiring crucial changes in the user interface, to present them in tabs.

Following Gerhard's recommendation and resolve this request as WF.

(In reply to Gerhard Weydt from comment #3)
> The problem described only arises when using an embedded database (HSQLDB,
> Firebird). The database is unpacked when the document is opened, the data
> reside in the local storage, where all changes are stored immediately. But
> they are only saved permanently when the document is closed or saved, by
> zipping the database. (It's not a question of "opening the main window",
> this must be open, because otherwise no forms ... can be open.) So there's
> no need to do anything in addition. The only possible problem is a crash
> before the document is saved/closed, then the changes are lost.
> But tabs instead of separate windows would change nothing at this situation.
> By the way: forms and reports are sort of separate Writer documents, I think
> it would be a difficult task, requiring crucial changes in the user
> interface, to present them in tabs.

Typical elitist programmer response. So the word "opened" was used instead of "show" or "bring to the forefront". A typical user probably won't even think of making that distinction.  Think of what the user might be suggesting instead of defining the words only by programmer-speak and then arguing based on that definition.  If unsure, ask.  So what that an example of use might only happen in an embedded database.  Most users used to MS Office are probably going to use that option instead of taking the trouble of setting up a server.  The point is that so many windows must be dealt with. So what if it's difficult to program.  The market doesn't care. Tabs are generally thought to present a much more usable interface. The clutter created by the multi-window approach is an archaic design and bugs 33173 & 37134 have been open for over a decade, so why just totally shut this idea down?

(In reply to David from comment #5)
> The clutter created by the multi-window approach is an archaic design
> and bugs 33173 & 37134 have been open for over a decade, so why just 
> totally shut this idea down?

Very unlikely that we find volunteers who revamp the application from ground. But neither Gerhard (Base user) nor me (UX guy) is a developer and becoming surprised is always nice. Removing UX for now as input has been given.

(In reply to David from comment #5)
It's not elitist to wish to have a problem described clearly. For even if you had said "show" or "bring to the forefront", that would be misleading, because that action does nothing to save the data. If you do not want to wait till the document is closed, you must -save- it. And that is a word every user is used to and will use! And I am not a programmer for LibreOffice, but only a user.
But you totally miss the main point: The difficulty with the embedded database is that the database itself is only saved when the document is closed, or if you explicitly save the document. One might argue about that, but saving the entire database after each change is probably a performance issue.
Using tabs will change nothing regarding this situation.

The main point I was trying to make was the clutter caused by the archaic multi-windowing that make the program harder to use. 

I'll re-phrase my comment to try avoid the extraneous noise that causes solution oriented people to think that it's just about the one particular example instead of being able to see the bigger picture.

"A tabbed Base application would be very beneficial.  Tables, queries, reports, and forms should all open as separate tabs instead of as windows.  MS Office and even Kexi have a much more user friendly approach."

Not everything that Microsoft introduces is really an advancement, think of the tiles in Windows 8 or the ribbons. What is newer isn't automatically better.
Whether tabs are better than separate windows is stuff for a lengthy discussion. I think that separate windows have the advantage of parallel viewing, which is sometimes useful. But I won't delve deeper into the subject now.

(In reply to Gerhard Weydt from comment #9)
> Not everything that Microsoft introduces is really an advancement, think of
> the tiles in Windows 8 or the ribbons. What is newer isn't automatically
> better.

I fully agree with that.  I hate ribbons. But I like options. 

> I think that separate windows have the advantage of parallel
> viewing, which is sometimes useful.

Then the tabs should be able to pulled out to make another window. There could also be an option to open in another window instead of another tab in the same window.

(In reply to David from comment #10)
> (In reply to Gerhard Weydt from comment #9)
> > Not everything that Microsoft introduces is really an advancement, think of
> > the tiles in Windows 8 or the ribbons. What is newer isn't automatically
> > better.
> 
> I fully agree with that.  I hate ribbons. But I like options. 
> 
> > I think that separate windows have the advantage of parallel
> > viewing, which is sometimes useful.
> 
> Then the tabs should be able to pulled out to make another window. There
> could also be an option to open in another window instead of another tab in
> the same window.


Which makes this a duplicate of bug 33173, along with the dev effort needed for MDI to manage multiple document "tabs" in a single app frame as for bug 33174

The hooks are there (look at the legacy Main Menu -> Windows menu), but the GUI framework requires new cross platform development.

Would need extensive UX design work to scope a new document framework--and a dev/devs with self-interest to implement, or a tender to fund the effort.

Frankly, I don't see that forthcoming from the community nor TDF authoring a funding tender to implement.

*** This bug has been marked as a duplicate of bug 33173 ***

(In reply to V Stuart Foote from comment #11)
> Which makes this a duplicate of bug 33173, along with the dev effort needed
> for MDI to manage multiple document "tabs" in a single app frame as for bug
> 33174

So are you saying that if division/section tabs ever got implemented within Writer that it would then be trivial for them to be implemented in Base?

(In reply to David from comment #13)
> (In reply to V Stuart Foote from comment #11)
> > Which makes this a duplicate of bug 33173, along with the dev effort needed
> > for MDI to manage multiple document "tabs" in a single app frame as for bug
> > 33174
> 
> So are you saying that if division/section tabs ever got implemented within
> Writer that it would then be trivial for them to be implemented in Base?

No, nothing trivial about it, but it is a prerequisite as the internal framework for a tabbed UI simply does not exist. Design and development more likely to be driven for Writer than for Base. But LibreOffice is monolithic--modules like Writer or Base are not really independent.  A tabbed MDI, or tabbed per section/panel/frame/page/slide rendering of an ODF document would use the same components.