When using Postgres through the psql command line client, you can use tab completion in the WHERE clause. For example, a "users" table with an "email" and "age" column, you could type:
SELECT age FROM users WHERE em<TAB>
Would give you
SELECT age FROM users WHERE email
However, this doesn't work in the SELECT clause. Typing:
SELECT em<TAB>
does NOT give you
SELECT email
Of course it doesn't work because it doesn't yet know what table to peer into for the the tab completion, but is there some way to do this? I tried switching the order of the sql statement to
FROM users SELECT em<TAB>
But that neither works, nor appears to be a legal SQL statement (it throws an error when executing).
No, there is no way to do this in psql. But is supported in some IDE, i.e. https://www.jetbrains.com/idea (only ultimate edition) and valentina db studio. (I only use Intellj Idea - and psql :) - and don't know other IDEs but probably this feature is supported by the most IDEs).
Related
I have queries created in Microsoft Query to run in Excel with VBA.
They work in different computers but there's one computer where it doesn't work.
In that computer the queries still work except the ones that use CTEs.
A normal query like the following works:
SELECT
TBL.COL
FROM
DB.TBL TBL;
But when it has a subquery (CTE) like the following:
WITH
SUBQUERY AS (
SELECT
TBL.COL
FROM
DB.TBL TBL
)
SELECT
SUBQUERY.COL
FROM
SUBQUERY;
It runs but doesn't retrieve any data.
It doesn't even show the column name like it would if it worked but had 0 records returned.
The query shows the warning message:
SQL Query can't be represented graphically. Continue anyway?
Which is normal and shows in any computer, but it also shows another warning message after:
SQL statement executed successfully.
Which only appears in that computer when it doesn't work.
I need to be able to use them for the queries that I have made.
Using temporary tables would maybe work but I don't have the permissions required to try.
I tried using inline views but they duplicate the data.
I have queries created in Microsoft Query to run in Excel with VBA.
... but there's one computer where it doesn't work.
Common table expressions (i.e., the WITH clause) were not introduced until release 9 of the database. Since ODBC is involved (Microsoft Query), the most likely reason for your situation is that the computer that does not work has an out-dated (pre-release 9) version of the Oracle Client installed.
Compare the Oracle Client installations between a client computer that works and one that does not, to find whether this is the case. If it is, upgrade the Oracle Client on the problematic machine.
I think you can use...
SELECT
SUBQUERY.COL
FROM
(
SELECT
TBL.COL AS COL --or (TBL.COL COL) or ( COL ) #if not duplicate with any
FROM
DB.TBL TBL
) SUBQUERY;
I'm coming from a MS SQL background using SSMS. I just recently started using Oracle / Toad at a new company and I'm finding it to be a bit finicky.
One of the things that I use to do in SSMS was select 2 queries, and then execute the statement and see the results for both.
When I attempt to run the following queries
select count(*) from table1;
select count(*) from table2;
I get the following error message back: ORA-00933: SQL Command not properly ended
Is there something in particular that I'm not doing correct?
In your tool, hit F5, you'll get your results as a script for both queries.
In the free, official GUI for Oracle Database, you can do this:
As Barbaros Özhan notes, you'll need to fix your queries first. You need to do a count() on SOMETHING - * will work.
You need to include some literal like 'x', or a symbol like * or a number 1 inside count function like count(1) or count(*) or count('x').
In your case, one of these missing operators causes ORA-00933.
The answer apparently was the button that I was selecting in Toad for Oracle / slightly incorrect SQL statement.
I was hitting the "Execute / compile statement at caret" button instead of the "Execute Script As" button.
Selecting the wrong button in Toad
In Microsoft SQL Server Management Studio (SSMS), you can right-click on a table, then go to Script Table as -> SELECT To, and then choose a destination for the generated script.
Is there anything similar in DataGrip, or can one be custom created in some way?
The reason I find this useful is because I often find that I'm working with a table with a lot of columns, and I want to select all but a few of them. So it's easier to just have it generate the SELECT statement with all the columns explicitly listed out, so that I can just go through and delete the ones I don't want.
Currently, my workaround in DataGrip is to right-click the table, then choose Copy DDL. This generates the CREATE TABLE statement, which lists out all the columns, but it also includes the column definitions. So I have to do a regex replace or run a macro to get rid of the extra info, which is kind of a pain. Does anyone have a better solution?
In DataGrip as other intellij-based IDEs everything is about source editing. So that can be achieved that way:
Open console
Start typing sel, you'll get completion popup (if not, hit Ctrl+Space)
Select sel here, which is live-template for select statement
Select statement will be generated, asking for table name and column list
Select desired table from completion, as column list provide *
Then hit Alt+Enter on asterisk and select Expand column list
I suggest you to look through https://www.jetbrains.com/datagrip/features/
In DataGrip 2018.3 you can use postfix completion. This is the flexible way to get needed queries.
Try typing
SELECT %table_name%.from
SELECT %table_name%.afrom
SELECT %table_name%.join
And this will be expanded to the needed queries. In the case of from completion you'll be able to write columns.
This makes writing SQL more logical: first, you point table, then columns.
See gif:
Can anybody tell me what does the error mean? Whenever I open the query builder it will prompt with an error indicating that SQL syntax errors were encountered.
https://msdn.microsoft.com/en-us/library/ms189012.aspx
I looked at the following page in MSDN but I don't understand what it means...
For instance, what do these bullet points from the MSDN article mean?
The SQL statement is incomplete or contains one or more syntax errors.
The SQL statement is valid but is not supported in the graphical panes (for example, a Union query).
The SQL statement is valid but contains syntax specific to the data connection you are using.
USER (which you've apparently decided is an appropriate table name) is a SQL Server reserved word.
The best solution is to rename your table, so you don't have to escape the table name every time you want to query it and to make it clear it's your user data (hey, there's a table name suggestion - userdata).
The other option is to escape the name by surrounding it with square brackets:
SELECT * FROM [users]
Note that it will get old fast having to do this with every query. Again, the best solution would be to rename the table to something that isn't a reserved word.
Access 2007 databases querying linked oracle 10g tables are returning flawed result sets when using the WHERE clause to filter-out unwanted records. Oddly, some filtering is happening, but not reliably.
I can reliably demonstrate/produce the problem like this:
Create a *new* database with Access 2007.
Create a second *new* database with Access 2007, and then "save-as" 2000.
Create a third *new* database with an older version of Access.
Run the following query in each database:
SELECT
STATUS,
ID,
LAST_NAME,
FIRST_NAME
FROM
Oracle10g_table
WHERE
STATUS="A"
In both databases created with Access 2007, running this query will give you a result set in which some of the records where (STATUS="A") = false have been filtered out, but not all of them.
In databases created with older versions of access, the where clause filters properly, and the result set is correct.
STATUS is a text field
The table is a "linked" table to an Oracle10g Database
The table has 68k rows
I've tested my timeout at 60, 1000 and 0
Has anyone run into this problem?
I wonder if this is a new "feature" of access that will also affect 2010. Could this have anything to do with ODBC?
Thanks for any help,
- dave
MORE...
I just tried an alternate form of the query, using HAVING instead of WHERE, and it worked! Problem is, besides that this shouldn't change anything (yes -- more virtual tables, but shouldn't change the end result) my end-users will be using the Access 2007 visual query designer, not typing SQL directly, which is going to default any criteria they enter into a WHERE.
My hunch is that one of your ODBC drivers used by Access to connect to Oracle is treating "A" as a column name not the literal 'A'. Have you tried single quotes on the 'A'? In Oracle double quotes are used to reference column names, is there a column named "A" by any chance?
Oracle Query Example #1
Select object_name from all_objects
where "OBJECT_NAME" = 'DUAL'
Oracle Query Example #2
with example as (
Select object_name as "Fancy Column Name" from all_objects
)
select * from example
where "Fancy Column Name" = 'DUAL'
I've had a similar problem. In my case, changing the ODBC driver worked, but I could also just change the 'unique record identifier' to a column with no nulls in it. It still doesn't have to be the "right" unique record identifier.
This turned-out to be an ODBC-related issue. Our tech support service unit installs connectivity on each of our workstations -- they program it themselves, and who knows what they actually put into it -- but the net result is that when you link to an ODBC datasource with Access (of any version), our network servers show-up in the 'machine data source' tab, so we just click on the one we want and away we go. This has worked well until Access 2007.
What I did was create a "new" machine data source, which let me choose the ODBC driver myself (instead of making me use the one our tech support folks created). I picked "Microsoft ODBC for Oracle", entered the name of the server I wanted, and that all it took. Now the WHERE-clause inconsistent filtering problem is solved (I hope).
The only thing remaining is to send this back to our tech support folks, so they can clean-up their installation. Should I ask for hazard pay? :-) hehe