After Changes in the Structure of the Data Source QlikView does no further Actualization - who can help?

[bettina13]

In our Data Warehouse a new field was added.

After that I can run QlikView-Skripts which use the correspondent table, but the objects are not actualized any more. There is no error message at all.

I tried to copy the script and the objects in a new QlikView-Document, but that doesn't help.

I have to rebuild the whole script and to copy the objects to get actual data.

Has anyone an idea to manage that situation?

Thanks

Bettina

[hic]

It is impossible to say from the information you give. Information that could be useful are things like:

Does the script run OK against the "new" Data Warehouse? Are fields loaded at all? Are the fields that are loaded named differently from the old DW? (For example upper case/lower case.) Do you use the variable "ErrorMode" in the script? How do the object properties look? Does it look like in the picture below, with the field "unavailable"?

HIC

[bettina13]

Hi Henric,

thanks for your answer.

Yes, script runs o.k., no error message. But the number of rows read from the table concerned stays the same. It should increase.

New fields were added, but no name of a given field is ever changed.

I don't use the variable "ErrorMode".

The object properties do not change. All fields are available.

Perhaps it is also important to know, that the content of the Data Warehouse (SQL-Database) is always deleted by the ETL-process and is filled again; whether there is a change in the datamodel or not.

Bettina

[hic]

You write "the number of rows read from the table concerned stays the same. It should increase." This is a warning sign to me.

First of all, do you make a full reload? Or a partial reload? You should make a full reload.

When you run a full QlikView reload, QlikView starts by erasing the internal database. So, the fact that QlikView then loads exactly the same number of records again is to me a sign that it doesn't load from the correct data source. Check the connect statement.

You can also create a completely new app from scratch (don't copy and paste), but with just a connect string and one single SELECT to see how many records you get. If the number is different from the old app, then you most likely have two different connect statements.

HIC

[bettina13]

Hi Henric,

I have already tried all these things.

I always make a full reload.

I connected again and also tried another ODBC-Connection to the same Database.

I built a new document to test the number of records I get. I got all I wanted.

And this problem didn't happen once. It happens systematically with all Qlikview-Documents, which uses Tables with new fields.

Do you have another idea?

[hic]

Then there must be a difference in the scripts of the two cases. The fact that a table gets new fields should not affect anything - as long as the old ones are there also.

Can you post a file that gets the correct data and one that doesn't? Or at least the scripts of the two?

HIC

[bettina13]

Here are the two scripts.

[hic · Accepted solution]

There are some differences in the scripts that could cause these problems:

• Line 66: The two files have connect statements that use different users. Different rights, perhaps?
• Line 73-74: The two files have SELECT statements that different databases. The old uses "MICOS_DW.DW" and the new use "MICOS_DW_PROD.DW".

I would check these first, before going on. In addition, you use different definitions for the Access rights:

• Section Access: In the old you load "FK_VW as ACCESS" and in the new you load "FK as ACCESS"

HIC

[bettina13]

Thank you very much - the "From"-Line was the problem.

So it just would be nice, if QlikView would give an error massage, when selecting records from a database without having connected it.

[hic]

QlikView does not evaluate the SELECT statement. It is just sent to the ODBC driver, and the ODBC driver returns a table. So QlikView does not "know" that the table comes from another database. Hence, no error message is possible.

What you could do, is to replace the table name in your SELECT:

... FROM MICOS_DW_PROD.DW.MDAT_FIBU_FIRMA

will load from the database specified. I.e. it could be any database. But

... FROM MDAT_FIBU_FIRMA

will load the same data, but always from the default database (as specified in the ODBC data source). If the table isn't found, it will return an error message.

HIC