I am completely new to QlikView and I have been given the task to add a new field to a QlikView Report. The Report is fed from an Oracle View, and whilst I have easily added the field to the View, I am completely at sea as to how I get QlikView to then add this new field where the outcome is simply displayed in a table on the UI.
Does anyone have any experience with this?
Find the place in the Qlik script where the data is loaded from the View. Add the new field to the rest of the fields.
It depends how the script is written but few possible examples:
In this example all fields are loaded from the view. Nothing to be added just reload the script and the field will be available in the UI
MyTable:
SQL Select * From MyView;
Specific fields are loaded from the view. Just add the new field and reload
MyTable:
SQL Select
Field1,
Field2,
Field3
...
From MyView;
specific fields are loaded from the view and then only subset of fields are exposed to the data model/UI. In this case you'll have to add the field in both places - sql part and above it
MyTable:
Load
Field1,
Field2
...
;
SQL Select
Field1,
Field2,
Field3
...
From MyView;
The above examples are covering the cases where no additional manipulations are made on the data. Its quite common to load the raw data (from the view) and then use the result table in later stages in the script. This highly depends on your data, data model and requirements. In this case you'll have to trace the usage of the raw table and add the field in the result tables. For example:
RawData:
SQL select
Field1,
Field2
from MyView;
//... some other script
FinalTable
Load
Field1,
Field2
Resident
RawData;
join
Load * From SomeOtherQlikTable;
Drop Table RawData;
As you can see RawData is a temporary table that is dropped at the end of the script. In this case adding the field only to RawData table will not bring the field to the data model at end. And you'll have to add the field to FinalTable as well
Related
Probably a simple answer, but assume I have a table with 3 columns:
ab, cd, ef
I create a new view
SELECT *
FROM tbl
It works. I save the view, SSMS automatically changes the saved version of the view to say:
SELECT dbo.tbl.ab, dbo.tbl.cd, dbo.tbl.ef
How do I keep the saved version of the view to include all columns in tbl rather than explicitly identifying each column?
You can create the view like this:
CREATE VIEW vwTbl
AS
SELECT *
FROM tbl
Then you can query the view to retrieve all columns like:
SELECT * FROM vwTbl
I want to create a table that will hold its currents rows and add new ones for each month but didn't find how to join the table with itself to get what I want.
Today I have a table with "current_records" from february
and a create table statement that get my values from february and do an union on another "current_month_table" to join all my records on a "all_records_table" so I get all my february+march records. But I don't want to create a new table for each month.
Tomorrow I'll want to have my "current_month_table" to list the april results and to append them to the existing "all_records_table" results.
I checked there Create SQL table with the data from another table as it seemed to provide good advice but I didnt get it to work.
CREATE TABLE `/Users/SQL essais/current_month_table` as c_m_t
INSERT INTO `/Users/SQL essais/all_records_table`
SELECT
*
FROM `/data`
the result was a full replacement of the data from current_month_table by the data from all_records_table where I wanted the data to go the other way around (and not replacing but adding rows).
Sounds like you just need an Insert-Select.
INSERT INTO all_records_table (Field1, Field2, Field3)
(SELECT Field1, Field2, Field3
FROM current_month_table)
You can add whatever joins and filters you need in the Select statement.
If you need more information, post additional examples of the data that is in the tables.
If I put new column or new value on rows, does it change the data on the database that I'm using to query the data? Let's say I have database 'A' and I'm working with table 'B'. Then, if I decide to put a new column on table 'B', will this also change the whole table 'B' from database 'A'? Or will this only show on the result tab, without changing the real data?
DDL makes changes to database. Like if you are doing
ALTER TABLE table_name
ADD column_name datatype
Yes, it will update in database.
As you mentioned you just started learning so possibly you are fetching records in new column while selecting. Like
SELECT table_name.column + table_name.column2 AS new_column_name, table_name.column, table_name.column2
FROM table_name
In above case it will not make any change in database.
When extracting data from a table (schema and data) I can do this by right clicking on the database and by going to tasks->Generate Scripts and it gives me all the data from the table including the create script, which is good.
This though gives me all the data from the table - can this be changed to give me only some of the data from the table? e.g only data on the table after a certain dtmTimeStamp?
Thanks,
I would recommend extracting your data into a separate table using a query and then using generate scripts on this table. Alternatively you can extract the data separately into a flatfile using the export data wizard (include your column headers and use comma seperators with double quote field delimiters).
To make a copy of your table:
SELECT Col1 ,Col2
INTO CloneTable
FROM MyTable
WHERE Col3 = #Condition
(Thanks to #MarkD for adding that)
We've got a view that's defined like this
CREATE VIEW aView as
SELECT * from aTable Where <bunch of conditions>;
The "value" of the view is in the where-condition, so it is okay to use a Select * in this case.
When a new column is added to the underlying table, we have to redefine the view with a
CREATE OR REPLACE FORCE VIEW aView as
SELECT * from aTable Where <bunch of conditions>;
as the Select * seems to get "translated" into all the columns present at the time the view is (re-)defined.
My question: How can we avoid this extra step?
(If the answer is dependent on the RDBMS, we're using Oracle.)
I know you specified Oracle, but the behavior is the same in SQL Server.
One way to update the view with the new column is to use:
exec sp_refreshview MyViewName
go
Of course, I also agree with the other comments about not using a SELECT * in a view definition.
This extra step is mandatory in Oracle: you will have to recompile your view manually.
As you have noticed, the "*" is lost once you create a view:
SQL> create table t (id number);
Table created
SQL> create view v as select * from t;
View created
SQL> select text from user_views where view_name = 'V';
TEXT
-------------------------------------------------------
select "ID" from t
You should not be using * in your views. Specify the columns explicitly.
That way you are only retrieving the data you need, and thus avoid potential issues down the road where someone adds a column to a table that you do not want that view to return (e.g., a large binary column that would adversely impact performance).
Yes, you need to recompile the view to add another column, but this is the correct process. That way you avoid other compilation issues, such as if the view reference two tables, and someone adds a duplicate column name in one of the tables. The compiler would then have issues determining which of the columns was being referred to if you did not prefix a reference to the column with a table alias, or it might complain if there are duplicate column names in the results.
The problem with automatically updating views to add columns comes when you extend your model, for example to
SELECT a.*, std_name_format(a.first_name, a.middle_names, a.last_name) long_name
or even
SELECT a.*, b.* from table_a a join table_b b....
If you have a view of just SELECT * FROM table, then you probably should be using a synonym or addressing the table directly.
If the view is hiding rows (SELECT * FROM table WHERE...), then you can look at the feature variously known as Fine Grained Access Control (FGAC), Row Level Security (RLS) or Virtual Private Database (VPD).
You might be able to do something with a DDL trigger but that would get complicated.