How can I resolve "Failed to load properties. No data found" publishing error?

[kwdaniels]

When publishing/overwriting an app, I'm getting an error, "Failed to load properties. No data found." Has anyone experienced this or found a solution to it?

I can get around this by 1) deleting the published app, 2) making a copy of the app in the "My Work" stream, and 3) republishing the copy. But as soon as I try to publish the app again by overwriting the published app, I get this error:

I wondered if one of the sheets in my app was causing the problem, so I made another copy of the app, stripped out all the existing sheets, created a simple new sheet (one table, one column), then published again to a new name. Then I republished a copy of the stripped-down app over the new app and received the same error.

The app has a lot of visualizations that I'd prefer not to lose. Do I have to start all over?

Thanks for any help you can provide!

[raju_insights]

Hi Daniels,

Try restarting your Qlik Repository Database and try again.

Services.msc > Qlik Repository Database (right click and select restart)

[kwdaniels]

Thanks for your quick response, Rangaraju. I tried restarting the "Qlik Sense Repository Database" service (and all the other Qlik services), but unfortunately the issue persists.

More details: If I start with a brand new application (not a stripped-down copy of the problematic application), the problem does not happen. So it seems to be an issue with the particular application I'm trying to publish. And yet, removing all the sheets does not fix the problem, so the problem seems to be buried somewhere deep in the application...

[raju_insights]

Instead of Replacing that app have you tried publishing that app as a new app in that stream ?

[kwdaniels]

Yes, I've tried publishing to a new app. But invariably, when I subsequently republish over that new app, I get the error. It seems to be a problem with the app itself, but I'm not sure how to identify/resolve it.

I'm using a lot of variables in the app (defined using the new 2.1 app editor, not in the load script), so it's going to be chore to redefine them all if I have to start from scratch with a new app. And my concern is, will this issue happen again in the future even if I start all over?

[raju_insights]

I mean, don't republish over any app. Just Publish it.

[kwdaniels · Accepted solution]

Right--publishing it the first time works fine, but then if I want to update the app and republish it, I encounter the error.

I just now found a solution that seems to work for now: I downloaded the app into my local Qlik Sense Desktop (instead of working on the server version), made a small change to the app, saved it, uploaded it to the server, published it, and then was able to publish it again without encountering the error. So hopefully this means it's resolved and I won't have to rebuild the app from scratch.

[#8]

I have had the same issues, where I can publish an application initially, but subsequent publications to overwrite the app result in that failure message.In my case, I exported an App from a development Server environment and imported it into our production Server environment.

It seems to be related to image references not copying over properly (I had created images to make it easier for end users to see apps once deployed to Streams). In any case, it is a strange point of failure.

To fix, I pulled the app in my workspace, deleted the image logo on the App, exported it, and imported it right back into Qlik Sense, all on the Server. This cleaned up the broken image link, and has worked for my issue.

I hope this helps someone!

[#9]

Hi kburrus2,

Thank you very much for this suggestion, this was also the solution in my case. What a workaround though...

I had already logged a case for this with Qlik Support.

Hope they will fix it in some way.

[Anonymous]

we had the same issue and in our case it was caused by custom image used as app logo. you have two choices to upload custom images and I think you have to use default content not the application one.