Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Detail: QlikSense Desktop 3.2 SR3
We have one laptop user that is getting an odd error when we try and load a model that works on several other computers (including other laptops), and which has previously worked with no issues on this laptop.
The following code causes a load error "unable to open file '***'" and a location of ?
[PSS]:
LOAD * INLINE
["Product Line","PSS"
1000,Other
2001,Snacks
3003,Pasta
3016,Pasta
3600,Pasta
4100,Pasta
4800,Semolina
4900,Other
5100,Snacks
5200,Pasta
];
If I comment the code out and run the load it completes normally.
I have also tried a complete reinstall of QlikSense on that laptop, to no effect.
Through searching, I found this thread for QlikView: QV 12.10 - mapping load * inline fails
But the solution there (delete the crypto folder) has had no effect.
We do use folder redirection to a DFS share, but this has not caused an issue before.
Does anyone have any suggestions as to how to resolve this?
Thanks for the suggestions gentlemen.
I found the following error in the Engine log for that user:
WARN 20171221T084814.375+0000 6828 10248 Personal\Me 20171221T083202.000Z System: OpenFileOrURL: An exception (fileNotFound \\<domain>\dfs\User\<user>\Documents\Qlik\Sense\1682-55eb-7dfe-406b.inl) occurred during open of \\<domain>\dfs\User\<user>\Documents\Qlik\Sense\1682-55eb-7dfe-406b.inl
It looks like the .inl file is created temporarily for the inline load. When I checked that user's permissions on the Qlik\Sense folder on the dfs share they had not been inherited properly, so Qlik could not write the temp file to that location. Once the permissions were corrected, everything worked properly.
Iain,
It loads ok here for me on Sense Desktop September
As to the description, it seems to not be finding some file your using.
Wouldn't make much sense for the inline table as I see it, try only loading the code you posted and reload the app.
Thanks Felip,
I know the code works, as the model is fine for all other users. There is a second inline load further down, and if I comment out the first one, it fails at the second one with the same error.
I suspect this is to do with temporary file creation, as was mentioned in the other thread, but I have no idea where QlikSense is trying to save these.
The code from the post works fine for me too.
Just tried the code:
//this one is straight from the manual
// https://help.qlik.com/en-US/sense/3.1/Subsystems/Hub/Content/Scripting/ScriptPrefixes/Mapping.htm
map1:
mapping LOAD *
Inline [
CCode, Country
Sw, Sweden
Dk, Denmark
No, Norway
] ;
facMap:
mapping LOAD * INLINE [
facCode, FacultyName
EP__, EPH
IT__, ITD
PH__, PHP
ADDE, Admin
DLAA, DL
ITAA, ITD
];
MAP facCode using facMap;
uoaMap:
Mapping LOAD * Inline [
UOAcode,UOAname
1, 1:Clinical Medicine
2, 2:Public Hlth. etc.
8, New Lecturers
9, New Others
];
MAP UOAcode using uoaMap;
PublisherMap:
Mapping LOAD * Inline [
publish,newPublish
Wiley, Wiley-Blackwell
Elsev, Elsevier
];
//MAP DOI_Publisher using PublisherMap; //use applymap in load
And get no error:
Pasting your code with the post's also gives me nothing out of the ordinary here.
Must be a version bug I assume, can you upgrade your version?
Hi Lain,
the error is certainly not relative to your load inline.
Try to identify exactly what load instruction cause this failure :
- with the debugger
or
- Put an exit script after the first load, if it's ok move the exit script after the second load ... etc until it fails
Thanks for the suggestions gentlemen.
I found the following error in the Engine log for that user:
WARN 20171221T084814.375+0000 6828 10248 Personal\Me 20171221T083202.000Z System: OpenFileOrURL: An exception (fileNotFound \\<domain>\dfs\User\<user>\Documents\Qlik\Sense\1682-55eb-7dfe-406b.inl) occurred during open of \\<domain>\dfs\User\<user>\Documents\Qlik\Sense\1682-55eb-7dfe-406b.inl
It looks like the .inl file is created temporarily for the inline load. When I checked that user's permissions on the Qlik\Sense folder on the dfs share they had not been inherited properly, so Qlik could not write the temp file to that location. Once the permissions were corrected, everything worked properly.