Error mode qlikview

Error Handling – Any system needs application or logic to handle error, the same logic is applicable to Qlikview…

This document is general overview and guideline around Qlikview Error Handling, suggesting best practices and providing some sample existing functions to achieve it, In brief document covers following functional areas:

1. Overview to Qlikview Error Handling
   
2. Customizing default Qlikview behaviour on encountering error
   
3. Defining exceptions – information, warning or errors
   
4. Defining Custom behaviour and application specific error messages
   

Qlikview Error Handling

Qlikview scripting allow error handling primary using Qlikview ErrorMode functions, where Value of ErrorMode defines, what type of behaviour application will have. Primary following are main ErrorMode values are used

Code in development should have always ErrorMode=1, Production Environment (batch modes) generally have value as 2, or in specific scenarios it can have 0 also…

Note:
Setting variable ErrorMode = 0 ignores any error and continue to next code syntax, but return code from that script will be non-zero(failure), so generally in batch event, where return code of a Qlikview is required to trigger the next job, it will create an issue.

Defining Exceptions – Information, Warning or Errors

Now based on the business functionality, any processing issue can be termed as Information/Warning or Error; these are further classified down as:

1. System Generated Errors
   

2. Custom
   

   1. Warning – Generally overriding System Error
      
   2. Errors – Errors Generated at specific event
      

Custom Messages

Warning:

Generally these are the errors, which are not business critical, but needs to be reported/logged

Example

Generally critical production system has BCP features(hot/cold), which means once primary system is down, secondary becomes operation and accessible. Certain organization had Production system copy/backup, but no automated BCPing(or failover) process, So Once Primary system is down, application accessing the primary application has to now access new application, generally different location/credential

Flow Logic

So in the above case, Qlikview ignores error messages, when system1 does not respond and continues to next system2, thus overriding default Qlikview behaviour of failure

Custom Error:

In the same process flow, there is section “Data validation fails” – This section can be used to check a number of business logics – like number of rows, %change in volume more than a threshold and based on that process can decide to action according

Assuming, if both systems are responding fine, but number of rows returned is zero, so in this case it is not a system error, but a processing error and hence require a custom errors

Attached external library:

Sample error library, which can be used to achieve and experiment certain standard process behaviour. These files can be customized for specific application/group to cater delivery of customized messages/warning or errors

Other useful areas from application

1. Set Statement used to execute a complete function – ERRORLOG

Сегодня, в этой статье, мы поговорим о системных переменных по работе с ошибками «Error Variables» и о том, как и где их можно использовать в своем приложении.

В Qlik Sense и QlikView «ErrorVariables» доступны для:

1. Определения, какие действия следует предпринять, если во время выполнения сценария возникает ошибка
2. Предоставления информации об ошибках, возникающих во время выполнения сценария

В этой статье мы рассмотрим следующие четыре переменные «ErrorVariables»:

1. ErrorMode
2. ScriptError
3. ScriptErrorCount
4. ScriptErrorList

Из этих 4 переменных, только одна переменная ErrorMode является переменной, задаваемой пользователем. Эта переменная определяет, что должно произойти, если во время выполнения скрипта возникает ошибка. Эта переменная устанавливается в скрипте следующим образом:

Переменная ErrorMode может принимать одно из трех значений: 0, 1 или 2. По умолчанию, переменная ErrorMode устанавливается в значение 1. Это означает, что при возникновении ошибки при выполнении скрипта скрипт остановится и предложит пользователю выполнить действие. Если для переменной ErrorMode установлено значение 0, то ошибка будет проигнорирована, и выполнение скрипта будет продолжено. Если для параметра ErrorMode установлено значение 2, сценарий завершится с ошибкой и остановится. Переменная ErrorMode должна быть установлена в начале сценария или перед секцией скрипта, где вы знаете, что могут возникнуть ошибки, которые вы хотели бы обработать особенным способом. Как только параметр ErrorMode будет установлен, он останется прежним, если переменная ErrorMode не будет перезагружена / изменена позже в скрипте. Например, вы можете установить для переменной ErrorMode значение 0, если в вашем скрипте есть область, которая может вызывать ошибки, которые вы хотели бы игнорировать (не останавливать выполнение сценария). В этом случае вам может потребоваться установить ErrorMode обратно в 1, если вы хотите, чтобы в дальнейшем сообщалось о других ошибках в скрипте.

Посмотрим, как будут отображаться сообщения об ошибках, если мы запустим простой сценарий ниже, чтобы загрузить группу файлов Excel, которые начинаются с «Book». Обратите внимание, что все загружаемые файлы не включают поле «MonthlySales».

Если перед этим скриптом, переменную ErrorMode выставили в значение «0» (SetErrorMode= 0), то когда скрипт завершит свою работы мы увидим следующее:

Обратите внимание, что скрипт завершил выполнение, хотя произошла ошибка. Теперь посмотрим, что произойдет, если мы оставим значение по умолчанию (ErrorMode= 1) или установим ErrorMode= 2.

Здесь выполнение скрипта остановилось при возникновении ошибки, предоставив возможность нажать кнопку «Close», исправить сценарий и перезагрузить данные снова.

В отличие от переменной ErrorMode переменные ScriptError, ScriptErrorCount и ScriptErrorList инициализируются не пользователем, а самой системой Qlik Sense или QlikView, которые предоставляют информацию об ошибке, которая была обнаружена при выполнении скрипта. Переменная ScriptError вернет код ошибки. Список кодов ошибок и их описания можно найти в справке Qlik Sense (или QlikView). ScriptErrorCount возвращает количество операторов, вызвавших ошибку во время выполнения скрипта. Наконец, переменная ScriptErrorList возвращает список ошибок, возникающих при выполнении сценария. Если имеется более одной ошибки, они разделяются переносом строки. Эти ошибки могут быть доступны в скрипте или через пользовательский интерфейс. В скрипте вы можете просто ссылаться на переменную ScriptError, чтобы найти его значение. Например, в приведенном ниже скрипте я могу проверить код ошибки 8 («Файл не найден»), чтобы определить, отсутствует ли загружаемый файл.

Переменные «ErrorVariables» также могут быть доступны в пользовательском интерфейсе через объект «Текст и изображение» (Text & image). В измерении объекта «Text& image» просто введите знак равенства и имя переменной:

Чтобы вернуть что-то вроде этого:

Переменные «ErrorVariables» полезны и просты в использовании. Например, мы, в своих проектах, чаще всего используем ErrorMode= 0 там где мы предполагаем, что существует вероятность того, что скрипт может вернуть ошибку, которую можно игнорировать. Это также полезно, если вам нужно контролировать путь выполнения скрипта на основе ошибки. Вы можете узнать больше об ошибках в справке Qlik Sense (или QlikView).

Surprise, loading data into Qlik is not always easy. But we already know you weren’t fooled when the salesperson confidently declared, “Any trained monkey can load your data into Qlik”. As data models get more complex I find myself joining, keeping, concatenating, mapping, resident loading and dropping tables. The Qlik script logic and syntax involved is not necessarily what I would label easy. Whether we use QlikView or Qlik Sense, these are some common scripting errors and how to resolve them. Also, please remember that the Qlik Community has always been an excellent place to get help for QlikView script errors you come across.

1. Comma Management

Symptom:           All I did was comment some fields.

Likely Cause:      Forgot to delete comma from what is now the last field.

This is an error we all make. The key here is to learn to recognize it quickly from the generated error messages that don’t really explain the cause. Just like in English grammar, we need commas between field names in a list and obviously we will remove the comma after the last field. Learn the general syntax rules regarding use of colons, semicolons, quotes and commas.

2. Missing QVD Directory

Symptom:           I get a non-descript error or “Failed to open file in write mode…”

Likely Cause:      Reference to a file location that does not exist.

This QlikView script error usually occurs when we are storing a QVD to a folder location that does not yet exist. It seems to me that in older versions of QlikView, the resulting error message was pretty much blank. The new error is much better. Make a mental note to always create the QVD folder in the file system before running this command in the QlikView script.

3. Forgetting to Drop Extra Tables

Symptom:         Why do I have synthetic keys all of a sudden?

Likely Cause:      Not Dropping Tables on a resident load.

There are many times when, for whatever reason, we must load a table again from a resident load. When the field mix in the new table is slightly different because we added a field or we renamed a field, this has the potential to create a large synthetic key. So if we resident load a table and all of a sudden we have a synthetic key, we likely forgot to drop the first version of the table.

4. Neglecting to account for table concatenation

Symptom:       I lost the new version of the table.

Likely Cause:      Automatic Concatenation on resident load.

This is related to the prior situation. If we do a resident load to create a new version of the table and the table viewer completely loses the new and old versions of the table, it could send us into a panic. “What happened to my table?” What we might not remember is that when Qlik loads a new table that shares the exact same fields as a prior loaded table, the new table will be concatenated to the old table. And then because we subsequently drop the first table, there is no table left with our data. Adding a noconcatenate quickly solves the problem by telling Qlik to keep the tables separate.

5. Cross joined tables

Symptom:         My Qlik reload locked up.

Likely Cause:      Joins with no keys.

When I first encountered a “stuck” script execution window, my heart sunk. “Gee, QlikView sure is buggy.” Of course, this was not a case of Qlik being buggy. Qlik was actually working very hard to create associations between a few tables. The problem was that I had joined one table to another with a typo between what I intended to be the key fields. When using the join keyword be mindful of the fields that Qlik will identify as keys and double-check to be sure they are named exactly the same. If the fields do not match, Qlik will associate every row of one table to every row of the other. This joining process can slow down the script at best and take your server down at worst. If our script appears to stop running for more than a few minutes this is the likely cause. Either way, this was not the resulting table we were looking for. Table 1: 100,000 rows Table 2: 5,000 rows Joined table: 500,000,000 (That’s 5 hundred million. Ugh.)

6. Repeating Facts after Join

Symptom:        My joined table has more records than it started with.

Likely Cause:      Left joining with repeating keys

I find this to be a data error that is very common and overlooked by many developers. Picture a transaction table where we simply want to left join the Customer Name into. This seemingly harmless action unfortunately might inflate the actual transaction expressions in our dashboard. This is because if a Customer ID from the right table has any repeats, the resulting table will add those repeats to the transaction table. If the right table has no repeated keys, then we are fine. But when doing such an action, use the lastvalue function with a group by or similar function to ensure you are only taking one ID. Whatever you do, please do not rely on a distinct qualifier with the left join as we will accidentally remove some records from the left transaction table as well because the resulting table will also take on the distinctiveness. Checking for row counts in the table viewer before and after our joins is a good way to check the row counts.

Qlik Freak came up with another list of gripes that are also extremely funny so check that out. Surely, we are just scratching the surface of the QlikView script errors that can occur. But if we understand these basic pitfalls, we are in a state to better deal with any script or data error that we might run across. What Qlik script errors have plagued your coding?