Issue 1334 - DB connection handling in Subforms
Summary: DB connection handling in Subforms
Status: CLOSED FIXED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 633
Hardware: PC Windows 2000
: P3 Trivial (vote)
Target Milestone: ---
Assignee: Frank Schönheit
QA Contact: issues@www
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-07-26 12:58 UTC by schulten
Modified: 2006-05-31 14:29 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description schulten 2001-07-26 12:58:00 UTC 
Subforms in design mode open additional connections to the underlying database 
and the connection is not always being closed after closing the form.

Proof: Create a subform in Adabas while logged on as a user who has only the 
right to have a single connection and try to enter the database in the subform 
properties.

With a multi-connection user, Adabas refuses the connection with "Too many 
users connected" after working with several subforms in design mode.

Closing the form doesn't help, you have to close the quick launch in order to 
get rid of the connections.
Comment 1 Frank Schönheit 2001-07-26 13:28:17 UTC 
For the first part (not reusing connections in sub forms): This issue is known 
(though it was not filed here before), and it has a rather high priority (at 
the moment :).

The second part (not freeing the connections when closing the form document):
Sure that the connection is really held and not only put back in the connection 
pool [1]?
Which means if you try to open a new document, and use the same data source in 
the property browser, does this succeed? If so, the connection is beeing re-
used from the pool, if not, it's not freed by the previous form document (and 
thus has not been put back into the pool).

A general remark:
Currently,t there is (besides connecting pooling) no concept for sharing 
connectings. In SO 5.2, every instance requesting a connection from a data 
source got a stub, which re-reouted all requests to a "real" connection, which 
was a singleton relative to the data source.
In OOo, every request for a connection opens a new "real" connection (which may 
come from the connection pool, but nevertheless has it's own physical 
connection to the external database).
This design is due to security reasons: With OOo beeing scriptable from any 
external host (provided that this is enabled in general), and no detailed 
security mechanisms to restrict access to selected components, it seems 
dangerous to allow a remote script client to access an already existent 
connection without authentication for this special connection (but only with 
authentication for the scripting).


[1] Though you can disable connection pooling at the UI, the core currently does
    not care for this setting - pooling is always enabled by default. This
    is fixed for a SRC638 version.
Comment 2 Frank Schönheit 2001-07-26 13:30:44 UTC 
I'll take care for this ...
Comment 3 Frank Schönheit 2001-08-09 13:04:05 UTC 
I fixed this for SRC638i:
Now sub forms share the connection with their parent forms, if 
possible. Form details, please see the respective feature mail in 
feature@dba.openoffice.org.
I also fixed the second part (connection not beeing disposed), which 
was a bug in the row set.
So in the next snapshot, this bug should be gone ....
Comment 4 Frank Schönheit 2001-12-11 11:05:05 UTC 
both issues are solved in the OO641B snapshot
Comment 5 Frank Schönheit 2001-12-11 11:06:01 UTC 
Dietrich,

can you (as the submitter) please confirm that the bug is fixed and close it?

Thanks
Frank
Comment 6 Frank Schönheit 2002-02-18 09:59:48 UTC 
closing this - no feedback from Dietrich, and already verified.
Comment 7 hans_werner67 2004-02-02 12:56:55 UTC 
change subcomponent to 'none'