Frank Schönheit - Sun Microsystems Germany wrote:
Hello Fernand,
I trye to pass a nwe connection to a already opened form document who
contains the macro a running from.
You cannot do this. ActiveConnection is only accepted when the form is
being loaded, after that, any change to it is vetoed, since the
assumption is that the form, living in the database document, always
uses the connection which the main database window already established.
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.
In fact this also allows you to use getIsolatedConnection (versus
getConnection) to create a connection that supports AUTO_COMMIT = False
if you need to - this allows you full control for committing or rolling
back updates as needed, for instance: multiple table updates as a single
business transaction. (This same trick works for an embedded HSQL
database by the way)
You will probably want to use two ODB files when you are building the
application, but a final step before pushing out to your users will be a
merge of the forms, query def's, reports into the single ODB file that
you would distribute.
Taking this one step then, you can have forms and or statements in
scripts that work with local (embedded HSQL) tables in the same ODB file
then - a nice way to offer user specific configuration or history data
in your database.
I hope that helps,
Drew
ps - sure looks like a ripe candidate for a sm/ all example project,
doesn't it.
Greetz and a Happy and Succes full New Year for you and your Familly
Fernand
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@api.openoffice.org
For additional commands, e-mail: dev-h...@api.openoffice.org
