-
-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ISQL extracts procedures body with double line break [CORE915] #1314
Comments
Modified by: @pcisarWorkflow: jira [ 11184 ] => Firebird [ 15336 ] |
Commented by: Dzirt (dzirt) May be patch in attachment show.epp.diff is resolve problem (patch for Firebird 2.1.3.18182)? |
Modified by: Dzirt (dzirt)Attachment: show.epp.diff [ 11466 ] |
Commented by: @asfernandes I can't reproduce. All line breaks are using CRLF. |
Commented by: dennis redozubov (dennis-r) 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. |
Modified by: dennis redozubov (dennis-r)Attachment: crlf.fbk [ 11471 ] |
Commented by: dennis redozubov (dennis-r) - |
Modified by: dennis redozubov (dennis-r)Attachment: crlf.sql [ 11472 ] |
Commented by: @asfernandes 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. |
Commented by: @hvlad 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 ? |
Commented by: dennis redozubov (dennis-r) 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. |
Commented by: @asfernandes 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. |
Commented by: dennis redozubov (dennis-r) 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. |
Commented by: @asfernandes 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. |
Commented by: dennis redozubov (dennis-r) OK, that sounds reasonable. I would also add the weird pair of LFCR. Just in case. :) |
Modified by: @asfernandesassignee: Adriano dos Santos Fernandes [ asfernandes ] |
Modified by: @asfernandesstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5 Beta 2 [ 10300 ] |
Commented by: @dyemanov 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. |
Modified by: @dyemanovFix Version: 2.5 RC1 [ 10362 ] summary: ISQL Extract procedures body with double line break. => ISQL extracts procedures body with double line break Fix Version: 2.5 Beta 2 [ 10300 ] => |
Modified by: @dyemanovissuetype: Improvement [ 4 ] => Bug [ 1 ] |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Submitted by: zaher dirkey (zaher)
Attachments:
show.epp.diff
crlf.fbk
crlf.sql
Votes: 8
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"
Commits: 029e9ff
The text was updated successfully, but these errors were encountered: