SR11 introduces two changes to error handling that you should be aware of.
The first change is that syntax errors marked with the “red squiggle” in the expression editor will always generate a status message of “Errors in expression”. This was not the case prior to SR11.
In SR10 and prior there could be a difference of opinion between the red squiggles and the status message. Valid syntax such as this–
SR10
in SR10 could be marked with squiggles but the “Expression OK” message would reassure us that this was just a syntax checker bug.
In SR11 the status message will always be “Errors in expression” when a red squiggle appears — even when the syntax is valid.
SR11
This applies as well to the very common squiggles that appear when using set expressions with variables. Again, this is a functional expression:
SR11
So now the squiggles and the status message are in alignment. I’m not sure this is a good thing. We can no longer say “Ignore the squiggles. If it says ‘Expression OK’ then it’s fine”. If this change sticks then we will have to get more aggressive about reporting and fixing syntax checker bugs.
The second Error Handling change you should be aware of is documented in the SR11 release notes. Charts that contain invalid expressions will now fail to render. In SR10 they assumed some sort of default and the chart was rendered. This new behavior applies to chart expressions, dimension attributes and expression attributes such as Text Color. If any of those expressions are in error, you will get various error messages in the chart frame. I don’t understand the pattern of the messages yet.
The good news is that this behavior is not implemented in Server until you explicitly turn it on with a Server Settings.ini switch. By default, Server charts will continue to render as they did in SR10. When you turn the setting on, the Server will log the “bad charts” to the event log. Unfortunately, the logging does not happen until you activate the new behavior. This means your logs and your users see the problem at the same time. Pity we can’t log before we turn the option on.
So what’s the combination of these two changes? If the syntax checker declares a perfectly good expression to be bad will the chart render? Yes, it will render. The syntax checker’s opinion and the actual evaluation of the expression are not connected.
I’m still trying to understand how these changes will affect my customers and I am holding off recommending SR11 until I can experience a few upgrades. If you have some experience good or bad with these changes please leave a comment.
-Rob
Thanks Rob, this is very helpful. There are also some major issues in the chart properties UI. So, I agree to hold SR11.
This is bad news. But it is better to know and write correctly, than to lose customers.
Some of the syntax error bugs are ridiculous, and I have become totally blind to red underline in expressions now as it is often more misguiding than helpful. Whilst I can kind of see it with variables, the set analysis syntax of *= always throwing an underline is crazy. Especially as I think that *= is generally what you want to use rather than a straight = anyway.
Takes deep breath…
We shall have to see how this pans out in practice.
Rob
Thanks for the warning.
We hold our database connections externally and use dollar expanded variables populated from them for all database connections, and they “red squiggle” the next script line.
So if my understanding of your blog warning is correct SR11 would make all our QlikView QVD generators System Dead.
Rob,
Thanks averting my panic there. I have now re-read your blog post properly.
Bill
Bill,
This change will not impact your QVD generator scripts. The change applies only to the UI expression editor. Further, as I noted in the second to last paragraph of the post, “Errors in Expression” from the syntax editor does not prevent a valid expression from executing.
Anyone ever used P() in set expressions. Everything after it always fails the syntax checker despite being perfectly valid. So a massive THANK YOU Rob – will definitely hold off on the upgrade.
Qlik are due a stupid update now anyway…SR5, then SR8 now SR11… Pretty much true to form 🙂
Thank you, Rob. Qlik should’ve been made the dollar-sign expansions a part of syntax, rather than just allowing blatantly pasting them in various, sometimes unexpected places. But even in this case they could’ve implicitly inserted actual values of variables into expressions before syntax checking — first, usually variables inserted in expressions contain valid syntax elements that would make entire expression correct. Second, if such a variable contains incorrect syntax elements then syntax checker would show the squiggles which again would be helpful as it indicates that the expression is wrong. In the worst case it would be just what it is now.
This has just become a bit more interesting with the security fix announced yesterday. It would look like upgrading has now become the more sensible path?
@Steve, Interesting yes. The security vulnerability applies to all SR levels, so I imagine many sites will feel compelled to upgrade. And they will acquire these error handling changes as part of the package.
I’ve been using SR11 for a couple weeks and have found that I now just tune out the “Error in expression” messages.
Like with getcurrentfield(group), it’s been happening since ever, but do the give a dime? I mean QlikTech.
@Steve ..and still the old annoying problem that no fix branch exists! Is this software? Why in the world deliver new features (including new bugs) with a SERVICE release?
At the last Qlik Dev Group event Qlik let us see their intentions on this. They will have parallel branches running for bugs and services (finally!) It was a little confusing though so we’re hoping for more clarity tomorrow night. Couldn’t quite tell how and when the streams would merge….watch this space though!
On Qonnections they said this is coming for Sense. But I guess not for QlikView..
Hi Rob/All
Error Handling in general script works fine as mentioned . Is there any way in QlikView for error handling in Connect statements so that if one connection fails,it should be skipped and moved on to other connection in case of multiple OLEDB connection?? Any response would be highly appreciated.
You can try multiple connections like this:
SET ErrorMode=0;
OLEDB CONNECT TO …;
SET vConnectStatus = $(#ScriptError);
IF $(vConnectStatus) > 0 THEN
OLEDB CONNECT TO …;
SET vConnectStatus = $(#ScriptError);
ENDIF
IF $(vConnectStatus) > 0 THEN
OLEDB CONNECT TO …;
SET vConnectStatus = $(#ScriptError);
ENDIF
Hi Rob
Much thanks for responding back. Just a thought.. would this work with the for loop as well?? I am having around 20 different connections for 20 different ledgers.
The general concept should work regardless of whether you are in a loop or not. Note that you must capture or test #ScriptError before executing any other statement, even “NEXT”. Every statement resets ScriptError.
Hi Rob
Thanks a lot for your help. 🙂 Have a beautiful day.
Hi Rob.
Sorry to bother you again as I tried the the same method specied but as usual no success . Could you please suggest something?? I am trying to capture the changes in a table as there can be multiple database failure at times
DatabaseList: //Ledger List
Load * INLINE [
Server,Port,DBName, Password, Username
88.99.77.55,52054,Melbourne,IMdHbFNGZDaADWRMFTcMG, sa
00.00.00.00,1234,Brisbane,NLLXWFNGZDaADWRMFTcWL, sa
11.11.11.11,8888,Queensland,IZZbIINKDKMcWZVOSLYcWRVMBZMA, sa
22.2.22.2,9999,Perth,PcWYTFNGZDaADWRMFTcYF, sa
];
//code to set the connect statements
LET Number_of_records = NoOfRows(‘DatabaseList’);
FOR DbNo=0 to $(Number_of_records)-1
Set ErrorMode=0;
let Nam=peek(‘DBName’,$(DbNo),’DatabaseList’);
let pwd=peek(‘Password’,$(DbNo),’DatabaseList’);
let user=peek(‘Username’,$(DbNo),’DatabaseList’);
let Server=peek(‘Server’,$(DbNo),’DatabaseList’)&’,’&peek(‘Port’,$(DbNo),’DatabaseList’);
//let port=peek(‘Port’,$(DbNo),’DatabaseList’);
CALL Qvc.Log(‘Starting load for $(Nam)’)
//Connection string would change for type of database. Replace dbname with the variable. SQLACCESS
OLEDB CONNECT TO [Provider=SQLOLEDB.1;Persist Security Info=True;User ID=$(user);Initial Catalog=$(Nam);Data Source=$(Server);Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=PRT-TS;Use Encryption for Data=False;Tag with column collation when possible=False] (XPassword is $(pwd));
Set vConnectStatus=$(#ScriptError);
IF vConnectStatus> 0 then
SQLACCESS
OLEDB CONNECT TO [Provider=SQLOLEDB.1;Persist Security Info=True;User ID=$(user);Initial Catalog=$(Nam);Data Source=$(Server);Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=PRT-TS;Use Encryption for Data=False;Tag with column collation when possible=False] (XPassword is $(pwd));
TempError:
Load
‘$(ScriptErrorCount)’ as Error_Seq_Number,
‘$(#ScriptError)’ as Error_ID,
‘$(ScriptError)’ as Error_Name,
‘$(ScriptErrorDetails)’ as Error_Detail,
DBName as DatabaseName
Resident DatabaseList;
End If;