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:
I am working on a system where I need to create a view.I have two databases
1.CDR_DB
2.EMS_DB
I want to create the view on the EMS_DB using table from CDR_DB. This I am trying to do via dblink.
The dblink is created at the runtime, i.e. DB Name is decided at the time user installs the database, based on the dbname dblink is decided.
My issue is I am trying to create a query like below to create a view from a table which name is decided at run time. Please see below query :
select count(*)
from (SELECT CONCAT('cdr_log#', alias) db_name
FROM ems_dbs a,
cdr_manager b
WHERE a.db_type = 'CDR'
and a.ems_db_id = b.cdr_db_id
and b.op_state = 4 ) db_name;
In this query cdr_log#"db_name" is the runtime table name(db_name get's created at runtime).
When I'm trying to run above query, I'm not getting the desired result. The result of the above query is '1'.
When running only the sub-query from the above query :
SELECT CONCAT('cdr_log#', alias) db_name
FROM ems_dbs a,
cdr_manager b
WHERE a.db_type = 'CDR'
and a.ems_db_id = b.cdr_db_id
and b.op_state = 4;
i'm getting the desired result, i.e. cdr_log#cdrdb01
but when i'm trying to run the full query, getting result as '1'.
Also, when i'm trying to run as
select count(*) from cdr_log#cdrdb01;
I'm getting the result as '24' which is correct.
Expected Result is that I should get the same output similar to the query :
select count(*) from cdr_log#cdrdb01;
---24
But the desired result is coming as '1' using the full query mentioned initially.
Please let me know a way to solve the above problem. I found a way to do it via a procedure, but i'm not sure how can I invoke this procedure.
Can this be done as part of sub query as I have used above?
You're not going to be able to create a view that will dynamically reference an object over a database link unless you do something like create a pipelined table function that builds the SQL dynamically.
If the database link is created and named dynamically at installation time, it would probably make the most sense to create any objects that depend on the database link (such as the view) at installation time too. Dynamic SQL tends to be much harder to write, maintain, and debug than static SQL so it would make sense to minimize the amount of dynamic SQL you need. If you can dynamically create the view at installation time, that's likely the easiest option. Even better than directly referencing the remote object in the view, particularly if there are multiple objects that need to reference the remote object, would probably be to have the view reference a synonym and create the synonym at install time. Something like
create synonym cdr_log_remote
for cdr#<<dblink name>>
create or replace view view_name
as
select *
from cdr_log_remote;
If you don't want to create the synonym/ view at installation time, you'd need to use dynamic SQL to reference the remote object. You can't use dynamic SQL as the SELECT statement in a view so you'd need to do something like have a view reference a pipelined table function that invokes dynamic SQL to call the remote object. That's a fair amount of work but it would look something like this
-- Define an object that has the same set of columns as the remote object
create type typ_cdr_log as object (
col1 number,
col2 varchar2(100)
);
create type tbl_cdr_log as table of typ_cdr_log;
create or replace function getAllCDRLog
return tbl_cdr_log
pipelined
is
l_rows typ_cdr_log;
l_sql varchar(1000);
l_dblink_name varchar(100);
begin
SELECT alias db_name
INTO l_dblink_name
FROM ems_dbs a,
cdr_manager b
WHERE a.db_type = 'CDR'
and a.ems_db_id = b.cdr_db_id
and b.op_state = 4;
l_sql := 'SELECT col1, col2 FROM cdr_log#' || l_dblink_name;
execute immediate l_sql
bulk collect into l_rows;
for i in 1 .. l_rows.count
loop
pipe row( l_rows(i) );
end loop;
return;
end;
create or replace view view_name
as
select *
from table( getAllCDRLog );
Note that this will not be a particularly efficient way to structure things if there are a large number of rows in the remote table since it reads all the rows into memory before starting to return them back to the caller. There are plenty of ways to make the pipelined table function more efficient but they'll tend to make the code more complicated.
I am using documentum data storage and and I have an object table called dm_user . I can fetch data from the table by running a DQL query like :
select * from dm_user where user_name = 'dkfloza'
However when I run a query to update my table such as :
update dm_user set user_email = 'dkfloza#gmail.com' where user_name ='dkfloza'
I recieve an error saying that :
the table is not registered or you do not have access to it
The correct syntax for DQL update in this case is:
UPDATE dm_user OBJECT
SET user_email = 'dkfloza#gmail.com'
WHERE user_name = 'dkfloza'
If you do not provide OBJECT, the parser thinks that you are trying to update a registered table instead of an object.
Please note: DQL does not deal with tables directly (apart from registered tables, which is an exception to this rule). Instead, it deals with objects. Objects consist of several tables that are joined together automatically by the Documentum Content Server. Therefore it is incorrect to state that you have a row in a table called dm_user. Instead, you should say that you have an object of type dm_user.
I am trying to grant admin, i.e. "monetdb" privileges to users, without any success so far (the privileges should extend to all the tables of the sys schema).
As I have a schema with many tables would be very complex to give explicit rights (e.g. SELECT ) to all the users mentioning all the tables: I need to find an efficient way to do this.
I log into MonetDB with SQLWorkbenchJ using the superuser monetdb.
I have also tried to directly send queries using R and the MonetDB.R package (with no difference).
I create a user associated to a schema (e.g. the sys schema) as
CREATE USER "user1" WITH PASSWORD 'user1' NAME 'user one' SCHEMA "sys";
Then I try to GRANT "monetdb" privileges to user1
GRANT monetdb TO "user1";
And I do not get any error.
If I log into MonetDb as user1 and try a simple select (on a pre-existing table of the sys schema) I get:
SELECT * FROM sys.departmentfunctionindex
SELECT: access denied for user1 to table 'sys.departmentfunctionindex'
Clearly I'm missing something.
Any suggestion is welcome.
I think I get it now.
The following works, using SQLWorkbenchJ I log into MonetDB as monetdb (superuser).
I run:
CREATE USER "user20" WITH PASSWORD 'user20' NAME 'user 20' SCHEMA "sys";
CREATE SCHEMA "mschema" AUTHORIZATION "monetdb";
CREATE table "mschema"."mtestTable"(v1 int, v2 int);
INSERT INTO "mschema"."mtestTable" VALUES (4, 4);
GRANT monetdb to "user20"; -- this gives implicit superuser powers to user20 (but not for the "sys" schema)
Now I log out and login again as user "user20".
I run:
SET SCHEMA mschema; -- I was missing this before but it is essential
SET ROLE monetdb;
At this stage user20 has got all the authorisations of the superuser monetdb, e.g.:
SELECT * FROM "mschema"."mtestTable"; -- can use select
DROP TABLE "mschema"."mtestTable"; -- can use drop etc.
Thanks to #Hannes, #Ying & #Dimitar
Here is an working example for granting SELECT privileges to a separate user with MonetDB:
as admin (e.g. monetdbaccount)
CREATE SCHEMA "somedataschema";
CREATE TABLE "somedataschema"."somepersistenttable" (i INTEGER);
INSERT INTO "somedataschema"."somepersistenttable" VALUES (42);
CREATE USER "someuser" WITH PASSWORD 'someuserpass' NAME 'someusername' SCHEMA "sys";
GRANT SELECT ON "somedataschema"."somepersistenttable" TO "someuser";
CREATE SCHEMA "someuserschema" AUTHORIZATION "someuser";
ALTER USER "someuser" SET SCHEMA "someuserschema";
Now, someuser can SELECT from somepersistenttable, but not modify it. Should this user need a table on its own, someuserschema or temporary tables (deleted when user logs out) could be used. Hence, this works:
SELECT * FROM "somedataschema"."somepersistenttable";
CREATE TABLE "someuserschema"."sometemptable" (i integer);
INSERT INTO "someuserschema"."sometemptable" VALUES (84);
SELECT * FROM "sometemptable";
CREATE TEMPORARY TABLE "sometemptable" (i INTEGER) ON COMMIT PRESERVE ROWS;
INSERT INTO "sometemptable" VALUES (42);
SELECT * FROM "sometemptable";
And this will produce an insufficient privileges error (same for update, drop, alter etc.):
INSERT INTO "somedataschema"."somepersistenttable" VALUES (43);
Please have a look at this MonetDB bug report. Grant privilege works for user created schemas, but the bug-fix seems not cover the default "sys" schema.
No, you don't have to explicitly grant access to each individual tables. You can still use GRANT monetdb to "user1". See my previous answer, for now, you just need to create your tables under a user created schema. I just tried it in the "default" branch of MonetDB.
Setting my var:
Foo = request("Bar")
Building SQL Query:
John.Source = "SELECT ID, Name FROM dbo.USER where Name = '"&Foo&"' and ID = '1'"
I found this in someones project, does this open the door for SQLi ?
Absolutely. request("Bar") will take parameters off the Request.QueryString or the Request.Form collection.
This means that you can in theory tag the following onto the querystring:
'; delete * from dbo.USER; select * from user where name='
Which will give you a query of
SELECT ID, Name FROM dbo.USER where Name = ''; delete * from dbo.USER; select * from user where name='' and ID = '1'
As one of the commenters said, use parameterized queries instead.
If this really isn't an option then be sure to escape values obtained from the Request collection. This link may help: http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx
Yes it is. You need to sanitise the value before inserting it into the query like that. Or use parameterised queries, which is a safer option.