I'm trying to run the following PHP script to do a simple database query:
$db_host = "localhost";
$db_name = "showfinder";
$username = "user";
$password = "password";
$dbconn = pg_connect("host=$db_host dbname=$db_name user=$username password=$password")
or die('Could not connect: ' . pg_last_error());
$query = 'SELECT * FROM sf_bands LIMIT 10';
$result = pg_query($query) or die('Query failed: ' . pg_last_error());
This produces the following error:
Query failed: ERROR: relation "sf_bands" does not exist
In all the examples I can find where someone gets an error stating the relation does not exist, it's because they use uppercase letters in their table name. My table name does not have uppercase letters. Is there a way to query my table without including the database name, i.e. showfinder.sf_bands?
From what I've read, this error means that you're not referencing the table name correctly. One common reason is that the table is defined with a mixed-case spelling, and you're trying to query it with all lower-case.
In other words, the following fails:
CREATE TABLE "SF_Bands" ( ... );
SELECT * FROM sf_bands; -- ERROR!
Use double-quotes to delimit identifiers so you can use the specific mixed-case spelling as the table is defined.
SELECT * FROM "SF_Bands";
Re your comment, you can add a schema to the "search_path" so that when you reference a table name without qualifying its schema, the query will match that table name by checked each schema in order. Just like PATH in the shell or include_path in PHP, etc. You can check your current schema search path:
SHOW search_path
"$user",public
You can change your schema search path:
SET search_path TO showfinder,public;
See also http://www.postgresql.org/docs/8.3/static/ddl-schemas.html
I had problems with this and this is the story (sad but true) :
If your table name is all lower case like : accounts
you can use: select * from AcCounTs and it will work fine
If your table name is all lower case like : accounts
The following will fail:
select * from "AcCounTs"
If your table name is mixed case like : Accounts
The following will fail:
select * from accounts
If your table name is mixed case like : Accounts
The following will work OK:
select * from "Accounts"
I dont like remembering useless stuff like this but you have to ;)
Postgres process query different from other RDMS. Put schema name in double quote before your table name like this, "SCHEMA_NAME"."SF_Bands"
Put the dbname parameter in your connection string. It works for me while everything else failed.
Also when doing the select, specify the your_schema.your_table like this:
select * from my_schema.your_table
If a table name contains underscores or upper case, you need to surround it in double-quotes.
SELECT * from "Table_Name";
I had a similar problem on OSX but tried to play around with double and single quotes. For your case, you could try something like this
$query = 'SELECT * FROM "sf_bands"'; // NOTE: double quotes on "sf_Bands"
This is realy helpfull
SET search_path TO schema,public;
I digged this issues more, and found out about how to set this "search_path" by defoult for a new user in current database.
Open DataBase Properties then open Sheet "Variables"
and simply add this variable for your user with actual value.
So now your user will get this schema_name by defoult and you could use tableName without schemaName.
You must write schema name and table name in qutotation mark. As below:
select * from "schemaName"."tableName";
I had the same issue as above and I am using PostgreSQL 10.5.
I tried everything as above but nothing seems to be working.
Then I closed the pgadmin and opened a session for the PSQL terminal.
Logged into the PSQL and connected to the database and schema respectively :
\c <DATABASE_NAME>;
set search_path to <SCHEMA_NAME>;
Then, restarted the pgadmin console and then I was able to work without issue in the query-tool of the pagadmin.
For me the problem was, that I had used a query to that particular table while Django was initialized. Of course it will then throw an error, because those tables did not exist. In my case, it was a get_or_create method within a admin.py file, that was executed whenever the software ran any kind of operation (in this case the migration). Hope that helps someone.
In addition to Bill Karwin's answer =>
Yes, you should surround the table name with double quotes. However, be aware that most probably php will not allow you to just write simply:
$query = "SELECT * FROM "SF_Bands"";
Instead, you should use single quotes while surrounding the query as sav said.
$query = 'SELECT * FROM "SF_Bands"';
You have to add the schema first e.g.
SELECT * FROM place.user_place;
If you don't want to add that in all queries then try this:
SET search_path TO place;
Now it will works:
SELECT * FROM user_place;
Easiest workaround is Just change the table name and all column names to lowercase and your issue will be resolved.
For example:
Change Table_Name to table_name and
Change ColumnName to columnname
It might be silly for a few, but in my case - once I created the table I could able to query the table on the same session, but if I relogin with new session table does not exits.
Then I used commit just after creating the table and now I could able to find and query the table in the new session as well. Like this:
select * from my_schema.my_tbl;
Hope this would help a few.
Make sure that Table name doesn't contain any trailing whitespaces
Try this: SCHEMA_NAME.TABLE_NAME
I'd suggest checking if you run the migrations or if the table exists in the database.
I tried every good answer ( upvote > 10) but not works.
I met this problem in pgAdmin4.
so my solution is quite simple:
find the target table / scheme.
mouse right click, and click: query-tool
in this new query tool window, you can run your SQL without specifying set search_path to <SCHEMA_NAME>;
you can see the result:
Present records
{"myLabel":"AFRICANA"}
{"myLabel":"africans"}
{"myLabel":"AFRICAN"}
{"myLabel":"Africa"}
Query : `cts:json-property-word-match("myLabel", "Africa*")`
Result:
{"myLabel":"Africa"}
Query returns only match case data not all relavent rows.
Query : `cts:json-property-word-match("myLabel", "Africa*", "case-insensitive")`
Result:
your query returned an empty sequence
If I use "case-insensitive" option it returns empty sequence.
I have set word lexicons as myLabel.
How do I search for JSON data case insensitively?
Both of the examples provided return the expected results for me. Did you intend to show the second query as a search with cts:json-property-value-query()?
If that is the case, then applying the wildcarded option will ensure that values are matched case-insenstive and as a wildcarded query:
cts:search(doc(),
cts:json-property-value-query("myLabel", "Africa*", ("wildcarded","case-insensitive")))
Double check to see if you have "trailing wildcard searches" enabled, or any of the three, two, or one character searches enabled for your content database. The rules for wildcard searches state that you need specific database indexes enabled for the query to automatically apply queries with wildcard patters as a wildcarded query:
If neither "wildcarded" nor "unwildcarded" is present, the database configuration and $text determine wildcarding. If the database has any wildcard indexes enabled ("three character searches", "two character searches", "one character searches", or "trailing wildcard searches") and if $text contains either of the wildcard characters '?' or '*', it specifies "wildcarded". Otherwise it specifies "unwildcarded".
With either of those index settings enabled, a query term with a * should automatically execute as a wildcard query, and you can remove the explicit wildcarded option:
cts:search(doc(),
cts:json-property-value-query("myLabel", "Africa*", "case-insensitive"))
"Order by" query on Document DB suddenly stopped working on my development environment and is working fine without "Order by"
Here is the query which is not working (Use to work till yesterday and till yesterday it use to return me 70+ documents and now its returning null results(Empty array)):
SELECT * FROM c WHERE c.Category = 'test' ORDER BY c.StartDate DESC
Here is the query which is working(Currently its returning 70+ results and it use to return the same yesterday (which is not the case with the above query which is not working )):
SELECT * FROM c WHERE c.Category = 'test'
Did someone face the similar problem? What can be the solution for this?
I found the solution to the problem. As per the documentations:
https://learn.microsoft.com/en-us/azure/cosmos-db/indexing-policies
It clearly says
"The default indexing policy sets "kind=Hash, precision=3" by default.
If it is changed into "kind=Range, precision=-1". Order by on string
datatype works as expected."
And i found the solution here:
https://github.com/Azure/azure-documentdb-dotnet/issues/65
Here are few more links that help you know more about Document DB Indexing
https://azure.microsoft.com/en-us/blog/order-query-results-with-azure-documentdb/
https://azure.microsoft.com/en-us/blog/update-your-documentdb-indexing-policies-online/
So i have deleted my old collection and created a new one with precision "-1".
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.
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/