Issue Details (XML | Word | Printable)

Key: CORE-915
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Adriano dos Santos Fernandes
Reporter: zaher dirkey
Votes: 8
Watchers: 6
Operations

If you were logged in you would be able to see more operations.
Firebird Core

ISQL extracts procedures body with double line break

Created: 30/Aug/06 10:17 PM   Updated: 12/Nov/09 05:18 PM
Component/s: ISQL
Affects Version/s: 2.0 RC4
Fix Version/s: 2.5 RC1

Time Tracking:
Not Specified

File Attachments: 1. File crlf.fbk (2 kB)
2. File crlf.sql (0.8 kB)
3. File show.epp.diff (0.7 kB)

Environment: Windows


 Description  « Hide
When extract metadata with ISQL -x to a file the procedures body have line break extracted as 0x0D and ISQL also put line break 0x0D 0x0A.
With notepad it is ignore first 0D but other editors take it as Line break for each.

isql -u "sysdba" -p "masterkey" -x -o design.sql "DESIGN.FDB"

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dzirt added a comment - 03/Jul/09 11:15 AM - edited
May be patch in attachment show.epp.diff is resolve problem (patch for Firebird 2.1.3.18182)?

Adriano dos Santos Fernandes added a comment - 10/Jul/09 12:24 PM
I can't reproduce.

All line breaks are using CRLF.

dennis redozubov added a comment - 11/Jul/09 04:02 PM - edited
crlf.fbk - a sample database backup with a procedure made with IBExpert. Procedure source contains CRLF line ends.

crlf.sql - the extracted metadata of the sample database made by isql with duplicated CR's in the procedure body.

dennis redozubov added a comment - 11/Jul/09 04:06 PM - edited
-

Adriano dos Santos Fernandes added a comment - 11/Jul/09 04:44 PM
But IBExpert is not part of Firebird.

I want to see a "good script" that you can use to create the objects with isql and the extraction result in the "bad script". I'm unable to reproduce that.

I want that because the text blob filter of the system table should normalize CRLF in the moment of the object creation.

Vlad Khorsun added a comment - 13/Jul/09 03:02 AM
Adriano,

about IBE : are you going to disable any 3rd party instruments ? :)

about blob filter and normalization of CRLF's : is this feature present and active since FB 1.0 ?
I ask because if this is not so, then metadata text's created before this feature could contain mixed kinds of line endings.

dennis redozubov added a comment - 13/Jul/09 05:46 AM - edited
Adriano,

I absolutely agree with Vlad about using third-party software. IBE doesn't write into or read from a database file directly. It simply uses API calls. So does isql.

But isql removes CRs from a SQL statement before supplying it to the server and reinserts them back while extracting the metadata. That's why if the metadata were inserted not with isql and already had CRs, they would duplicate.

You can see it with a simple test: try execute any DDL script containing CRLFs with IBE and isql. Then have a look at the resulted database file with a hex-viewer or whatever - IBE's version will contain CRLFs, isql's - LFs only.

By the way, it happens to all the metadata text blobs, not only procedures - views, descriptions, etc.

Adriano dos Santos Fernandes added a comment - 14/Jul/09 12:15 PM
I don't want to break applications provided that they work correctly, which appear to be the case.

Indeed, depending on console/GUI, things are inserted with CR or CRLF in the database.

The text blob filter is not used. It is a read-only filter, but ISQL uses the transliteration filter.

So when ISQL prints a CRLF, the MSVCRT converts it to CRCRLF.

Is it correct? I always though that only only LF not preceeded by CR would be converted.

dennis redozubov added a comment - 16/Jul/09 05:54 AM - edited
Well, yes, it is.

And as far as I can see the problem, it's because of output file is opened in text mode, so every LF is prepended with a CR, while CRs are passed as they are. I don't know whether it common behavior or MSVC only feature. I couldn't find a clear explanation of the issue in the c++ standard.

The workaround made by Dzirt is rather straightforward - kill all CRs in the text blob before sending it to the output file.

Adriano dos Santos Fernandes added a comment - 16/Jul/09 06:47 AM
Just removing CRs is not a good solution, as they also works as line terminator in Mac OS.

I think we should convert CRLF pairs to LF before print. But that should be done with care re. blob segment bondaries too.

dennis redozubov added a comment - 16/Jul/09 07:57 AM
OK, that sounds reasonable. I would also add the weird pair of LFCR. Just in case. :)

Dmitry Yemanov added a comment - 20/Jul/09 10:54 AM
As the tree is already tagged for Beta 2 and the final additions to the release notes have just been sent to Helen, I'm scheduling this ticket for RC1.