These errors are considered bugs and should be debugged by a Qliktech Support Technician. Report this as a case to email@example.com and attach the document (if possible) and steps to reproduce. Also include detailed information about your environment, such as the QVS DSI.
this one just popped on 2 days ago, no fix yet, been sending logs and info to Support. Other issues; I had lots of problems with the macros that we use (lots of post reload macros) that stopped working. We also use scheduled tasks for our reloading btw. Anyway what I discovered is that the macros would fail because in my .bat files I was using the /r option which worked fine with version 8.5. However under version 9 the macros fail to execute. Switching to /l in the .bat files solved the problem as the various objects I was exporting were now "visible". Other problems were found with the current selections in the IE plugin toolbar. Under v9 you could see the current selections, but not clear them. I modified all our apps to use the current selections layout object and told my uses to stop using the toolbar item. I have only tried it briefly under 9sr1, but that one seems to be fixed now.
Our big issue probably stemmed from our environment. When we first went to v9 our IE users, when they connected to the server were being assigned 2 CALS for each user. one for the server account and another that showed up as a user with "<NW-username>" (we are a novell shop). Took some help from QliKTech support to find that by checking Prohibit Anonymous under Authentication, Client, in the enterprise management console solved that problem.
Actually, I've already seen the error/message "Internal inconsistency, type D, detected" in several scenarios, not too often, but again and again, in QV 9, in QV 9 SR1, in 32 and in 64 bit. And I could hardly ever reproduce it (and so I never could occupy support). And I could not make out what the situations in which the error occurred had in common... Once it occurred to my mind that "D" might stand for "Don't know!" - or "Dont't tell you!" ;-))
The "Internal inconsistency" errors is not by definition an issue in it self, but a pointer to what type of error that has occured when inconsistency did. These errors can for e.g. be an access violation or a number of other, often memory related, issues. They are not harmful to persistent data, but is most probably going to empty the working set for QVS as an evasive maneuver to not cause any more inconsistency or errors.
Often the errors can be a symptom of a somewhat bad document design, or an indication of memory shortage, or any other number of issues. Sometimes there are workarounds, but they are always seen as bugs.
They occur in very specific situations, and not very often if all is correctly done, which is why we require as much information as possible when troubleshooting these errors. Document, steps-2-reproduce and environment information is a must.
I have sent over all the details that I can think of, logs, the about info from the mgmt console. Server has 32 gig of ram so I can't image that is an issue. Been trying to hone in on what triggers it, it just started happening in the last 3 days. The real trouble is that it is causing the qvs.exe to hang, and my users get a No Server message in the Access Point home page.
I didn't say that memory related necessarily meant shortage of memory. It could be a mapped area in memory that is cleared and then referenced, or a faulty pointer, or read/write access violation, or.. and so on. And as I said; the "hang" of QVS is because the server will most probably clear the working set or that sometimes the process crashes as a result of the error.