I have a query with a sub query in the select that needs to get a value from a certain table if it exists. I don't want to paste the query here for business reasons, but here's a simplified example of what I am trying to do:
select a, b, (select x from z) as c from table where ...
The query runs fine in TOAD, but when I go through the ASP.NET table adapter wizard in my data object, it complains about the sql statement: "Error in SELECT clause NEAR ','". I'm not sure if it would still work at runtime even though it complains? I know the preview doesn't work and it didn't create the data table. Anyone experienced this?
The reason I want to do it this way is because the query that populates field c will not always have a value but I have to return a and b even if c does not have a value. Any one good with knowledge of sql may be able to suggest a work around. I want to stick with 1 table adapter query if possible.
Outer join to table Z?
SELECT t.a,t.b,z.x
FROM table t LEFT OUTER JOIN Z ON (t.y = Z.y)
WHERE...
This will give you the values from Z if they exist, NULL otherwise.
When a tool doesn't understand a query, one method that always works is to create a view that encapsulates your query.
CREATE VIEW v AS SELECT a, b, (select x from z) as c from table
You would then use a simple query in ASP.NET like :
SELECT a, b, c FROM v where...
The view now contains your business logic and would be kept in your source control repository alongside all your other code.
Related
I am trying to add a new property to the projection of a query using: select *, 4 Type from c, but it fails with error Syntax error, incorrect syntax near ','. Trying select c.*, 4 Type from c results in a similar error: Syntax error, incorrect syntax near '*'.
Projecting all properties manually is not really an option as not all documents contain all properties (one of the best features of DocumentDb).
How can I do so?
UPDATE
What I am trying to accomplish is something very simple in any SQL Like language. Open any relational database of your choosing and execute select *, 4 Type from [Table] and the results are very straight forward: a table with all it's columns and it's corresponding values plus an additional column named Type with all rows having the same value: 4. The difference here is that in a relational database with schema all rows in the database contain the same columns, so it is easy to enumerate the columns instead of asking for *. In a schemaless environment like documentdb you can't enumerate them because there could be unlimited combinations.
I am trying to accomplish the same thing that select c.id, 4 Type from c accomplishes, but with all properties
We solved this issue by adding a User Defined Function:
function AddType (c, v) {
c['Type'] = v;
return c;
}
and calling it SELECT value udf.AddType(c,4) FROM c.
Of course you could make this a little more generic by passing in an array instead, but hopefully the Cosmos Db team will add native support for it.
WARNING
This function adds overhead and in our internal tests it more than doubled the RUs. select * from c resulted in 90 RUs vs 220 RUs using the function above.
I am working on a CR where I need to create a PL/SQL package and I am bit confused about the approach.
Background : There is a View named ‘D’ which is at end of the chain of interdependent views in sequence.
We can put it as :
A – Fact table (Populated using Informatica, source MS-Dynamics)
B – View 1 based on fact table
C – View 2 based on View1
D – View 3 based on view2
Each view has multiple joins with other tables in structure along with the base view.
Requirement: Client wants to remove all these views and create a PL/SQL Package which can insert data directly from MS-Dynamics to View3 i.e., ‘D’.
Before I come up with something complex. I would like to know, is there any standard approach to address such requirements.
Any advice/suggestions are appreciated.
It should be obvious that you still need a fact table to keep some data.
You could get rid of B and C by making D more complex (the WITH clause might help to keep it overseeable).
Inserting data into D is (most likely) not possible per se, but you can create and INSTEAD OF INSERT trigger to handle that, i.e. insert into the fact table A instead.
Example for using the WITH clause:
Instead of
create view b as select * from dual;
create view c as select * from b;
create view d as select * from c;
you could write
create view d as
with b as (select * from dual),
c as (select * from b)
select * from c;
As you can see, the existing view definition goes 1:1 into the WITH clause, so it's not too difficult to create a view to combine all views.
If you are on Oracle 12c you might look at DBMS_UTILITY.EXPAND_SQL_TEXT, though you'll probably want to clean up the output a bit for readability.
A few things first
1) A view is a predefined sql query so it is not possible to insert records directly into it. Even a materialized view which is a persistant table structure only gets populated with the results of a query thus as things stand this is not possible. What is possible is to create a new table to populate the data which is currently aggregated at view D
2) It is very possible to aggregate data at muliple levels in Informatica using combination of multiple inline sorter and aggregater transformations which will generate the data at the level you're looking for.
3) Should you do it? Data warehousing best practices would say no and keep the data as granular as possible per the original table A so that it can be rolled up in many ways (refer Kimball group site and read up on star schema for such matters). Do you have much sway in the choice though?
4) The current process (while often used) is not that much better in terms of star schema
Lets say I already have 3 columns A,B,C in my table Tb. I want to add a new column M between B and C. How can I do this ?
After adding M,my table should look like - A B M C and NOT A B C M ?
The simple answer is that you can't. Columns are always added at the end. However, you shouldn't care about the order of columns in a table since you should always be explicitly listing columns in your queries and in your DML. And you should always have an interface layer (a view, for example) where, if order is important, you can add the new column in the appropriate place.
If you are really determined, you can create a new table with the new column order, move the data to the new table, drop the old table, and rename the new table. You'll need to recreate any indexes, constraints, or triggers on the table. Something like
ALTER TABLE tb
ADD( M NUMBER );
CREATE TABLE tb_new
AS
SELECT a, b, m, c
FROM tb;
DROP TABLE tb;
ALTER TABLE tb_new
RENAME TO tb;
I'm not sure whether it's an option in the express edition (I tend to doubt it is but I don't have an XE database handy to verify) but you could also potentially use the DBMS_REDEFINITION package as Barbara shows in that example. Behind the scenes, Oracle is doing basically the same thing that is done above but with some added materialized view logs to allow applications to continue to access the table during the operation.
If you find yourself caring about the order of columns in a table, though, you're much better off stopping to figure out what you've done wrong rather than continuing to move forward on either path. It should be exceptionally, exceptionally rare that you would care about the physical order of columns in a table.
When retrieving objects in our Documentum application it takes a long time. We have activated long running query option in data source och, but have found that the below query is taking too much time:
select all
b.r_object_id, dm_repeating1_0.state_name, a.object_name
from
dm_policy_sp a,
dm_sysobject_sp b,
dm_policy_rp dm_repeating1_0
where
(
(a.r_object_id=b.r_policy_id)
and (dm_repeating1_0.i_state_no=b.r_current_state)
and b.r_object_id in (N'a long, long list of IDs')
or a.r_object_id in (N'a long, long list of IDs')
)
and /* ... */
As you can see, the table "a" is a policy table and it has only 7 records. In the SQL statement after both "or" operators, we are looking for an object_id between 100 objects in table "a"! We executed a query and searched for those objects in table "b" (systemObjects) and we found that those objects belong to table b!
The above query takes about 17 minutes. When we changed the name of table after "or" operator in table to b, it took only 10 seconds!
We suppose this query is wrong. We don't know if it is a bug in Documentum or we have configured Documentum wrong. We don't know where we can find the DQL which creates this SQL or related components? Any idea?
Looks like documentum does it inside LifecycleNameDataHandler and LifecycleDataHandlerHelper. I decompile these classes and found this DQL query
SELECT b.r_object_id, a.state_name, a.object_name FROM dm_policy(all) a, dm_sysobject(all) b WHERE b.r_object_id IN (...) AND a.r_object_id = b.r_policy_id AND a.i_state_no = b.r_current_state ENABLE(row_based)
Documentum Webtop execute this DQL query when user open any datagrid with LifeCycle state name column.
There are a few option:
Optimize query on database level and test it from DQL (dql Tester in DA and etc)
Decompile class LifecycleDataHandlerHelper and rewrite DQL query in other manner. Try to add hints like FORCE_ORDER or something else.
If you do not use Life Cycles at all, you can easy disable this class. in the file webcomponent\app.xml line com.documentum.webcomponent.library.applylifecycle.LifecycleNameDataHandler should be commented or disabled.
Delete Life Cycle State name (or State Name) from grids. Maybe users select this column in their customized grids. It is possible to advice users to delete this columns from the grids.
I don't know what exactly you want to retrieve by this query, but I think that your query might be reworked as follows:
select all
b.r_object_id, dm_repeating1_0.state_name, a.object_name
from
dm_policy_sp a,
dm_sysobject_sp b,
dm_policy_rp dm_repeating1_0
where
(
(a.r_object_id=b.r_policy_id)
AND dm_repeating1_0.r_object_id=a.r_object_id
and (dm_repeating1_0.i_state_no=b.r_current_state)
and (b.r_object_id in (...)
or a.r_object_id in (...))
)
I have recently stumbled upon a problem with selecting relationship details from a 1 table and inserting into another table, i hope someone can help.
I have a table structure as follows:
ID (PK) Name ParentID<br>
1 Myname 0<br>
2 nametwo 1<br>
3 namethree 2
e.g
This is the table i need to select from and get all the relationship data. As there could be unlimited number of sub links (is there a function i can create for this to create the loop ?)
Then once i have all the data i need to insert into another table and the ID's will now have to change as the id's must go in order (e.g. i cannot have id "2" be a sub of 3 for example), i am hoping i can use the same function for selecting to do the inserting.
If you are using SQL Server 2005 or above, you may use recursive queries to get your information. Here is an example:
With tree (id, Name, ParentID, [level])
As (
Select id, Name, ParentID, 1
From [myTable]
Where ParentID = 0
Union All
Select child.id
,child.Name
,child.ParentID
,parent.[level] + 1 As [level]
From [myTable] As [child]
Inner Join [tree] As [parent]
On [child].ParentID = [parent].id)
Select * From [tree];
This query will return the row requested by the first portion (Where ParentID = 0) and all sub-rows recursively. Does this help you?
I'm not sure I understand what you want to have happen with your insert. Can you provide more information in terms of the expected result when you are done?
Good luck!
For the retrieval part, you can take a look at Common Table Expression. This feature can provide recursive operation using SQL.
For the insertion part, you can use the CTE above to regenerate the ID, and insert accordingly.
I hope this URL helps Self-Joins in SQL
This is the problem of finding the transitive closure of a graph in sql. SQL does not support this directly, which leaves you with three common strategies:
use a vendor specific SQL extension
store the Materialized Path from the root to the given node in each row
store the Nested Sets, that is the interval covered by the subtree rooted at a given node when nodes are labeled depth first
The first option is straightforward, and if you don't need database portability is probably the best. The second and third options have the advantage of being plain SQL, but require maintaining some de-normalized state. Updating a table that uses materialized paths is simple, but for fast queries your database must support indexes for prefix queries on string values. Nested sets avoid needing any string indexing features, but can require updating a lot of rows as you insert or remove nodes.
If you're fine with always using MSSQL, I'd use the vendor specific option Adrian mentioned.