I have this regular expressions to find syntax errors off of webpages (I'm a pentester for a living):
SQL_REGEX = %r((?-mix:SQL query error)|(?-mix:MySQL Query Error)|(?-mix:expects parameter)|(?-mix:You have an error in your SQL syntax))
I would like a regex that will find the error messages on a website if they have incorrectly closed SQL syntax, the one above works, but it seems to me that it's a little slower then it could be, any suggestions on how to make a better more reliable regex?
Related
I'm trying to work with some Visual FoxPro 9.0 code written years ago by programmers now long gone. There are several uses of ALLTRIM() that include a double-asterisk in front of the field name being passed, such as:
fred = ALLTRIM( **barney )
where Barney is a character field in a table. When I try running that line in a VFP session, it errors out with "Function is missing )". But I'm uncomfortable supporting code that I don't understand - what does the "**" do?
I've tried storing the field to a memvar, in case there's a SCATTER in the code that calls this, with no change in the resulting error. I've tried storing other data types (numeric and boolean) to the memvar, still no change. I've been programming in dBase, then FoxBase, then FoxPro, then VFP, for almost 35 years - and I don't remember ever coming across this before. And yet, the program runs without errors, I just don't understand what it is doing.
In case any of this matters, the code in question is stored in a memo field in a table, then invoked with an EXECSCRIPT() call. And some of the tables that the code is working with (but not the one containing the code) are SQL Server tables, accessed through cursor adapters - so "barney" in my example is very likely a field in a cursor adapter, not a .DBF.
I found my answer. Searching for asterisks in source code was useless, of course, because of comments. But I finally thought, after posting this question, of searching for the string with surrounding quotes, and found that, before the code I was looking at was called with EXECSCRIPT(), it was also run through STRTRAN(), which substituted "m." or "." or some other appropriate prefix for the "**" in the code.
So, the double asterisk was internal to the application, and meant nothing to VFP itself.
i'm getting started with sitecore and i just discovered this tool sitecore offers to test our queries:
My problem is i just can't make it return results and i do know this query works perfectly cause i've been using it on my project right now.
There is probably a problem of syntax somwhere i don't know.
Thank you for helping me to put some light on this !
It's a bit difficult to tell due to how bits of that are redacted (there might be other syntax errors hiding under the boxes), but there's one obvious issue there, I think: You don't need the "query:" bit on the beginning of what you've typed.
In general, if the API or web form your filling in can only take a query expression you can leave the "query:" bit off. But if you're putting text into somewhere that might take a query or might take something else then "query:" is needed to tell Sitecore what it's looking at.
When i use <<-SQL construction for insert SQL to my ruby code, syntax highlihting was broken:
So, my questions is:
1. is the way to fix this problem?
2. How i can find problem solution if google not understand <<-SQL character combination?
I am having the same problem on VS Code, except that I am using PHP but the syntax highlighting always breaks when I use any heredoc or nowdoc; The workaround I found was NOT to indent the closing tag (shown in the image below).
Not sure if it's the same case for your Ruby code.
I'm trying to find a means of working through Elasticsearch query parse exceptions in a fashion that doesn't treat me like a machine. I want to be a human and that means that when I have a syntax error in my query I want an informative and concise message.
Is there an existing service / gem / technology that makes this possible? Maybe it's a parser that you feed it ES gibberish query parse exception messages and it gives you back something (more) helpful? Or maybe it's an ES plugin that simply changes how parse exceptions are rendered.
My most wanted characteristics -
Concise, no more than 80 characters to summarize the problem and another 200 to explain how to fix it
It tells me exactly where in my query the error occurred (too often the error coarsely directs my debugging efforts; as in from[-1],size[-1]: Parse Failure [Expected [START_OBJECT] under [and], but got a [START_ARRAY] in [filter]]], which vaguely directs my attention to help me debug, but surely it could tell me at which line or character the syntax error occurred)
Human readable - it gets rid of the machine friendly cruft like {, (, and ; and uses proper English instead of jargon.
Your help in reducing the cognitive burden imparted by these exceptions is greatly appreciated.
I'm not sure if this helps, but if I have a query that is failing for a reason I don't understand, I like to use the Elasticsearch validate API.
So for my queries, I will do
curl -XPOST 'localhost:9200/<index>/_validate/query/?explain=true&pretty=true -d {
"query": {"match_all": {}}
}
It will take the query and run it through the validator, and if it fails, it will display the specific error it detected without all that cruft.
Hope that is helpful!
Thats awful, I can't find where I can turn if off!
The prolem is that PhpStorm detectes quote as Bad Token and Underwaves it.
The backticks delimiters for table and column names are not SQL compliant, they're MySQL, hence it's giving an error.
To fix the problem, inject the "MySQL" language into the string. The problem should be resolved.