|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | Can't edit tables, queries, forms, and reports | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base | Reporter: | Mechtilde <mechtilde> | ||||||
| Component: | code | Assignee: | marc.neumann | ||||||
| Status: | CLOSED FIXED | QA Contact: | issues@dba <issues> | ||||||
| Severity: | Trivial | ||||||||
| Priority: | P2 | CC: | frank.schoenheit, issues, mikhail.voytenko, rs | ||||||
| Version: | OOO300m4 | Keywords: | oooqa, regression, release_blocker | ||||||
| Target Milestone: | OOo 3.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||
| Developer Difficulty: | --- | ||||||||
| Attachments: |
|
||||||||
|
Description
Mechtilde
2008-08-31 09:25:27 UTC
@ clu Can you confirm it? I have no idea what happened It works in a new created database file but not in existed ones. I Can confirm on WinXP with new files all java related wizards working but all part of OOo base grayed out, and when opening existing .odb file, and if click on tables section, error msg came up (see attached screen shot).(java 1.6.07) Created attachment 56113 [details]
screenshot on winXP
set OS to all *** Issue 93296 has been marked as a duplicate of this issue. *** grabbing, targeting working on it fs->mav: This is a regression of your fix for issue 92735. When I revert the change in filter/source/config/cache which you did, then this bug here vanishes. The problem is that the type detection leaves an input stream in the media descriptor, which, since your fix, is read-only (before, it didn't exist, or it was writable, I do not know). Now when a database document is read from a media descriptor, it uses the stream it finds - and since this stream is read-only, the complete document is considered read-only, so all modifying operations on it are prevented in the UI. mav->fs: Yes, you are right. The database still uses the system file locking, so the stream that had been opened by the type-detection should be reopened after it was detected that it is a database ( only for OOo3.0, in OOo3.0.1 the database should be switched to the new file locking as well as we have discussed with Ocke ). I assume that you were going to send the bug to me. Created attachment 56130 [details]
The suggested fix for OOo3.0
mav->fs: Could you please take a look whether the workaround is acceptable from your point of view as a showstopper fix. fs->mav: The patch looks good, and is minimally invasive, which is important for 3.0. As we agreed on the phone, I think that later, the database document loader should be able to load writable documents from read-only streams, if there is a writable document URL. But that's nothing for 3.0 anymore, and perhaps implicitly done with the file locking changes you mentioned. Thanks for the quick patch! mav->fs: Thank you for the review. The fix with slight changes is commited to mav38 cws. . mav->msc: Please verify the issue. verified in CWS mav38 find more information about this CWS, like when it is available in the master builds, in EIS, the Environment Information System: http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=OOO300%2Fmav38 fs->mav: you were too generous in your fix: In revision 1.36.24.1 of dbloader.cxx, consider line 175 ff: if ( bStreamFromDescr && sURL.compareTo( ... ), 14 ) != COMPARE_EQUAL ); { ... } Note the superfluous semicolon at the end of the if-statement - it effectively means that the code inside the brackets, which is intended to be executed only if the if-statement evaluates to true, is executed unconditionally. I suppose it's not worth fixing this for OOO300, since it "just" means that the input-stream needs to be re-created when the document is actually loaded. But please fix it on the DEV300 branch. Also, another change which was not in the initial patch attached to this issue is the closing of the input stream. While this is a Good Thing (TM), please note that in DBA's code there's rarely such a thing as "catch( Exception& ) {}". This almost always has to be catch ( Exception& ) { DBG_UNHANDLED_EXCEPTION(); } , i.e. the error (and catching an exception here is an error) really should be reported in a non-product build, so it can at least be noticed and investigated, if it ever happens. (Oh, and one thing I in fact overlooked in the review of the attached patch is the minor thing that NamedValueCollection also has a ASCII version of "remove", so there's no need to create the ::rtl::OUString when calling it :) Sorry for coming up with those issues (which are not serious at all) that late. I just needed to add your patch to a CWS of mine, and thus stumbled upon those things ... The new issue 93461 is opened to fix the typo. verified in RC1 -< closed As I see today this issue come back since 3.0 final :-(( There is again the sting "read-only" in the title or it seems to be the wrong issue for that problem? I found the right one -> set to fixed . |