Closed YvesR closed 3 years ago
Hi, Sorry, I'm not 100% understanding. Could you possibly post an example of the cut-off content?
Sure.
That means that I have data fields of type nvarchar(max)
and those content fields were not always export completely.
Content was cut off for my tests. So one of my content had 21410 chars and after insert on other system there where missing chars.
I did the same thing user MS SQL Management Studio with Generate scripts wizard
and there I got the full content.
Beside this, export data using
\r\n
does not work if you want to insert data e.g. on Azure SQL using management studio. There should be real line breaks, or to be save something like' +CHAR(10) + CHAR(13) + '
I just did to reproduce the same steps again and now it seems I do have all chars now, so it seems something else must cause the effect on export. But still have to regex search and replace the line breaks before insert.
I've reproduced the line break issue. I'll get that sorted for the next build.
Thanks for taking care.
Could you try this build: https://sqlprostudio.s3.us-east-1.amazonaws.com/studio/SQLProStudio.2020.93.app.zip
That should sort this issue out.
Could you try this build: https://sqlprostudio.s3.us-east-1.amazonaws.com/studio/SQLProStudio.2020.93.app.zip
That should sort this issue out.
Hello, I did test it.
\n
by CHAR(13) only and do not a \r
at all. OR you check the content before export if your find those chars. In my case I do not have CrLf, I have Lf only.I think CHAR(10) + CHAR(13) is to much, this destroy the content. Replace \n by CHAR(13) only and do not a \r at all. OR you check the content before export if your find those chars. In my case I do not have CrLf, I have Lf only.
Hmmm, so the code should actually be just replacing \r's with CHAR(10) and \n's with CHAR(13) (each is done individually) - so it should be matching exactly what goes in. So
To confirm, this is NOT what you are seeing?
Correct. Sample:
<table width="100%" cellpadding="5" cellspacing="0" border="0">
<tr>
<td>
When I do use the statement I get results
<table width="100%" cellpadding="5" cellspacing="0" border="0">
<tr>
<td>
Ahh, I think I see what happened. I've got my 10 and 13's mixed up. I'm building a new build now. With the following test case:
CREATE TABLE dbo.lineBreak (
lineBreak nvarchar(256) NOT NULL
);
GO
INSERT INTO dbo.lineBreak (lineBreak) VALUES
('hello' + CHAR(10) + 'world'),
('hello' + CHAR(13) + 'world'),
('hello' + CHAR(10) + '' + CHAR(13) + 'world');
If I export as a MSSQL script, I receive:
-- Inserting 3 rows into dbo.lineBreak
-- Insert batch #1
INSERT INTO dbo.lineBreak (lineBreak) VALUES
('hello' + CHAR(10) + 'world'),
('hello' + CHAR(13) + 'world'),
('hello' + CHAR(10) + '' + CHAR(13) + 'world');
So the same input yeads the same output. I'll have the build available shortly.
Ok! Sorry about that. I believe this build should do the trick: https://sqlprostudio.s3.us-east-1.amazonaws.com/studio/SQLProStudio.2020.94.app.zip
Please let me know if you get the chance.
Tried last version. Strange thing is that app crash on execute with generated script.
Need to dig into details, but it seems SQL server handle
+ CHAR(10) + '' + CHAR(13) +
and
+ CHAR(10) + CHAR(13) +
different.
I see no reason to add the + '' +
anyway.
Tried last version. Strange thing is that app crash on execute with generated script.
Sorry, your seeing the SQLPro crash when it's generating the query, or once you try to execute the generated query? (Could you possible provide the crash report? I'm not seeing any crashes on appcenter.ms for that app version).
- CHAR(10) + '' + CHAR(13) +
Hmm, that seems odd -- I'm not sure why the '' would be added.
Sorry, your seeing the SQLPro crash when it's generating the query, or once you try to execute the generated query? (Could you possible provide the crash report? I'm not seeing any crashes on appcenter.ms for that app version).
Do not really know, I did open your special version from download link. The moment I hit execute the window simple closes. Tried the current live version, same effect (they share cache data). So this seems to be an other problem related to this.
I've posted an update to the app store. If you get the chance, could you check this out and see if it helps sort the issue out?
Hello,
tested your latest version from AppStore.
Beside the small issue that Char 10 and 13 still creates ' + CHAR(13) + '' + CHAR(10) + '
(extra + '' + is not needed) the export works fine. Imported data using those INSERT statements worked also as expected.
From my point of view the problem is solved.
Ahhhh, sorry I had misunderstood when you mentioned that earlier. I will replace:
' + CHAR(13) + '' + CHAR(10) + '
With
' + CHAR(13) + CHAR(10) + '
and get that fixed for the next build.
(And I will leave the issue open until that is sorted).
Just to note this has been all fixed up. If you continue to see any related issues, please let me know.
As a user I can create insert statements for export and import data from one database to another.
Select table and export to MSSQL
Select bulk insert statements.
Problem Fields of type
nvarchar(max)
on export will have a limit length and therefor I loose content here!