Hi All;
Is it possible to configure autocommit in Data Studio SQL processor? I
can't find this feature anywhere... Kind of a show-stopper for us
using the tool productively. Any insight greatly appreciated

Pete H

On Jun 22, 8:43*am, peteh <phazz... (AT) intellicare (DOT) com> wrote:
I don't think this is possible (at least with 2.2.0.2). There's no
option to set this, and I don't believe that there is not a JDBC
property that you can set at the connection level to disable this. I
even tried setting autoCommit=false in the Optional Driver Properties
for a particular connection, but this doesn't work.

"Ian" <ianbjor (AT) mobileaudio (DOT) com> wrote

Thank God for this. Bless you, Data Studio developers.

Any decent DBA should know how to run a script with autocommit off. This
information should never be provided to developers or end users.

On Jun 22, 12:48*pm, "Mark A" <no... (AT) nowhere (DOT) com> wrote:
Hi all,

The autocommit capability is not JDBC property but is a method call
against the connection. Therefore, it cannot be specified in the
Optional Driver Properties.
There is an open requirement to support this in future releases of
Data Studio / Optim Development Studio.

On Jun 22, 12:48*pm, "Mark A" <no... (AT) nowhere (DOT) com> wrote:
Yes, of course. But the OP was asking if it's possbile to do it from
Data Studio.
Turning off autoCommit is a very valid request. Just because it's
powerful (and
can cause problems if not used with care) doesn't mean people
shouldn't be
able to use it.

"Ian" <ianbjor (AT) mobileaudio (DOT) com> wrote

It may be a valid request, but I would be willing to sacrfice the
convenience of not having it in the tool (would have to use command line)
for the benefit of keeping that feature out of the hands of my developers
and end-users, both of which use the tool for production databases. Even an
S lock that is not released causes a lot of problems. Just my opinion.

On Jun 23, 2:32*pm, "Mark A" <no... (AT) nowhere (DOT) com> wrote:
I think that's a bad idea, keeping it out of Data Studio for this
reason is simply security through obscurity. Any competent Java
developer can write and launch this in 5 minutes:

con.setAutoCommit(false);
stmt.executeUpdate("DELETE FROM STOCK WHERE ID=X");
Thread.sleep(100000);
worldCup.watch("Ghana", "Germany");
home.go();
work.return();
con.commit();

Protecting against this behaviour seems quite difficult. Maybe a
combination of WLM and NUM_LOG_SPAN might help, but I don't know the
golden bullet against this, besides whipping any offending
developers...

--
Frederik

"Frederik Engelen" <engelenfrederik (AT) gmail (DOT) com> wrote

I am actually not worried about updates, because they don't have authority
to update in production. But they do have authority to select in production,
and doing a select with auto-commit off will hold an S lock until it is
committed. That means no one else can update that row using the application
code.

I am also not worried about someone writing java code, I am more worried
about accidentally turning auto-commit off when browsing data. I don't think
these problems arise when someone intentionally does not commit (or at least
that is a different problem).

I would also like to see a "light" version of Data Studio that only
functions as a data query/update tool as opposed to a development or DBA
tool. Maybe this one could have the auto-commit always on (or not easily
changed).