Maybe i'm missing something, but does anyone know how the debugging line numbering works in BigQuery?
I get an error like this:
Failed to save view. 2.196 - 2.226: Ambiguous column name eventcode.
and I'm not sure what the address 2.196-2.226 means. Specifically, what does the decimal signify? The second line of my query is very short (just SELECT *), so I don't think the numbers after the decimal indicate a character range?
Anyway -- I can't find any info for it in the docs, so any help here would be great
Line counting is most like shifted by 1 so it is actually line number #1 (not #2)
196 - 226 points to char range on that line with piece of code that introduces ambiquity - just the second piece (that has already existing aliac or column name for it)
Somehow for some first lines line numbering is incremented by 1 - it can be a bug on BQ UI side.
Btw, I noticed same strange behaviour in CodeMirror BQ UI is using, so it can be CodeMirror's bug too
Related
I have the following segment of comment in my code file (the last line is intentionally missing the slash characters - that the error):
// * Cube Back Text from Méi guī
// 一颗 心 怕 摔倒 打破
//"yī kē xīn pà shuāi dǎo dǎ pò"
// "It's the heart afraid of breaking"
// 不敢 起舞 欢 歌
// "bù gǎn qǐwǔ huāngē"
// "that never learns to dance."
不敢起舞欢歌 (dance)
But the red error dot appears on the second character of the second line (second slash of the line "// * Cube Back Text from Méi guī".
Stranger, if I remove various quotes in the comment, the character that is hilited changes.
I assume this has something to do with a recursive structure somewhere in the parser that is continuing to parse the quotes inside the comment itself and ultimately figures out where to signal the error.
I suppose this is a bug ("semi-bug") that I should post to the GitHub list - to completely ignore anything past the second slash on a commented line, or some other change so that the error tag shows up on the line where the error actually is?
As it is, I futzed around about 10 minutes wondering if OpenSCAD just didn't like files longer than 575 lines.
I get the same problem when I try your example or modify it slightly but it worked perfectly when I replaced everything with random Latin characters so I think the bug has a lot to do with the Chinese ideographs you used.
In any case, I only copied the small sample you gave so it probably have nothing to do with the length of the file.
I'm currently using vim to take notes and the way I'll usually do that is as follows:
- First line of info
- Sub line of info
- More sub information
- Second point
- Third point, etc
However, when writing long lines the output will look as follows:
- First line of info that is really long
goes down to here
- Subpoint line of info that is short
- Subpoint line that is really long goes to
here and continues
- Subpoint line that is short again
- Second point that is really long goes to
here, etc, etc
What I'd really like is if it looked like this:
- First line of info that is really long
goes down to here
- Subpoint line of info that is short
- Subpoint line that is really long goes to
here and continues
- Subpoint line that is short again
- Second point that is really long goes to
here, etc, etc
This would make it easier to see when each new point or subpoint was started because of the "-" sticks out more.
If possible I'd like:
automatic inserting of the leading character (doesn't have to be a dash) on enter
automatic inserting of the leading character (doesn't have to be a dash) on o and O
automatic soft wrapping of the text to the correct indentation level
automatic soft wrapping of the text to the first character after the leading character
I've been able to achieve the first three using the following:
set formatoptions=ro
set comments=b:-
set breakindent
set autoindent
However, when trying to get the soft wrapping at the first character after the "-" I am having trouble.
I've tried using set formatoptions+=n with an accompanying formatlistpat=^\s*-\s*. However, then it is not automatic and I need to use gq which seems like it makes a second line instead of just soft wrapping. If using set formatoptions+=wan I can get it sometimes automatically wrapping but it is once again a hard line break, not a soft wrapping.
If anyone could help that would be greatly appreciated!
So I've finally figured it out. The answer was breakindentopt :help breakindentopt
Specifically set breakindentopt=shift:2
This causes the line that is wrapped due to breakindent to shift two spaces two the right which lines everything up the way I wanted.
The full settings which achieve what I was going for are:
set formatoptions=ro
set comments=b:-
set breakindent
set autoindent
set breakindentopt=shift:2
Informix 11.5
I am trying to search for carriage returns and line feeds that may exist in a VARCHAR field. First, I need a SELECT statement to show that they exist. Second, I need to REPLACE them with a space or other character.
I've tried all kinds of variations:
CHR(10) + CHR(13)
CHR(10) || CHR(13)
CHAR(13) + CHAR(10)
CHAR(13) || CHAR(10)
SELECT CHR(10) from systables;
Everything gives an error: Routine (chr) can not be resolved.
I've been searching all over and just can't find anything that works, and I'm sure this is crazy stupid easy.
Get the ASCII package from the IIUG
The CHR() function was added to IDS 11.70; it isn't in IDS 11.50.
The good news is you can add the function because IDS is an extensible server. The better news for you is that you can obtain the relevant code from the IIUG web site in the Software Archive under the Miscellaneous section as ascii.
That should allow you to do what you need. (Note: I wrote the code way back when — before there was support built into any of the servers.)
Windows makes things more complicated
I was uploading the ascii.unl file and I get an error that the number of columns do not match on line 13. Have you seen this before? I'm on Windows 2008. The errors are:
846: Number of values in load file is not equal to number of columns.
847: Error in load file line 13.
I hadn't seen it before, but I've not tried the file on Windows and … well, let's say life gets trickier on Windows than it is on Unix (and this bit isn't all that simple on Unix).
First of all, the data file needs to have CRLF line endings instead of the NL-only line endings that are standard on Unix. (Note that NL, newline, is another name for LF, line feed — aka '\n'.) For most lines in the unload file, that isn't a problem.
The two entries for which it might be (is) a problem are for CR and LF — entries 13 and 10 respectively. In theory, if the entry for line 10 contains (in C string notation) "10|\\\n\r\n" (that is, 10, pipe, backslash, newline, CRLF), all should be OK; the absence of an error message for line 10 suggests that it is OK.
Similarly, the entry for line 13 is "13|\r\r\n", which apparently causes grief. The simplest trial fix is to add a backslash here too: "13|\\\r\r\nn". The backslash says "the next character doesn't have a special meaning". If that doesn't work, we'll probably have to try hex-escape notation: "13|\\0d\r\n" — and use dbaccess -X to enable the hex escape notation.
With luck, one of those two (or both) will work. If neither works, come back and we'll try to think of something else.
As per my above comment:
I was uploading the ascii.unl file and I get an error that the number of columns do not match on line 13. Have you seen this before? I'm on Windows 2008. 846: Number of values in load file is not equal to number of columns. 847: Error in load file line 13.
Here is what I see in the ascii.unl file.
If I put this into MS Word and turn on Show Formatting/Paragraph marks, it shows this:
I got this error message while using StringTemplate:
line 94:26: unexpected char: ')'
And after about 15 minutes of randomly adding and removing blank lines in my template, and observing how the number in that message changed, I finally isolated the line that caused trouble. It was line #152, position #35.
Is the value after "line " just normally totally wrong, or is there a way of deducing the real line number from that output?
In StringTemplate (ST) 4, it appears that the first number is the line number, within the specific template at issue and not the line number within the .stg file if that's what you're using (which most of us do).
When I'm using vim, this means I need to mentally offset that from the line number of the first line of the template (add them together) to get the actual line number within the .stg file.
The second number in the ST error is the character position within that line of the template. But wait, there's more - you know you love it...
When an error is on the first line of a multi-line template: since ST elides the starting newline in multi-line templates, ST effectively combines the first/ declaration line (ending in "<<") with the second (actual start of the template) line, in multi-line templates;
so at least with ST-4.0.8 I need to subtract the length of the template declaration line from the character position, to get the actual character position.
The first "\n" eliding (for multi-line templates only) also means the line number may appear to be offset by 1, and possibly the character position, for an error on the "first line".
The error should include the filename and template name, so it's enough information for an automated script or tool, but a bit cumbersome for us mere humans.
Good luck.
I'm trying to process a fixed width input file in pentaho and validate the format. The file will be a mixture of strings, numbers and dates. However when attempting to process a number field that has an incorrect character present (which i had expected would throw an error) it just reads the first part of the number and ignores the bad char.
I can recreate this issue with a very simple input file containing a single field:
I specify the expected number format, along with start position and length:
On running the transformation i would have expected the 'Q' to cause an error instead the following result is displayed, just reading the first two digits "67" and padding the rest to match the specified format:
If the input file is formatted correctly it runs perfectly well, but need it to throw an error otherwise. Any suggestions would be awesome. Thanks!
Just an FYI in case someone stumbles accross this question after hitting the same issues as myself.
I was able to construct a workaround by reading all values in the "Text File Input" step as strings, and then using a "Data Validator" step equipped with regex evaluation to ensure numbers were correctly formatted before parsing to number type with a following "Select Values" step.
Takes a bit longer to do this for every field, but was the most robust solution i could come up with.
Thanks