Hallo Drew,
After a few weeks strugling to try "simply pass this second connection
to the form." if finaly comme back to you .
Once a form is opened with a connection it seems to be imposible to
"pass" a new connection . Frank S. replyed:
"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."
Am I right posing that I must open all my forms with "OpenFromURL" and then
passing this connection to the embedded subforms ? or have you a other trick ?
Greetz and a succes full and Happy New Year to you and your Family
Fernand
Drew Jensen wrote:
Fernand Vanrie wrote:
Hallo Drew
Thanks for you extended reply. We are developing a Implemenation who
is based on Micrsoft SQL tables and views and or ODB file is
connected with ODBC. Due to the fatc that it are relative small
data-tables everyting go smootly. I learned a lot having a deeper
look at the Switcboard macro's . SO mi idea is to have a OO native
Basedoc for every user and tnen using the Switchboard extension to
keep the ODBC based tables away from or users.
We have still to test this approach, just wondering if we need for
every user 2 Basedocs (a native and a ODBC conected) or if we can
have only 2 multiused network based Basedocs ?
Hello Fernand,
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 small example project,
doesn't it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org
For additional commands, e-mail: dev-h...@dba.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org
For additional commands, e-mail: dev-h...@dba.openoffice.org
