Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
TKendrick20
Partner - Specialist
Partner - Specialist

QlikView Freezes After Script Execution is Complete

This problem happens on and off with no real rhyme or reason it seems. I will make a change to the script, save it, then run a limited load (~10,000 records). The script will run as usual, but once the execution is complete I cannot click 'cancel' to close the debug window. Doing so promptly freezes the program and slows down my entire computer.  The only way I can close QlikView is to force close it with the task manager. Any ideas on what the problem is or how to fix it?

1 Solution

Accepted Solutions
TKendrick20
Partner - Specialist
Partner - Specialist
Author

I did have two fields with (accidentally) the same name: SubGroup1 and SubGroup1 <- supposed to be 2.

However, in trying to use the Qualify *; thing in the script, that was also the cause of more problems that slowed the load down a lot. So be careful if you try to use that to diagnose a similar problem.

View solution in original post

11 Replies
Not applicable

Could it be possible that you forgot to remove a certain table? So that you have two tables with more or less similar field names. Ifso QV tries to create composite keys which can take a long time

gr.

Frank

TKendrick20
Partner - Specialist
Partner - Specialist
Author

So is it safe to say that hitting "cancel" after the script has run in the debug window prompts the creation of these composite keys? I'm trying to work this out but I've been very careful not to repeat field names because I've been warned of how much QV hates composite keys.

Not applicable

Maybe add qualify *; in your script. That will break the model but allow you to see  witch table/field not supposes to be here.

(You probably have a temporate table not dropped or 2 fields with the same name and not suppose to.... or an modelisation issue in you final model)

TKendrick20
Partner - Specialist
Partner - Specialist
Author

That's a helpful little trick, but now the script freezes before it is even done.

Not applicable

Just run it on debug mode with 100 records,, and then check data model.

cheers,

Not applicable

Check you fields in the script. You must be referencing the same fields in 2 differnt load statements and if the count of fields is too much, QV will stop responding after the execution of the script since it is buzy creating Synthetic keys for all the common fields. A simple turnaround for this issue is to prequalify the common fields with the table name. Hope this works

Best

Not applicable

Check you fields in the script. You must be referencing the same fields in 2 differnt load statements and if the count of fields is too much, QV will stop responding after the execution of the script since it is buzy creating Synthetic keys for all the common fields. A simple turnaround for this issue is to prequalify the common fields with the table name. Hope this works

Best

Not applicable

Check you fields in the script. You must be referencing the same fields in 2 differnt load statements and if the count of fields is too much, QV will stop responding after the execution of the script since it is buzy creating Synthetic keys for all the common fields. A simple turnaround for this issue is to prequalify the common fields with the table name. Hope this works

Best

TKendrick20
Partner - Specialist
Partner - Specialist
Author

I did have two fields with (accidentally) the same name: SubGroup1 and SubGroup1 <- supposed to be 2.

However, in trying to use the Qualify *; thing in the script, that was also the cause of more problems that slowed the load down a lot. So be careful if you try to use that to diagnose a similar problem.