[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User atjensen changed the following: What|Old value |New value CC|'eberlein'|'atjensen,eberlein' --- Additional comments from atjen...@openoffice.org Sat Oct 24 18:41:34 + 2009 --- @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... - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from mhath...@openoffice.org Sun Oct 25 00:11:36 + 2009 --- == 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from f...@openoffice.org Fri Oct 23 11:03:32 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User fs changed the following: What|Old value |New value Assigned to|bh|fs --- Additional comments from f...@openoffice.org Fri Oct 23 11:05:52 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from b...@openoffice.org Fri Oct 23 11:18:14 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from eberl...@openoffice.org Fri Oct 23 13:49:03 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from f...@openoffice.org Fri Oct 23 13:59:22 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from mhath...@openoffice.org Sat Oct 24 02:51:29 + 2009 --- == 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from mhath...@openoffice.org Sat Oct 10 14:49:37 + 2009 --- ==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 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from f...@openoffice.org Fri Oct 9 09:39:42 + 2009 --- 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? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from mhath...@openoffice.org Fri Oct 9 14:42:33 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from f...@openoffice.org Fri Oct 9 15:29:29 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from f...@openoffice.org Thu Oct 8 13:13:02 + 2009 --- 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? - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from mhath...@openoffice.org Thu Oct 8 18:52:54 + 2009 --- ==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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from mhath...@openoffice.org Wed Aug 19 13:53:16 + 2009 --- 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 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User fs changed the following: What|Old value |New value Target milestone|OOo 3.1.1 |OOo Later --- Additional comments from f...@openoffice.org Tue Aug 18 07:20:29 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from mhath...@openoffice.org Tue Aug 18 15:33:26 + 2009 --- 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 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from f...@openoffice.org Tue Aug 18 21:05:29 + 2009 --- 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. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User mhatheoo changed the following: What|Old value |New value Target milestone|OOo Later |OOo 3.1.1 --- Additional comments from mhath...@openoffice.org Mon Aug 17 22:41:43 + 2009 --- 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 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User eberlein changed the following: What|Old value |New value CC|''|'eberlein' - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: issues-unsubscr...@dba.openoffice.org For additional commands, e-mail: issues-h...@dba.openoffice.org - To unsubscribe, e-mail: allbugs-unsubscr...@openoffice.org For additional commands, e-mail: allbugs-h...@openoffice.org
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 --- Additional comments from [EMAIL PROTECTED] Tue Jun 10 20:09:50 + 2008 --- = 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 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User fs changed the following: What|Old value |New value Target milestone|OOo 2.4 |OOo Later --- Additional comments from [EMAIL PROTECTED] Fri Jan 25 20:14:48 + 2008 --- fs-mhatheoo: You're kidding. Code freeze for 2.4 was more than a week ago: http://wiki.services.openoffice.org/wiki/OOoRelease24. - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User mhatheoo changed the following: What|Old value |New value Target milestone|--- |OOo 2.4 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User jjmckenzie changed the following: What|Old value |New value Version|OOo 2.2 |OOo 1.1.4 --- Additional comments from [EMAIL PROTECTED] Tue Feb 20 01:21:26 + 2007 --- 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 - Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dba-issues] [Issue 36231] forms: option explicit co mmit is missing
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=36231 User mhatheoo changed the following: What|Old value |New value Version|1.0.0 |OOo 2.2 --- Additional comments from [EMAIL PROTECTED] Tue Feb 13 14:44:14 + 2007 --- 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 reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]