Re: Double quotes throws off SQL syntax colouring

Paul <Paul.Domaskis <at> gmail.com> writes:
> I'm editing a file tmp.sql with syntax colouring. The following
> code all turns yellow after the first double quote (actual file
> contains a lot more code). I'm in an environment, where upgrading
> anything is difficult. Is there anything superficial changes I can
> make to prevent this unexpected colour behaviour?
>
> SELECT
> Field1,
> COUNT(*) AS Field2,
> MIN ( LEN( REPLACE( EEEPppp, "\", "" ) ) ) AS Field3,
> FROM someTable
> etc....

Ben Fritz <fritzophrenic <at> gmail.com> writes:
| Why is that unexpected?
|
| I'm not familiar with SQL syntax, but some brief searching shows
| that at least sometimes, '\' can escape a '"' character as it can in
| many other languages (although I also see that sometimes it cannot
| escape the quote...so maybe this is one of those times, please
| correct me if that's the case).
|
| So, if I'm reading that right, you're using a single string
| containing a literal " character, a comma, and a space. Then you're
| opening the next string. It looks like maybe you wanted to use '\',
| '' or "\\", "" or something like that instead of "\", "" in your
| code.

I'm using Access 2010. Unfortunately, from experimentation, a double
backslash doesn't match a backslash in the data.

William Robertson <william <at> williamrobertson.net> writes:
|
| I think the double quotes may be a red herring, as the issue is
| really the backslash. I've just tried with single quotes and a
| backslash is treated as escaping a closing quote, despite it not
| being an escape character in SQL (I'll admit I'm only familiar with
| Oracle though so perhaps '\' has some special significance in other
| SQL dialects.)
|
| I can't say I've hit this issue before, but if you wanted to replace
| backslashes with forward slashes and you used
|
| replace(somecolumn, '\', '/')
|
| that would mess up syntax highlighting as the first quoted string
| would be treated as ending at the third quote.

I'm actually replacing backslashes with zero-length strings so that I
can determine the number of backslashes in the string based on how
much shorter it becomes. So I need to match a backslash.

Tim Chase <vim <at> tim.thechases.com> writes:
| I'd expect that, as I believe just about every SQL engine out there
| uses ANSI-standard single-quotes instead of double-quotes. Some
| might *permit* double-quoted strings, but it certainly doesn't
| adhere to standards, and double-quotes are used in some databases to
| quote names of databases/tables/columns.
|
| What SQL engine is this for?

Microsoft Access 2010.

John Little <John.B.Little <at> gmail.com> writes:
| As others have pointed out, standard SQL uses single quotes. Looks
| like you might be using Informix, SQL anywhere or SQL HANA, because
| those highlight your snippet properly in my vim.
|
| I suggest running
|
| :help sql-type-default
|
| in Vim.

I tried all 3 SQL dialects in the help:

let g:sql_type_default = 'sqlanywhere'
let g:sql_type_default = 'sqlinformix'
let g:sql_type_default = 'mysql'

'sqlanywhere' and 'sqlinformix' seem to get around the problem, while
'mysql' does not. Quick googling shattered my misconception that the
latter is a Microsoft invention.

Strictly speaking, the dialect for Access use to be JET, and it is ACE
these days. Because Microsoft Office is so prevalent, I'm surprised
that there isn't a syntax file for that. Ah well, I will run with
'sqlanywhere' until I see anomalies, then switch to 'sqlinformix' to
see if it circumvents them.

Thanks!

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.