I have an ODBC DSN setup to hit a Filemaker database from my ASP.Net application. I'm trying to form a valid query where the column name has spaces in it. In T-SQL, you would enclose it in []. But I fail to get it to work in this case. Here's a valid query:
select * from ua_inventory where location like '%a%'
But this is not:
select * from ua_inventory where [item place] like '%a%'
I get the following error:
[DataDirect][ODBC SequeLink driver][ODBC Socket][DataDirect][ODBC FileMaker driver][FileMaker]Parse Error in SQL
Does anyone have a clue how to form queries where the table and/or columns have spaces in the name?
Thanks in advance
Here are some example queries:
SELECT DISTINCT LastNameFirst, "Full Name" FROM "UA Biographies" ORDER BY LastNameFirst"
SELECT DISTINCT Categories FROM UA_Inventory ORDER BY Categories
The important thing to remember is objects (table name & column names) need double quotes
The back-n-forth comments at the bottom of this artcle really helped out:
http://www.nathanm.com/filemaker-pro-odbc-quirks/
Related
I have a simple query like this:
SELECT * FROM CUSTOMERS WHERE CUSTID LIKE '~' AND BANKNO LIKE '~'
The problem is, the customers-table might or might not contain the BANKNO column depending on circumstances I've no control over. If however BANKNO is not a column in CUSTOMERS, this query fails.
So my question is: it is possible to test if the BANKNO column exists and if so, to include it in the query and if not to exclude this column?
The query really has to be flexible.
A non-existent column in a SELECT to sqlite3 will always fail.
One option might be to put the "full" sql in a try block, and if it errors, execute the other sql.
Or, you could query PRAGMA table_info('CUSTOMERS') and interrogate the result to see if a column in question is in the database. Find the sqlite doc here https://www.sqlite.org/pragma.html#pragma_table_info.
I'm sure there are other options, but the bottom line is you need to know before the sql is executed that it contains only valid column names.
I have a SQLite DB that have a corrupted table somehow. I can't access the table in my sqlite gui tool but when I query the same table with just a single column, I get the value fine.
So this do NOT work(SQL Error: SQL logic error or missing database):
select * from table
This DOES work:
select column from table
Result back from this query is the value of column. Perfectly normal result.
Any suggestions how this can happen? Any suggestion for any analysis tool for the actual file?
Seems that one of the columns were corrupt and prevented the select * to fully work. But the question remains, what can possibly be written to this column that prevents a select?
I need a query in oracle 11g that will search all the columns of a table for a particular string and give the result.
I have tried a query given below and it worked for me...
SELECT * FROM account
WHERE ACCOUNT_ID like'%gaurav%'
OR ACCOUNT_NAME like'%gaurav%'
OR PARENT_ACCOUNT like'%gaurav%'
OR WEBSITE LIKE '%gaurav%'
OR TYPE LIKE'%gaurav%'
OR DESCRIPTION LIKE'%gaurav%'
OR ACCOUNT_OWNER LIKE'%gaurav%'
OR PHONE LIKE'%gaurav%'
OR STD_CODE LIKE'%gaurav%'
OR EMPLOYEES LIKE'%gaurav%';
but I need a more simplified solution...as I am having only 10 columns in my table so this solution is okay but what if I have 30-40 columns in my table.
If you have a table with 30-40 columns you should normalize the database: http://www.studytonight.com/dbms/database-normalization.php and you might not need to check all columns (phone for example). Your solution is fine :)
If you need a solution that is generic, repeatable, and simple enough to use, then implement a table function with
input parameters of: "table name", "searched string"
result of: collection of tuple {"rowid", "column name with the match"}
Inside the table function you can implement the functionality you need via means of dynamic SQL.
As for the terms used above ...
collection: http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/composites.htm#LNPLS005
"tuple" = record ... http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/composites.htm#LNPLS005
dynamic SQL: http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/dynamic.htm#LNPLS011
(pipelined) table functions: http://docs.oracle.com/cd/E11882_01/appdev.112/e25519/tuning.htm#LNPLS915
Just out of curiosity, looks like a distinct field must be placed ahead of any other fields, am I wrong?
See this example in SQLite,
sqlite> select ip, distinct code from parser; # syntax error?
Error: near "distinct": syntax error
sqlite> select distinct code, ip from parser; # works
Why is that? Do I really have a syntax error?
There is no such thing as a "distinct field".
distinct applies to all fields in the query and therefore must appear immediately after select.
In other words, select distinct code, ip is really
select distinct
code,
ip
rather than
select
distinct code,
ip
It selects all distinct pairs of (code, ip). Thus the result set could include repeated values of code (each with a different value of ip).
It is not possible to apply distinct to a single field in the way you're trying to (group by might be a useful alternative, but we need to understand what it is exactly that you're trying to achieve).
my page has utf-8 meta element added + sql server encoding is also utf. However when I create record and try to issue SELECT statement with condition that contains POLISH characters like 'ń' , I see no results. Any ideas what am I missing?
ALSO Sql management studio shows result with POLISH characters , but I don't trust it.... I guess something is wrong with putting record into database...
Or how can I troubleshoot it?
Thanks,Paweł
I had the same issue, and I solved it by prefixing the text in the WHERE clause with "N".
For example, I have a table 'Person' containing a bit over 21,000 names of people. A person with the last name "Krzemiński" was recently added to the database, and the name appears normal when the row is displayed (i.e., the "ń" character is displayed correctly). However, neither of the following statements returned any records:
SELECT * FROM Person WHERE FamilyName='Krzemiński
SELECT * FROM Person WHERE FamilyName LIKE 'Krzemiń%'
...but these statements both returned the correct record:
SELECT * FROM Person WHERE FamilyName LIKE 'Krzemi%'<br>
SELECT * FROM Person WHERE FamilyName LIKE 'Krzemi%ski'
When I executed the following statement:
SELECT * FROM Person WHERE FamilyName LIKE '%ń%'
I get all 8900 records that contain the letter "n" (no diacritic), but I do not get the record that contains the "ń" character. I tried this last query with all of the Polish characters (ąćęłńóśźż), and all of them except "ó" exhibit the same behavior (i.e., return all records with the lower-ASCII equivalent character). Weirdly, "ó" works as it should, returning only those records with an "ó" in the FamilyName field.
In any case, the solution was to prefix the search criterion with "N", to explicitly declare it as Unicode.
Thus, the following statements:
SELECT * FROM Person WHERE FamilyName LIKE N'%ń%'
SELECT * FROM Person WHERE FamilyName=N'Krzemiński'
...both return the correct set of records.
The reason I was confused is that I have MANY records with weird diacritics, and they all return the correct records even without the "N" prefix. So far, the only characters I've found that require the explicit "N" prefix are the Polish characters.
According to this (Archived) Microsoft Support Issue:
You must precede all Unicode strings with a prefix N when you deal with Unicode string constants in SQL Server
simply use nvarchar instead of varchar as the datatype of the column saving the record.