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

Wrong symbol for single quotewhen saving to sql file #1502

Closed
Bluezy opened this Issue Aug 10, 2018 · 9 comments

Comments

Projects
None yet
5 participants
@Bluezy
Copy link

Bluezy commented Aug 10, 2018

Details for the issue

the SQL file obtained via the "Save database to an SQL file" uses ` (U+0060, accent grave) instead of ' (U+0020) apostrophe

Useful extra information

I'm opening this issue because:

  • DB4S is crashing
  • DB4S has a bug
  • DB4S needs a feature
  • DB4S has another problem

I'm using DB4S on:

  • Windows: ( version: ___ )
  • Linux: ( distro: ___ )
  • Mac OS: ( version: ___ )
  • Other: ___

I'm using DB4S version:

  • 3.10.1
  • 3.10.0
  • 3.9.1
  • Other: ___

I have also:

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Aug 11, 2018

Ahhh. Would you be ok to try with the latest nightly build (tomorrow's one, in a few hours)?

    https://nightlies.sqlitebrowser.org/latest/

We've been doing stuff with the SQL file export recently, and I think we've been changing quotes too. 😄

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Aug 12, 2018

Yep, we have changed quotes throughout the entire program, including the SQL export. So the nightly is worth a try 😄 But I guess you mean double quotes instead of the apostrophe? Because apostrophes are for strings only, not for identifiers, and we've been using them since ever for strings 😉

Just mentioning one exception to the changes in the nightly build: if the original table definition uses e.g. grave quotes and you configured the application to use double quotes (the new default), it'll export double quotes unless the table or index definition cannot be fully parsed. So if our parser notices something it doesn't fully understand we leave the statement as-is to avoid any loss of information. For triggers and views that's always the case by the way. So these statements would always be exported using grave quotes if that's how they were defined in the first place.

@chrisjlocke

This comment has been minimized.

Copy link
Contributor

chrisjlocke commented Aug 16, 2018

@Bluezy : cough

@chrisjlocke chrisjlocke added the bug label Sep 6, 2018

@chrisjlocke

This comment has been minimized.

Copy link
Contributor

chrisjlocke commented Sep 6, 2018

Just exported a database to SQL using the nightly (6 Sep) and while CREATE TABLE and INSERT statements use the user-defined option, CREATE VIEW doesn't.

image

Also (I'm on Windows) there was no option to set carriage return options, so all the SQL has got squished into one line - note the 'tn3.orderBy=3left join contactsData'.....(etc). It is valid SQL though (it all imported fine) but its just the 'wrong' line terminators for Windows...

@justinclift

This comment has been minimized.

Copy link
Member

justinclift commented Sep 6, 2018

Good thing you checked @chrisjlocke. 😄

@MKleusberg

This comment has been minimized.

Copy link
Member

MKleusberg commented Sep 6, 2018

@chrisjlocke You're right - but it's supposed to be like that 😉 The reason for that is that the quotation settings only affect all the SQL statements generated by us. The INSERT statements are obviously always generated by us and the CREATE TABLE statements at least most of the time because we have the habit to parse them and then put them back together whenever we work with them. But if the parser doesn't quite understand the full CREATE TABLE statement it will just not touch it and export it in its original form. The same is true for indices. Views and triggers on the other hand are never parsed (because we have no parser for them 😉) so we always export them in their original form, that is by which statements they were originally created and how they were saved in the database.

@chrisjlocke

This comment has been minimized.

Copy link
Contributor

chrisjlocke commented Sep 6, 2018

That's pants! ;) 😆
Fair enough - makes sense!

mgrojo added a commit that referenced this issue Sep 6, 2018

SQL export uses wrong line terminators for Windows
According to Qt documentation:

When writing, the end-of-line terminators are translated to the local
encoding, for example '\r\n' for Win32.

Reported in issue #1502
@mgrojo

This comment has been minimized.

Copy link
Contributor

mgrojo commented Sep 6, 2018

@chrisjlocke:

Also (I'm on Windows) there was no option to set carriage return options, so all the SQL has got squished into one line - note the 'tn3.orderBy=3left join contactsData'.....(etc). It is valid SQL though (it all imported fine) but its just the 'wrong' line terminators for Windows...

That should be solved with my last commit. Could you confirm it?

@chrisjlocke

This comment has been minimized.

Copy link
Contributor

chrisjlocke commented Sep 7, 2018

Can confirm - the file now looks beautiful. Almost art. 😉
Thanks! 👍

I'll close this as its resolved. @Bluezy can re-open it or comment further if need be. 📓

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment