Drew,
you wrote
"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."
Any idea if this second connection also can been used for SQL
statements, ,how can i define the second connection tables in the SQL
statement ?
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)
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