This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When rightclicking a cell in a resultset that is of type text/longvarchar, and selecting the "CopyCellValue", the copied text is not the value of the field, but instead it is simply a tostring of a nb object: "org.netbeans.modules.db.dataview.util.FileBackedClob@3c989792" On another note, when the cell in the resultset is doubleclicked, and the "Edit data" is selected, the correct text is shown in an editor. However, this editor is so small, and can not be resized, so it is almost unuseable. It would be nice if it could be resized.
Created attachment 125104 [details] proposed patch v1
The attached patch does the following: - Add a method to create a string representation of the content (in the case of BLOBs + CLOBs the size is limited to 1 million bytes or 1 million chars. if the limit is exceeded the current behaviour kicks in as fallback) - Correct TSV Export to quote cell value if needed For the second item, akobberup, that you mention, please file a separate bug (actually an enhancement request, as .
Thank you - I will do that.
(In reply to comment #2) > The attached patch does the following: > - Add a method to create a string representation of the content (in the case of > BLOBs + CLOBs the size is limited to 1 million bytes or 1 million chars. if the > limit is exceeded the current behaviour kicks in as fallback) > - Correct TSV Export to quote cell value if needed Matthias, it seems that you've attached another file (Base64.java). Can you please check it? Thanks.
Created attachment 125247 [details] proposed patch v2 Jaroslav your right. Not sure how that happened - seems I screwed up creating the diff. The file is intended to be there. This gave me the chance for another round. My first patch did not consider, that the JTable itself also handles copies ... I moved the TSV Export down into ResultSetJXTable, so that the case is also correctly handled in other output/input tables and I defined a TransferHandler there, that adds TSV handling also in the copy action if the table. The Base64.java file is still part of the patch as I use it to do a base64 encoding of the binary blob data.
Created attachment 125293 [details] proposed patch v3 This is another iteration. I removed Base64.java again, utilizing a sql compatible hexadecimal encoding already present in the module: BinaryToStringConverter. Additionally neek commented in bug #215973, that "Show SQL script for INSERT" is also affected => fixed in interation 3.
Applied as http://hg.netbeans.org/core-main/rev/d3a4a5f09ecd Updated in http://hg.netbeans.org/core-main/rev/def734307597 I think that 1 MB limit is pretty good. If there are any problems with it, we can change it. I changed String.replace to String.replaceAll in some places (doubling quotes or apostrophes), I hope it is correct. I've also added check for null and empty values, which will be copied to clipboard as a pair of double quotes (""). I hope it will be better visible as we have non-printable separator (tab). Is it OK? SQL statement generator can now create INSERT commands with very long string literals from CLOB or BLOB fields. I think there is some limit on string literal length in some databases (e.g. 4000 characters for Oracle). Maybe there should be also some limit, or a warning if the string (or binary data) is too long. For now, we can just wait for the feedback. Thank you very much again, Matthias!
(In reply to comment #7) > Applied as http://hg.netbeans.org/core-main/rev/d3a4a5f09ecd > Updated in http://hg.netbeans.org/core-main/rev/def734307597 Thanks! > I changed String.replace to String.replaceAll in some places (doubling quotes > or apostrophes), I hope it is correct. I would change that back to plain replace. In this case there is no difference between replace("'", "''") and replaceAll("'", "''"), because the string in the replaceAll case is interpreted as a regexp which represents a plain string. The difference is, that in the replaceAll case the regexp engine as to be fired up first. Beware this is deduced from the String.class documentation :-) > I've also added check for null and empty values, which will be copied to > clipboard as a pair of double quotes (""). I hope it will be better visible as > we have non-printable separator (tab). > Is it OK? Good idea! The null case should not be present, but the empty string is - it's not necessary, but nice for the eye! BTW: Thanks for adapting quoteIfNecessary to include the quoting char to enforce quoting. > SQL statement generator can now create INSERT commands with very long string > literals from CLOB or BLOB fields. I think there is some limit on string > literal length in some databases (e.g. 4000 characters for Oracle). > Maybe there should be also some limit, or a warning if the string (or binary > data) is too long. > For now, we can just wait for the feedback. I agree.
(In reply to comment #8) > > I changed String.replace to String.replaceAll in some places (doubling > > quotes or apostrophes), I hope it is correct. > I would change that back to plain replace. In this case there is no > difference between replace("'", "''") and replaceAll("'", "''"), because > the string in the replaceAll case is interpreted as a regexp which > represents a plain string. The difference is, that in the replaceAll case > the regexp engine as to be fired up first. > > Beware this is deduced from the String.class documentation :-) I'm sorry, I'm dumb. Fixed in http://hg.netbeans.org/core-main/rev/d04c8dcd91eb Thank you for correction!
Integrated into 'main-golden', will be available in build *201210070002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d3a4a5f09ecd User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #219117: Copy cell value do not work if datatype is a longvarchar/text