It appears that SQLite, apparently as a "compatibility feature", parses double quoted identifiers as string literals if no matching column is found.
I understand that it does so for people who write improper sql, and for backwards compatibility with legacy projects created by such people, but it makes debugging very difficult for those of us writing proper sql on brand new projects.
For example,
SELECT * FROM "users" WHERE "usernme" = 'joe';
returns a query with 0 rows, since the string 'usernme' does not equal the string 'joe'.
This leaves me scratching my head wondering why i'm not getting joe's row even when i know there's a user by that name until I painstakingly backtrack my code and realize that I left out an a.
Is there any "strict mode" PRAGMA or API option to enforce quoting rules and treat all double-quoted strings as identifiers so that it will inform me immediately if one is misspelled?
(And please, no answers telling me not to quote identifiers if I don't need to, because any such answer is basically telling me that in order to get proper debugging, you have to write bad code in the first place.)
This is hardcoded in the SQLite parser and cannot be changed from the outside.
I also asked in the SQLite channel and someone there was kind enough to look through the source code and create a patch, and even started a thread on the mailing list describing the patch:
http://www.mail-archive.com/sqlite-users#sqlite.org/msg73832.html
It's not an answer that works for the official builds, but it may be someday. For the moment, I'm just going to recompile it myself with this patch.
Ten years later, and this doesn't completely meet your criteria about "strict mode" kinds of things, but here's a trick I used to make some queries safer, if you can remember to use it. It's to give your table an alias and reference it:
SELECT t."nosuch_column" FROM some_table t;
I suppose in this form, it's clear to SQLite that a literal isn't desired.
Related
Can anyone actually explain, in layman's terms, what is a real-world use case for the set operation's options?
While I fully understand what set with merge does, as well as merge beeing a boolean and mergeFields being an array of fieldPaths, I cannot think of cases in which mergeFields might be of any use.
I also understand the fact that mergeFields basically acts like a mask for the object passed to the set operation, but I still cannot think of how is it so useful that it actually got implemented within the SDK.
Can someone shed some light?
After looking through the documentation, there seem to be two reasons why you might want to use one vs the other:
mergeFieldPaths/mergeFields trigger an error when passing in field values that don't currently exist on the document while merge will add in those fields if they don't exist. The error is good for safety purposes if you're concerned about typos/writing to incorrect field paths.
This one is just a guess, but the documentation indicates mergeFieldPaths/mergeFields ignores AND leaves fields untouched while merge ONLY leaves other fields untouched. It's possible there's some performance advantage to using mergeFieldPaths/mergeFields esp for documents with a ton of fields. The difference might be direct access vs still needing to look at unspecified fields to identify the matches in some way.
SetOptions Reference
We're writing a parser for ACORD AL3. Read AL3 coming in, write AL3 going out. Nice and simple.
As of right now, it is 99% solid. The only thing that's driving me nuts is the use of "?"s in the ACORD AL3 standard. It appears that they are used as placeholders for fields that do not have values in the message. HOWEVER, that's not the only rule for it, because if it was, the AL3 I'm currently generating would look that the sample files I'm trying to have it match.
So if anyone here knows anything about the rules around AL3 "?"s, that would be great. I've been pouring over the Data Dictionary and the other documentation from ACORD, and I'm seeing nothing to indicate which fields get it, and which ones don't.
Also, if the "?"s are not required for AL3 processing to begin with, that would also be great to know, because then I could just stop worrying about the whole thing.
In the ACORD AL3 standard, from what I recall, if you use a "?" in one of the fields, this tells the receiving system to not overwrite (with blanks) the target field in the user's management system.
There may be individual elements in a group that are valid, but the sender
cannot send them for some reason. The solution is to fill that data element with questions marks (?????) The receiving system will recognize this and not update that field on their system.
In ACORD Al3 "?" means there is not any data in that specific element but that element is much important to maintain the hierarchy. But there is one thing, Coverage groups and Transaction groups will not contains any question mark. that does not means these are not important even these are very much important in Al3 files. But that above mentioned description applies for data group.
Secondly number of question marks in element describe its length.
If anyone need more details related to al3 data, don't hesitate to ask.
I have a web-form with a Name field which I want to be able to accept single apostrophes, such as in the name O'Leary, but when trying to push this record to the SQL 2005 server, I get an error. My question is not this. It's that when I attempt to insert the record into the db using this statement...
Dim acctName As String = Replace(txtName.Text, "'", "''")
I get O''Leary in the database instead of O'Leary. Thought SQL was supposed to treat these double single apostrophes as one apostrophe???
You'd be better off using parameterized queries. These will automatically handle the single quotes, and protect you better from SQL Injection.
Inserting the double single quotes (did I say that right?) is a way of escaping the data. It should work, but it's not a best practice.
See this article for a much fuller answer:
http://msdn.microsoft.com/en-us/library/ff648339.aspx
What I'm proposing is step 3.
Edit - I should read the question better
If you're already using parameterized queries, or a stored procedure, and you're setting the value of acctName to the value of a parameter, then you do not need to escape the quotes yourself. That's handled automatically.
It's also handled by several tools, including the Mirosoft Patterns and Practices Database library. That has several commands where you can pass in a statement and array of objects that are used as parameter values -that handles the escaping as well.
If either of those are the case, you can completely eliminate the line of code where you're replacing the values.
Depends how you're INSERTing the data into the database.
If you're using dynamic SQL and building the SQL string yourself, you are responsible for doubling the quotes yourself. But if you're using a parameterized query (as you should be, and probably are) then the engine will take care of that for you and, if you double the quotes yourself, you'll get doubled quotes in the database.
Note, if you started with dynamic SQL and switched to paramterized queries, this issue would suddenly appear at the time you made the change.
Off-the-cuff, without knowing too much detail I'd recommend checking the SET QUOTED_IDENTIFIER setting on the SQL Server. More information can be found here. Let me know if this helps.
It highly depends what query you actually submit. If you submit '' then this is what will be saved. You do need to double the ' but for other reasons (mainly security, but of course also syntax validity).
Please submit the code that you use to submit the query.
I don't currently have any access to any Oracle books and my searches online are returning literally no results ( (+) in Google shows nothing). I'm looking through existing code to add some fields to a query and saw:
AND lookup.LookupID (+) = AuditID
However, I have no idea what this does. Any help would be appreciated.
Note: I'm not seeing a community wiki checkbox while posting this in Google Chrome, so if someone can change it to that for me, I'd be appreciative. Thanks.
What you're seeing is an "old" way for specifying an outer join. Oracle needed a syntax to represent outer joins and before the ANSI commitee settled on a standard syntax, Oracle came up with their own.
(+) should be seen only in legacy code and today it is recommended to simply avoid this syntax and stick with the standards.
In this Oracle FAQ you can read some historical info. Not too detailed, but it will give you an idea of how this operator came to be.
Relevant part:
In query2 we see the "Old Style"
Oracle syntax for OUTER-JOIN. It is
the PLUS SIGN in parenthesis. This
syntax was not actually invented by
Oracle but rather some smart guy whose
name escapes me at the moment. Oracle
saw its value and was an early adopter
of OUTER-JOIN but doing so required
them to use a syntax before ANSI SQL
COMMITTEE settled on one. The new and
improved ANSI SQL is fine and all,
some say even better, but being an old
bird I tend to stick with old and
proven ways till something makes me
change.
Apparently not even Oracle did invent this syntax. It's good to have standards...
It is Oracle way to specify a outer join (ANSI way would be RIGHT JOIN/LEFT JOIN)
I'm trying to build a search that is similar to that on Google (with regards to exact match encapsulated in double quotes).
Let's use the following phrase for an example
"phrase search" single terms [different phrase]
Currently if I use the following code
Dim searchTermsArray As String() = searchTerms.Split(New String() {" ", ",", ";"}, StringSplitOptions.RemoveEmptyEntries)
For Each entry In searchTermsArray
Response.Write(entry & "<br>")
Next
my output is
"phrase
search"
single
terms
[different
phrase]
but what I really need is to build a key value pair
phrase search | table1
single | table1
terms | table1
different phrase | table2
where table1 is a table with general info, and table2 is a table of "tags" similar to that on stackoverflow.
Can anybody point me in the right direction on how to properly capture the input?
What are you trying to do is not that trivial. Implementing a search "similar to Google's" is far beyond parsing the search string.
I'd suggest you not to reinvent the wheel and instead use production ready solutions such as Apache Lucene.NET or Apache Solr. Those cope with both parsing and fulltext search.
But if you only need to parse this kind of strings then you should really consider solution Pete pointed to.
Regex is your friend. See this question
Depending on how fancy you plan in getting, you might consider the search grammar/implementation that's included with Irony.
http://irony.codeplex.com/
Search string parsing is a non-regular problem. That means that while a regular expression can get deceptively close, it won't take you all the way there without using proprietary extensions, building an unmaintainable mess of an expression, leaving nasty edge cases open that don't work how you'd like, or some combination of the three.
Instead, there are three correct ways to handle this:
Use a third-party solution like Lucene.
Build a grammar via something like antlr.
Build your own state machine.
For a problem of this level (and assuming that search is core enough to what you're doing to really want to implement it yourself), I'd probably go with option 3. This makes more sense when you realize that regular expressions are themselves instructions for how to set up state machines. All you're doing is building that right into your code. This should give you the ability to tune performance and features as well, without requiring adding a larger lexer component into your code.
For an example of how you might do this take a look at my answer to this question:
Reading CSV files in C#
hat I would do is build a state machine to parse the string character by character. This will be the easiest way to implement a fully-correct solution, and should also result in the fastest code.