Frank Schönheit - Sun Microsystems Germany wrote:
Hi Fernand,

Also, in the scenario you described - two forms in the same database
document - there should be no need at all to change the active
connection of the already-loaded form. What do you want to achieve with
Frank, thanks for the reply, the goal is to use OO as a front end for manupulating data in external Databases and using OO-docs for the output . Problem is to have 1 Doc where users have only acces to the Forms or reports and keep them as far as possible away from the Databases tables. etc... .. A few weeks ago Drew Jensen Gives me the folowing advice

/Actually no you don't need 2 ODB files per user.

When a form, query definition, or report, is opened from a script (basic, python or JavaScript macro) you pass an instance of an open connection object. Normally this is the Active connection for the ODB file, but it does not have to be.

So, when the switchboard form loads it could create a second connection object. One that is connected to the MS SQLServer. Then when it loads the actual forms, etc., simply pass this second connection to the form.

Okay, so your form is in an .odb file, but it shall work on a connection
other than the one described by the database document.


Not sure I would call this a valid scenario :), since the assumption has
always been that a form embedded in a database document uses the
connection of this database document. The fact that the ActiveConnection
of this document is/must-be passed when loading the form is more of an
implementation detail, which normally should not be exposed to the API.
That's the reason why the more recent XDatabaseDocumentUI.loadComponent,
which is to be preferred over loadComponentFromURL, does not require the
active connection, but calculates it itself.

Anyway, since it seems loadComponentFromURL works (kind of), you can try
proceeding with it. However, for "re-connecting" a form to a new
connection, you will then need to close/re-open the form.

Your other question, about the sub forms not getting the active
connection, is harder. Without going into detail, I in fact think the
problem is the ActiveConnection used by the master form, which does not
belong to the embodying database document.

I can't think of a clean solution, but you could use an ugly workaround
like this: a) Remove the sub form from its parent b) change its
ActiveConnection property c) re-insert the sub form into its parent.

You might write an RFE requesting that the sub forms also use the
ActiveConnection passed while loading - finally, it could be considered
a bug that they currently don't. However, I would need more thinking
about the potential side effects of running an embedded form with an
alien connection. In the worst case, this could lead to the conclusion
that an ActiveConnection being different from the current connection of
the application window is forbidden at all ...
OK I can follow so far, but can you see a other strategie to keep the users away from Tables and other Datbase stuff where valid information like Paswords etc... are been stored ?
I was thinking on
- Stroring the forms in a WritterDoc ?
- open a OO-base-doc in a "hidden" way ?
- multi-user aces to one OO-base-doc (because one of the main problems is to distribute several Docs who are needed to run 1 application)

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to