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 >> this? >> > 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. Hmm. 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 ... Ciao Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org For additional commands, e-mail: dev-h...@api.openoffice.org
