Database Export

[Brendon Kozlowski]

I've noticed that the newlines created during an export of a database (tested with v5.01 and v5.02 Free Edition) are set as:

nnr

…or x0D x0D x0A, depending on how you write it (assuming the previous).

On Windows' based systems, that's one too many carriage returns. ((SUGGESTION)) Perhaps there should be an option on the export window that allows to export to a certain OS' native newline as well?

…only other suggest I'd have is to swap the C++ style comments (/**/) with double hyphens and a space per line to make it more ANSI SQL compatible.

OLD

Quote:

/*

SQLyog – Free MySQL GUI v5.01

Host – 4.1.14-nt : Database – history

*********************************************************************

Server version : 4.1.14-nt

*/

NEW

Quote:

— SQLyog – Free MySQL GUI v5.01

— Host – 4.1.14-nt : Database – history

—

---

— Server version : 4.1.14-nt

…it's hard to see in the forum, but there's a space between the two hyphens and the text; that's mandatory.

[peterlaursen]

1st issue confirmed!

That also explains two issues I think.

1) in some text-editors (not Notepad but Textpad for instance) there is an empty line between each row of data.

2) when importing data SQLyog reports twice as may rows as there are.

What is the particular reason for the 2nd request?

[Brendon Kozlowski]

peterlaursen wrote on Feb 13 2006, 11:52 AM:

What is the particular reason for the 2nd request?

[post=”8732″]<{POST_SNAPBACK}>[/post]

I know that MS SQL doesn't like the /**/ form of commenting, and although I haven't tested Oracle or PostgreSQL, I would assume that at least one of them wouldn't like it either. The double hyphen is just more standards acceptable in SQL, I believe.

I *think* phpMyAdmin would also get confused with commenting such as this, and if, say, I emailed a backup to someone who prefers to use a different MySQL client, it's possible that this style of commenting could confuse the client and cause problems.

…and yes, I noticed the double newline problem due to my text editor (Crimson Editor) showing an “unknown” character, which usually shows up as a filled square (such as xDB, or character 219 in decimal). I had problems with a poorly created CSV file and had to clean it out, so I created a function that prints out all character codes of a given text file and used that to determine that there are two carriage returns in a row, with a line feed after.

[peterlaursen]

Quote:

I *think* phpMyAdmin would also get confused with commenting such as this

I don't thinks so! The parsing is done by the server and not the client. Don't think that phpmyadmin attempts to parse either.

But it is true that the /* */ comments style is a C-impact on MySQL that is not originally a SQL comment – and probably does not conform with ANSI standards either.

Personally I don't care!

[peterlaursen]

It looks like — and /* */ are standards, # is a MySQL speciality.

http://dev.mysql.com/doc/refman/5.0/en/comments.html

http://dev.mysql.com/doc/refman/5.0/en/ans…f-comments.html

http://dev.mysql.com/doc/refman/5.0/en/portability.html

I have noticed that the (also C-style?)

// this is a comment

often works too as a comment when it start as the first cahracter of a line.

However it is undocumented, and probably should be avoided.

[Brendon Kozlowski]

…I knew MSSQL didn't like a certain comment character, I thought it was /**/, guess not. Anyway, thanks for the quick research and confirmation of the double newlines.

[peterlaursen]

let me add that that if it is correct what I assume here that SQLyog simply counts the number of lines processed when importing it should display 'lines processed: xxxx' and NOT 'rows imported: xxxx'.

[Ritesh]

Thanks for the report. Addition of those special characters is indeed a bug. Will be fixed in v5.1.

I am not sure about the commenting idea.

[Author]

Posts