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] Sat Oct 24 02:51:29 +0000 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: [email protected] For additional commands, e-mail: [email protected]
