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
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,


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



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

Reply via email to