[Issue 126404] Lost precision when copying table data
https://bz.apache.org/ooo/show_bug.cgi?id=126404 --- Comment #4 from Lars Jødal la...@sund.ku.dk --- Thanks, copying by selection and dragging gives the full precision. I still thinks the behaviour is somewhat misleading, since it does not tell that precision is lost. Replacing the standard copy (as shown) with two choices copy as shown and copy with full precision would make things more clear. But I take your point that it is not a bug, so instead of continuing here I will open a new Request for Enhancement with that suggestion. Thanks for the comments. Best regards, Lars J -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126411] New: bad import CSV files with text delimiters
https://bz.apache.org/ooo/show_bug.cgi?id=126411 Issue ID: 126411 Issue Type: DEFECT Summary: bad import CSV files with text delimiters Product: Calc Version: 4.1.0 Hardware: PC OS: Linux64 Status: UNCONFIRMED Severity: normal Priority: P5 Component: open-import Assignee: issues@openoffice.apache.org Reporter: uhrak.ser...@seznam.cz Opening CSV file with TAB as field delimiters and __ or _'_ as text delimiters lead to text delimiters are imported ( except first column ) too. Maybe I don't understand using of text delimiters, but Libre office (4.4.2) works properly. ( at least of this one ) example : 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126411] bad import CSV files with text delimiters
https://bz.apache.org/ooo/show_bug.cgi?id=126411 --- Comment #1 from setvit uhrak.ser...@seznam.cz --- hm .. version 4.0.1 for Window works also properly I have OpenSuse 13.1 and OpenOffice downloaded from official source ( link to sourceforge from openoffice.cz ) as version 4.1.1. but Calc show version 4.1.0 -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126412] New: Suggestion: Add Copy with full precision for Base tables
https://bz.apache.org/ooo/show_bug.cgi?id=126412 Issue ID: 126412 Issue Type: ENHANCEMENT Summary: Suggestion: Add Copy with full precision for Base tables Product: Base Version: 4.1.1 Hardware: All OS: Windows 7 Status: UNCONFIRMED Severity: normal Priority: P5 Component: code Assignee: issues@openoffice.apache.org Reporter: la...@sund.ku.dk Created attachment 84830 -- https://bz.apache.org/ooo/attachment.cgi?id=84830action=edit Sample database with high-precision data Brief description: In Base, copying a table or query with standard Copy, the data are only copied to the precision defined by the formatting, not the full precision. For instance, standard numeric format shows two decimal places, so a data entry containing the number 3.1415 will be copied as 3.14, resulting in loss of precision. It is suggested to replace the function Copy (in Base) by two functions: 1. Copy as shown: Same behaviour as current Copy. 2. Copy with full precision: Copy with full precision. More details: For seeing the behaviour, open the attached small database and copy Table1 into e.g. a Calc spreadsheet. The database contains the data MyTimestampMyDouble 01-01-2015 00:00:011.2345 01-01-2015 00:00:153.1415 but unless formatting is changed in Base before copying, Copy will only copy the timestamp to the level of full minutes, and the numbers will only be copied with two decimal places. (Changing formatting in Calc does not alter the data copied.) As discussed in the closed Issue 126404, this behaviour has both advantages and disadvantages: Advantage: Copying a full table can mean copying a huge amount of data to the clipboard. And copying data with full precision can give a confusing result on insert. Disadvantages: The user is not warned that Copy is a lossy copy. The behaviour is different from Copy in Calc, where data is copied in full precison regardless of formatting for showing. Finally, alternatives for copying with full precision may not be obvious to the user. Replacing Copy with Copy as shown will make more clear to the user that precision may be lost. And adding the choice Copy with full precision will make the alternative readily accessible, moving the responsibility for copying large tables to the user (where responsibility belongs). -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126258] javadoc fails to build
https://bz.apache.org/ooo/show_bug.cgi?id=126258 Alexander Pyhalov a...@rsu.ru changed: What|Removed |Added CC||a...@rsu.ru --- Comment #2 from Alexander Pyhalov a...@rsu.ru --- What version of GNU patch are you using? -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126409] JRE
https://bz.apache.org/ooo/show_bug.cgi?id=126409 oooforum ooofo...@free.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOT_AN_ISSUE CC||ooofo...@free.fr --- Comment #1 from oooforum ooofo...@free.fr --- AOO works fine with JRE. Did you read this page: http://www.openoffice.org/download/common/java.html ? Your bug report is being closed as NOT_AN_ISSUE due to a lack of information which is needed in order to accurately reproduce and confirm the problem. a) Provide details of your operating system. b) Attach a screenshot of Tools Options Java dialogbox Once this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126258] javadoc fails to build
https://bz.apache.org/ooo/show_bug.cgi?id=126258 --- Comment #3 from Alexander Pyhalov a...@rsu.ru --- Created attachment 84831 -- https://bz.apache.org/ooo/attachment.cgi?id=84831action=edit Don't patch files accross ../ The issue seems to be in GNU patch - it refuses to patch files outside of current directory: $ echo aa file1 $ echo bb file2 $ mkdir 1 $ diff -u file1 file2 1/patch $ cd 1 $ patch ../file1 patch Invalid file name ../file1 -- skipping patch And OO makes patch ../../unxsogi.pro/bin/odkcommon/docs/java/ref/index.html idl_ref_javadoc.patch which leads to Invalid file name ../../unxsogi.pro/bin/odkcommon/docs/java/ref/index.html -- skipping patch -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126258] javadoc fails to build
https://bz.apache.org/ooo/show_bug.cgi?id=126258 --- Comment #4 from hramr...@gmail.com --- Thanks for looking into this. I have GNU patch 2.7.5 I will try the attached patch later -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126411] bad import CSV files with text delimiters
https://bz.apache.org/ooo/show_bug.cgi?id=126411 --- Comment #2 from mroe mroe.nos...@gmx.net --- Please provide a sample CSV that the described behaviour can be reproduced with. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126414] New: missing -fPIC flag
https://bz.apache.org/ooo/show_bug.cgi?id=126414 Issue ID: 126414 Issue Type: DEFECT Summary: missing -fPIC flag Product: General Version: 4.2.0-dev Hardware: PC OS: Linux Status: UNCONFIRMED Severity: normal Priority: P5 Component: code Assignee: issues@openoffice.apache.org Reporter: hramr...@gmail.com When building openoffice the build fails due to something missing -fPIC flag. I am building on Linux AMD64. I added -fPIC to ARCH_FLAGS and the build seems to proceed much further. This needs further investigation as to where the flag is missing. The object where the build fails probably links to something that should have been built with -fPIC but is not. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126413] New: main/pyuno/source/module/pyuno_type.cxx fails to build due to local shadowing
https://bz.apache.org/ooo/show_bug.cgi?id=126413 Issue ID: 126413 Issue Type: DEFECT Summary: main/pyuno/source/module/pyuno_type.cxx fails to build due to local shadowing Product: General Version: 4.2.0-dev Hardware: All OS: Linux Status: UNCONFIRMED Severity: trivial Priority: P5 Component: code Assignee: issues@openoffice.apache.org Reporter: hramr...@gmail.com Created attachment 84832 -- https://bz.apache.org/ooo/attachment.cgi?id=84832action=edit patch renaming one of the local variables It seems this source is built with Werror and build fails due to shadowed local. Either way the fix is trivial. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126258] javadoc fails to build
https://bz.apache.org/ooo/show_bug.cgi?id=126258 --- Comment #5 from hramr...@gmail.com --- ok, it seems javadoc works with this patch. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126411] bad import CSV files with text delimiters
https://bz.apache.org/ooo/show_bug.cgi?id=126411 --- Comment #4 from setvit uhrak.ser...@seznam.cz --- Created attachment 84833 -- https://bz.apache.org/ooo/attachment.cgi?id=84833action=edit test file .. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126411] bad import CSV files with text delimiters
https://bz.apache.org/ooo/show_bug.cgi?id=126411 --- Comment #3 from setvit uhrak.ser...@seznam.cz --- sample you can obtain copy paste ot 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' 'Soubor' 'Datum' 'OD' 'Předmět' 'KOMU' what's wrong ? -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126411] bad import CSV files with text delimiters
https://bz.apache.org/ooo/show_bug.cgi?id=126411 mroe mroe.nos...@gmx.net changed: What|Removed |Added Resolution|--- |NOT_AN_ISSUE Status|UNCONFIRMED |RESOLVED --- Comment #5 from mroe mroe.nos...@gmx.net --- The delimiters in your testfile are TAB and Blanks together. Import the file with (*) Separated by [x] Tab [x] Space [x] Merge delimiters Text delimiter: ' -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126414] missing -fPIC flag
https://bz.apache.org/ooo/show_bug.cgi?id=126414 --- Comment #1 from hramr...@gmail.com --- ok, I have the exact error now: [ build LNK ] Library/libsvxcore.so /scratch/build/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: In function `FmXGridControl::createPeer(com::sun::star::uno::Referencecom::sun::star::awt::XToolkit const, com::sun::star::uno::Referencecom::sun::star::awt::XWindowPeer const)': fmgridif.cxx:(.text+0x68b2): undefined reference to `non-virtual thunk to WindowListenerMultiplexer::acquire()' /usr/bin/ld: /scratch/build/aoo/main/solver/420/unxlngx6.pro/workdir/CxxObject/svx/source/fmcomp/fmgridif.o: relocation R_X86_64_PC32 against undefined symbol `_ZThn48_N25WindowListenerMultiplexer7acquireEv' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status /scratch/build/aoo/main/solenv/gbuild/LinkTarget.mk:259: recipe for target '/scratch/build/aoo/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so' failed make: *** [/scratch/build/aoo/main/solver/420/unxlngx6.pro/workdir/LinkTarget/Library/libsvxcore.so] Error 1 dmake: Error code 2, while making 'all' So adding -fPIC to flags at random does not help. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126414] missing -fPIC flag
https://bz.apache.org/ooo/show_bug.cgi?id=126414 --- Comment #2 from hramr...@gmail.com --- hmm, to the best of my knowledge both fmgridif.c and the directory containing WindowListenerMultiplexer are built with -fPIC so the error is misleading at best. g++ (Debian 4.9.2-10) 4.9.2 -- You are receiving this mail because: You are the assignee for the issue.
[Issue 121703] Java (JRE)
https://bz.apache.org/ooo/show_bug.cgi?id=121703 Kay ksch...@apache.org changed: What|Removed |Added CC||ksch...@apache.org --- Comment #2 from Kay ksch...@apache.org --- (In reply to Ed Hume from comment #1) In order to use the Help file of OO, I must install JRE. Because I read The reg and similar mags, I know that JRE is a security hole. That means I will remove the condemned JRE as soon as I am done using Help. This is a phenomenal waste of time. Please make help something other than Java, which is a security hole. The Help system of Apache OpenOffice does not require Java. See this link for what areas/functions of OpenOffice require Java -- http://www.openoffice.org/download/common/java.html Java is used in many many environments and updates are issued on a regular basis. However, you can certainly disable the use of Java by Apache OpenOffice by going to Tools - Options - Java and unchecking Use Java Environment. -- You are receiving this mail because: You are on the CC list for the issue.
[Issue 126415] New: Access to d/l templates or Website Feedback produces same error msg.
https://bz.apache.org/ooo/show_bug.cgi?id=126415 Issue ID: 126415 Issue Type: DEFECT Summary: Access to d/l templates or Website Feedback produces same error msg. Product: Infrastructure Version: current Hardware: PC OS: Windows Server 2008 Status: UNCONFIRMED Severity: normal Priority: P5 Component: Downloads Assignee: issues@openoffice.apache.org Reporter: kaydinbo...@gmail.com Message reads: The connection was reset The connection to the server was reset while the page was loading. The site could be temporarily unavailable or too busy. Try again in a few moments. If you are unable to load any pages, check your computer's network connection. If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web. Site appears to be down at least since Friday the 17th (according to post on FB which I responded to). Is there a fix in the works? -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126300] Misspelling Üerschrift
https://bz.apache.org/ooo/show_bug.cgi?id=126300 Kay ksch...@apache.org changed: What|Removed |Added CC||ksch...@apache.org Target Milestone|--- |4.2.0 -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126416] New: Append table alias name Database Advanced Settings overriden by database metadata from JDBC data source
https://bz.apache.org/ooo/show_bug.cgi?id=126416 Issue ID: 126416 Issue Type: DEFECT Summary: Append table alias name Database Advanced Settings overriden by database metadata from JDBC data source Product: Base Version: 4.1.0 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: P5 Component: code Assignee: issues@openoffice.apache.org Reporter: ianbstu...@gmail.com Platform: Windows and Linux Libreoffice Versions from 4.0.x to 4.4.4.3 (and OpenOffice 4.1) Database connection - JDBC JDBC driver - Rocket Software U2 JDBC driver - previously IBM U2 JDBC driver Database server - UniVerse 11.2.4 (Windows, Linux and AIX) In BASE, the database advanced settings has an option to deselect the automatic aliasing of a table to itself as well as suppress the use of schema and catalog names in the formed SQL; EG SELECT * FROM CM AS CM is formed as SELECT * FROM CM (i.e without the alias) if the advanced settings option is unchecked. However it seems that metadata from the database server is able to override this setting or, alternatively, BASE detects something in the metadata sent by the database manager that results in the Alias option being enabled. The point at which the alias is added is when editing a query in the Designer View (not Edit in SQL View). Once the query is saved and then viewed in the Edit in SQL View editor, the alias is present. If the query is manually edited to remove the alias and the changes saved, then the SQL is correctly executed and the results returned as expected. However, as soon as the query is edited again in the Query Designer, the alias is added. The circumstances around this are that this has occurred since an upgrade of the Rocket Software UniVerse database manager where the database manager responds with a derived schema name of UVACCT for each table that is present. Prior to this, since OpenOffice 2, the same JDBC driver has worked with OpenOffice and LibreOffice. The logfiles that were generated from the JDBC driver whilst trying to debug the problem seem to highlight that the schema name is sent from the latest version of the database manager whereas previous versions do not have the schema name: EG: Part of log file from Version 11.2.4 of UniVerse with Schema of UVACCT which was logged when clicking on Tables to query available tables shows: 015-07-20 21:45:44.128 getString(1) returns '' 2015-07-20 21:45:44.129 getString(2) returns 'UVACCT' 2015-07-20 21:45:44.129 getString(3) returns 'CUSTOMER' 2015-07-20 21:45:44.133 getString(4) returns 'TABLE' 2015-07-20 21:45:44.133 UniJDBCProtocolU2Impl#nextRow:enter 2015-07-20 21:45:44.133 UniJDBCProtocolU2Impl#nextRow:leave-1 2015-07-20 21:45:44.134 mHasNextRow=true,mRowCount=2 2015-07-20 21:45:44.134 getString(1) returns '' 2015-07-20 21:45:44.134 getString(2) returns 'UVACCT' 2015-07-20 21:45:44.135 getString(3) returns 'CUSTOMER_ORDERS' 2015-07-20 21:45:44.135 getString(4) returns 'TABLE' 2015-07-20 21:45:44.135 UniJDBCProtocolU2Impl#nextRow:enter 2015-07-20 21:45:44.135 UniJDBCProtocolU2Impl#nextRow:leave-1 2015-07-20 21:45:44.135 mHasNextRow=true,mRowCount=3 2015-07-20 21:45:44.136 getString(1) returns '' 2015-07-20 21:45:44.136 getString(2) returns 'UVACCT' 2015-07-20 21:45:44.136 getString(3) returns 'PRODUCTS' 2015-07-20 21:45:44.137 getString(4) returns 'TABLE' 2015-07-20 21:45:44.137 UniJDBCProtocolU2Impl#nextRow:enter 2015-07-20 21:45:44.137 UniJDBCProtocolU2Impl#nextRow:leave-1 2015-07-20 21:45:44.137 mHasNextRow=true,mRowCount=4 2015-07-20 21:45:44.137 getString(1) returns '' 2015-07-20 21:45:44.137 getString(2) returns 'UVACCT' 2015-07-20 21:45:44.138 getString(3) returns 'STATES' 2015-07-20 21:45:44.138 getString(4) returns 'TABLE' Whereas a previous version of UniVerse 11.1.9 does not include the schema name: 2015-07-20 21:42:26.645 getString(1) returns '' 2015-07-20 21:42:26.645 getString(2) returns 'null' 2015-07-20 21:42:26.645 getString(3) returns 'CUSTOMER' 2015-07-20 21:42:26.645 getString(4) returns 'TABLE' 2015-07-20 21:42:26.645 UniJDBCProtocolU2Impl#nextRow:enter 2015-07-20 21:42:26.646 UniJDBCProtocolU2Impl#nextRow:leave-1 2015-07-20 21:42:26.646 mHasNextRow=true,mRowCount=2 2015-07-20 21:42:26.646 getString(1) returns '' 2015-07-20 21:42:26.646 getString(2) returns 'null' 2015-07-20 21:42:26.646 getString(3) returns 'PRODUCTS' 2015-07-20 21:42:26.646 getString(4) returns 'TABLE' 2015-07-20 21:42:26.647 UniJDBCProtocolU2Impl#nextRow:enter 2015-07-20 21:42:26.647 UniJDBCProtocolU2Impl#nextRow:leave-1 2015-07-20 21:42:26.647 mHasNextRow=true,mRowCount=3 2015-07-20 21:42:26.647 getString(1) returns '' 2015-07-20 21:42:26.647 getString(2) returns 'null' 2015-07-20 21:42:26.647 getString(3) returns 'STATES' 2015-07-20 21:42:26.647 getString(4) returns 'TABLE' 2015-07-20 21:42:26.647 UniJDBCProtocolU2Impl#nextRow:enter
