Hi,

I reassign this issue to User Experience for evaluating.

Bye Marc

<explicit commit> is no option in 2.0Beta
Wonder, if this (essential) feature can be implemented.

Martin

this seems to be a bigger problem in OO.o 2.2 too
the basics are missing: user is unable to disable record-update on leaving last
field/column
but this is substantial to make use of the build-in makro-functions.

May be the issue-type should be changed from enhancement to defect, as at actual
looks to be a defect

Martin
  

Please do NOT change the version found in.  If this is needed in a particular
version or is a showstopper for a version then please change the target milestone.

James McKenzie

fs->mhatheoo: You're kidding. Code freeze for 2.4 was more than a week ago:
http://wiki.services.openoffice.org/wiki/OOoRelease24.

=> fs

just re-found this issue, and as code-freeze for OO.o 3.0 was,
I guess the function "explicit committ" will neither be  part of the
table-properties nor the general base-settings (like in HSQL), right? hmm.
Wouldn't be at least possible to enforce/clarify the settings within the
Form-properties?

Martin

just found, that the behaviour changed from Version OO2 to OO3:
While it had been possible, to set the cycle in OO2 to "cycle" it is now
impossible  to protect records from beeing changed just by using navigation-keys.

This is a harsh drawback behind the abilities of HSQL, and also behind seeing
the willing of the developers to make the base-part of OO being useful for
serious use.
You need to think about making "explicit commit" available as soon as possible. 

Martin

resetting target. Sorry, but 3.1.1 is absolutely ridiculous - we're in the RC
phase for this release, so nobody would approve an issue like this here anymore.

As for the cycle problem - I am not sure I get you here. Could you please
elaborate (in a new issue)? Thanks.

well Frank, I guess you did not mean rediculous, although, you are nearly right,
3.1.1 was a provocation, and I was right - I got your attention, but the real
challenge is to see it fixed in 3.2 - NOT in OO-later (OO-never?) !

The thing is simple
Give an option within forms to set cycle to NOT leave by any navigation-key
(incl. TAB) but to use the appropriate makro bound to a button only (which is at
least already available within the navigation-bar). The missing of this is a
killer for usability of OO-base since version 1, while the repair is simple -
that's all.

Martin

3.2 is also illusionary (though not as ridiculous as 3.1.1 - I meant what I said
here :) ). Branch-off date for this release is pretty soon, and even if I were
as convinced as you that this is absolutely necessary, we wouldn't easily be
able to hit this date. (You know, there'd be a file format change and such
things associated with this ...)

That said, I am not remotely as convinced as you that this is a necessary and
highly useful feature, justifying the resources needed to implement it.

>fs

well, I see that the changes to HSQL 1.9  will cause some problems, although as
I understood these changes seems to be more under the hood and not that much
relevant to applications calling HSQL-functions by skripts. However, I am not
that much a developer to judge about that.

But nevertheless I can not really accept your responds. I have in mind, that an
OO-form should not be leavable by using any auto-commit-function, but only by
using an explicit function. Of course this needs to think about locking etc, but
this is related to OO.o only, as it is part of the form-properties, not related
to HSQL.

Example: Supposed you will have a record-copy-function sometimes (choose a
record - dublicate it to temp - edit it - and start the base-table-updated when
all is done from user-side) you will face the same problems. So you have the
following options: Give up and wait until this feature is implemented in HSQL
(which may not come!), implement it as an OO-base feature, or trust, that users
will find a makro-solution.

You understand, that it is not about your ambitions to solve this matter, it is
about the competence within the community aswell as the willing of your employee
to spend something on that. Thats all.

Martin
 

I don't understand the connection to HSQL which you draw here, sorry.

All in all, reading over that issue again, I am not sure I really understand
what you wish.

Perhaps we have a terminology problem here: With "commit", do you mean
- the "back-end feature" of committing, i.e. as it is used for databases in
  general: You can set make changes to the data, but unless you call some
  explicit "commit", this is not persistent
OR
- the "front-end feature" of committing the content of the form controls to the
  current database

Part of my confusion might result from /me thinking all the time that you meant
the latter (since this is also called "commit", at least under the hood), but
meanwhile I think you mean the former.

Can you clarify, please?

==>fs

hm

I did not understood what two different items you are looking for,
as the HSQL has no "primanota-concept" for delayed transactions. Isn't it, that
the HSQLDB (back-end - if you wish) could be set to auto-execution of statements
or not? COMMIT is one of those. so, at actual

1. You changed the behavior of forms
2. the method setautocommit is still unused 

While there had been a chance to substitute the lack of the missing 2. by using
a working cycle-function within forms, even that isn't working anymore. I am
sure you knew that, so I wonder about your question. However, as the HSQL is
working in OOo like in a black box - everything is under the hood - you may
start to make the properties available - or even give reliable infos how to
hack/set it up manually.

Note - substantial for dealing with OOo and data: when it is not possible to set
the table-properties so that data will be updated by a manually controlled
(explicit!) commit only, in forms aswell as in tableview - at least for me, OOo
will never ever get the chance to be used for anything serious.  


Martin

P.S.:
look at the OP - this issue will make the 5-years-anniversery these days.

> 1. You changed the behavior of forms

Huh?

> 2. the method setautocommit is still unused 
>
> While there had been a chance to substitute the lack of the missing 2. by
> using a working cycle-function within forms, even that isn't working anymore.

That is exactly what I asked you (above) to elaborate - the cycle function works
perfectly, as far as I know, so I do not remotely know what you refer to here.

> I am sure you knew that

No, I didn't, and still don't know.



Still, I do not understand the work flow you have in mind. Currently, it is as
follows:
1. When you enter data into a control, and leave this control, this data
   is transferred ("committed") to the result set row. Still, this happens
   "client-side", the result row is not yet updated to the database.
2. When you move to another record, then all modifications to the current
   result row are updated ("committed") to the database, effectively executing
   an "UPDATE" SQL statement.
2a. Since all our connections are set to AutoCommit=TRUE, this means that
    after that statement has been executed, the new data is immediately in the
    database (modulo some write caches, if you're working with the embedded
    HSQLDB).
2b. Moving to another record is (by default) also done when you TAB through
    your controls. This can be prevented by setting the "Cycle" property of
    the form to "Active Record". (This is what you claimed doesn't work
    anymore, but I don't see any problem here.)
3. Explicitly pressing the "Save Record" button also updates ("commits") the
   data to the database, issuing the very same UPDATE statement.

In which of those steps, the behavior you expect would differ?

well Frank

I did it explain, and you returned that you could catch the point, what else can
I do. 
Autocommitting is a  nasty nonsense-feature, invented by developers, but useless
in  allday-work. please catch it: Every form or table, that holds data for edit
or by new entry, that can be left unintentionally - by TAB or Nav-Keys - and
updates data anyway, is worthless for the user! Bind the function to a button, a
function-key or an icon, but do not miss to make it available. It is a problem,
that you do not have a Database-Parameter-Table for each ODB, where one can
store such things, so you need to put it in the Base-Option-dialog. No good
place, but the onlyone, if you want to make SetAutoCommit a switchable option.  

And, bytheway, you just explained, why devolopment of the base-part of OOo is
not evoling: HSQL is not intended to keep/hold data for updating a back-end
until you leave a form. I do not know where you got that, it must be an
OOo-invention, it has nothing to do with HSQL. However, for a database ment for
the public it is a useless concept. Everything must be done loud and clear
(explicit commit !) and immidiatly - otherwise no subform/lookup-concept will
seriously ever work with OOo. And I have thought you wanted make that possible.

Martin


P.S.:
You change the cycle-behaviour anyway: move from last to first field in
TAB-order will update - without to ask.

> I did it explain, and you returned that you could catch the point, what else
> can I do.

Answering my questions is a good starting point, as you did with explaining that
cycling within the same record still commits the data. I was not aware of the
fact that it does so, and I tend to agree that this is a bug. If you submit it,
it has chances of being fixed. If you moan about in in a somewhat unrelated
issue like this here, it hasn't.

> Wvery form or table, that holds data for edit or by new entry, that can be
> left unintentionally - by TAB or Nav-Keys - and updates data anyway, is
> worthless for the user!

I disagree. That alone does not mean that the functionality you describe/request
is useless.

Again, let me ask you to describe the work flow you have in mind in more detail.
The most "simple" solution to your problem, as I understand it, is to raise a
dialog at every point where today a silent "commit to database" happens, asking
the user for confirmation. There could be other (better?) solutions to this,
that's why (and to better understand what you request) I asked how the work flow
looks in your imagination, sadly without a concrete response.

> HSQL is not intended to keep/hold data for updating a back-end until you
> leave a form.

Huh? Where did I claim this? Sorry, but your complete last paragraph does not
make any sense to me.

==>fs

you wrote: 
Since all our connections are set to AutoCommit=TRUE, this means that
after that statement has been executed, the new data is immediately in the
database (modulo some write caches, if you're working with the embedded HSQLDB)
(...)

This BOTH is what I ment, and for everybody not knowing the story here is the link:
http://hsqldb.org/doc/guide/ch09.html#set_autocommit-section
so, AutoCommit is an option to the tables, which must-be-used, and can not be
left in default state.
And, EVEN when using HSQL as a memory-only DBMS, "statements" should not be
written to any cache, but need to be executed immidiatly (btw.: I am no friend
of memory-only DBMS). 
I you want to make a ROLL-BACK possible, this needs to be done on base of
transaction-protocol, not  on base of a "do-nothing-until" ... whatsoever.


You asked for a workflow? What do you expect, tricky stuff? I just look at a
records and walk record-wise through a table/a view? nothing with marcos etc,
just using ordinary functions.

so: quote again:
(..)
dialog at every point where today a silent "commit to database" happens, asking
the user for confirmation. 
(..)
yes, of course, this is what we are talking about
(note: the smart version of dealing with things like this is, not to do anything
and to stay in the TAB-cycle until COMMIT is given, or to pop-up the dialog,
when record is changed but shall be left by ESC or NAV-Keys.)

(..) 
There could be other (better?) solutions to this 
(..)
really? which ones?

you do not like moaning? Sorry, here you have it again. Since years OOo stumbles
over smart features (here: autoCommit), whereas the basics (explicit commit) are
missing. Okay, this can happen, system-developement and programming are
different jobs, but it should not be a big problem to do the programming, when
things are clear. You complain about moaning? I think, things would become much
easier, when I charge you for good advice.


Martin

> This BOTH is what I ment, and for everybody not knowing the story here is
> the link:
> http://hsqldb.org/doc/guide/ch09.html#set_autocommit-section
> so, AutoCommit is an option to the tables,

No, it is a per-connection option

> which must-be-used, and can not be left in default state.

It is not left in default state, it is intentionally set to TRUE, to reach the
current behavior, which works as designed. Before you jump onto this, let me
repeat two things:
a) "works as designed" doesn't mean your request isn't feasible (though I
   strongly disagree to your "it's useless currently" statement)
b) You mix up different and completely independent terms of "commit". I
   explained the two different meanings above, and won't bother repeating
   it here. Just let me say that what you cited refers to the first meaning,
   and what you really request in the issue refers to the second.

> And, EVEN when using HSQL as a memory-only DBMS, "statements" should not
> be written to any cache, but need to be executed immidiatly

You might want to read the HSQLDB document about caching (I'm sure there is
some, around SET WRITE DELAY). Anyway, that's an unrelated topic.

> You asked for a workflow? What do you expect, tricky stuff?

A "this is what I do, this is what happens, this is what I would expect to
happen" text, like it is essential for good bug reports. Please read
http://qa.openoffice.org/issue_handling/basic_rules.html#reproducibility for an
explanation why it is *very* important to be sure that all involved parties have
the same understanding of the matter. Written prose, in particular written by
non-native speakers (no offense intended, this applies to me as well) has way
too much potential for misunderstandings.

> (..) 
> There could be other (better?) solutions to this 
> (..)
> really? which ones?

Nice example of the above :) My "could" meant "Perhaps you imagine other
solutions here than I do", not "I can imagine other solutions."

> you do not like moaning? Sorry, here you have it again.

Sigh. This adds just noise to the issue, which makes it increasingly difficult
to properly handle it, and find a common understanding.

So, reading this here and your other issue 105782, I think we have the mentioned
common understanding now: In all situations where OOo silently commits the
content of the current record to the database, you want it to (optionally) ask
the user for confirmation.

I don't agree to the importance you imposed on that feature, but I agree that it
can be useful in general.

Grabbing issue, having BH owning it does not make sense at all.

Hi Frank, but it makes sense to make a query on "bh" and change the owner
appropriatly; it should especially be easy for data base issues. :) Thanks.

Though autocommit=true is a connection property, it would be a nice to have
feature to implement this in the GUI as a form property "autocommit" in the
properties dialog, which then changes the mode of the connection the form is
bound to.
If set to false, a commit should only be executed by pressing the save button in
the navigation bar resp. a control push button of type "Save".

@mhatheoo: Why only talking about HSQL? This per-connection option is IMO valid
for all connection types.

Would be possible, though some questions would need to be clarified (nothing
impossible, though). First, connections are shared: Everything started from
within a database document uses the same connection, so tampering with
AutoCommit in one form would affect all other forms and table data views and the
like, or AutoCommit=true would imply the form using an isolated connection
(which would be possible, though potentially expensive). Second, a point in time
would need to be found when the changes are to be committed. "When closing the
form" would be an option, if the form really has an isolated connection.

==> eberlein

yes of course, explicit commit is substantial to all DBMS. But HSQL would be a
good point to start with, as it is the default DBMS to OO.o, right?

You said " Though autocommit=true is a connection property ..."
But that is the point!
We have - at least - THREE parts in the game: The HSQL-engine, the HSQL-build-in
java-class for connect to it, and the OO.o-own GUI using the connetion-class.
The problem is, that in no sufficient manner the OO.o is dealing with the
properties-file, everything seems to be left in default state. And it looks,
that OO.o is also setting foreign property-files back to default-state. This for
example might be the reason, why I can not use the HSQL-based BORG-calendar as
datasource, having it opend in OO.o will make it crash in BORG.
Why you read this in here? I understand this missing feature - or the missing
ability to pass and save a "set autocommit=false" - as an indicator for a
mislead concept. Otherwise it would have been available since years. I treat my
complaint  about this missing feature not as a request for an enhancement, but
simply as pointing to a defect - by design.

==> fs

Well, I am not sure, whether you are trying kidding me. 
Spending hours and seeing than, that your responds reads like discrediting my
complaint, that isn't really fun. So some more accurracy will help, may be both
of us, if you want to. Things like "This adds just noise ..." are really
unwanted. Note, we are not talking about my skills, it's about yours ...

Back to the story:
As there is no way to directly connect to data-tables in HSQL, it is clear, that
autocommit is part of the connection-properties. Where is your problem to
understand this? You just need to make use of this method.

You introduced something strange, that is not really part of HSQLanyway,  in
destinguishing between:
- the transaction that the FORM starts when a record is closed/changed/entered
- the update/writing of the HSQL-engine into the table
it looks that is the problem: COMMIT in here had always been ment as the result,
the updated records within the tables, safely stored even when now the current
goes off. 
Holding data in memory for later transaction is no commit. Seeing record-changes
in the front-end, wheras they are not really updated in the back-end-files is no
commit either. That is an undefined state of the DBMS and should never happen.

The solution OO.o invented was, that everything with the tables can be managed
on OO-GUI-side. That is not a workable idea. However, one can try to do so.
 
But reading your "I don't agree to the importance you imposed on that feature,
but I agree that it can be useful in general" is an rather absurd interpretation
on how to deal with data. Note: You disabled one of the basic features within
the HSQLDB by intention, overruling, what the developers of the HSQL had
suggested a basic feature should be? Wow, smart. But no good, it must be re-enabled.

You know all you need to repair this. We'll see, whether you can do so.

Martin

P.S.:
Hope you did not ment what you wrote in the last message:
"I don't want to update, as I do not know how to solve the side-effects with
other open forms"? Please mind the order: First comes the data, than how the
DBMS deals with it.

@mahatheoo -Before getting to the real question here:

"Autocommitting is a  nasty nonsense-feature, invented by developers,"

Sorry but that statement is just wrong. Users, in certain contexts, expect it
and demand it - back office 10 key operations is a prime example, make them hit
one more key then absolutely necessary and your application is out the door and
in the dumper. (mistakes in keying are caught during a reconciliation step,
almost always, not during data input as it has proven to reduce overall
efficiency when keying in large numbers of transactions...but that is old school
stuff I suppose and often involves use of temp tables during data entry)


 "everything seems to be left in default state. And it looks,
that OO.o is also setting foreign property-files back to default-state. This for
example might be the reason, why I can not use the HSQL-based BORG-calendar as
datasource, having it opend in OO.o will make it crash in BORG."

Well, I had to give that a try after reading the issue here. Using OO.o 3.1.1 or
3.2m_1 (dev build) and connecting to the BORG database using
jdbc:hsqldb:file:<path>\BORG_ allows me to have both applications open
simultaneously (using Ubuntu 9.04 here). I can enter data via SQL commands from
Base but not via the GUI, I can build forms but only against queries, not
tables, same with Reports and a few other oddities, but no crashes on either
side. The data entered in either is not available to the other applications
however until the connections have been closed and opened again. (I note that
BORG now ships with a MySQL schema as an option) However, as I am not a BORG
*smile*, user, If you want to pursue this I would be happy to work with you via
an OO.o mailing list or web forum or the BORG mailing list, where I see you
opened a thread on just this issue. We might find solutions...might be fun
actually, and perhaps we could contribute back to the BORG project any changes
needed to make it fully compatible with Base (OO.o).

---back to the question in this issue--

How should Base handle auto-commit? Should it be the default?

Any chance we could have this conversation on the mailing list versus the issue,
one, I hate this text box...and two - maybe we invite the UX team to get involved...

==> atj

Hello Drew.

well, you are right, users may have requested the One-Key-less-procedures. It
depends, whether the onwer of the application is accepting it or not. No serious
appliaction is using autocommit, as an unintentional commit will make roll-back
neccessary that just causes pain to everybody, like multi-use environments,
key-generating transactions etc. Think about bookkeeping, invoicing etc.

However, you can judge yourself. Think about developing a DBMS, and think about
which feature can miss, whithout the need to prevent the application from
dataloss by unintentional commit, the keyhit-saving autocommit or the
one-key-more(which in not really the case). A roll-back is needed for both, but
in case of explicit commit the user knows why. So it depends on what comes first
in regard to data-integrity, auto or not auto. 

regarding the BORG-calendar. It is not my favorite application, the calendar has
some disadvantages, however, it has a good potential. And it is not the only
HSQL-based application, that can be useful together with OO.o. It is a cann't
be, that OO.o is not save for use external HSQL-Sources. I am not that much
familiar with stuff like that, but I tried to find the differences, and it looks
as OO.o is tempering the properties-file and the storage-type in there. BORG
hold tables in memory, OO.o hold it cached. So Borg has data available
immidiatly. OO.o not, but could make the data immidiatly available, for example
by clearing cache  when waiting on next input, or just stop this rather useless
feature. that would not have any impact on performance in single-user or
SOHO-environments, but is the much saver concept. 
Well, I think you got what I ment, keep it safe, keep it simple, just the
old-school-way.

Martin

P.S.:
No, I do not want to discuss this in UX. I hate mailing-lists, stuff needs to be
centralized, thats enough. And I do not see the neccessity for this issue. This
is a defect-by-design, but nevertheless a defect.

Reset the assignee to the default "issues@openoffice.apache.org".