Error in Log File - SE_LOG: Shared - CreateMetaData: Object ID...

[stevedark]

Hi,

We are seeing lots of instances of this error message in our server log files:

SE_LOG: Shared - CreateMetaData: Object ID already exists in document E:\QLIKVIEW DOCUMENTS\PUBLISHED\[folder name]\SALES FORECAST.QVW.Shared. Info: Id(SH03-162), Type(MetaData), User()

It happens for a number of different documents, but not all of them.  It doesn't happen at all on the Development Server, which hosts the same documents.

Is anyone else seeing this error?  More importantly, does anyone know how to stop it occurring?

Thanks in advance.

Steve

[#2]

Hi Steve,

Did you change Document Security Settings ?

Maybe did you remove the check for the option "Add Sheets" (2nd option in security Tab, Document Properties)

Gaëtan

[Anonymous]

Have you recently updated your version of QlikView? Are you 11.2 SR11?

These entries are a bug in the logging software and can be ignored.

We have had two great guys from Qlik in Sweden working with us on some issues this week and they confirmed that these entries are a logging bug. I think Support can confirm this also.

[#4]

Hi Steve, Hi Paul,

I think I have an explanation to this matter which is not really a bug from my point of vue.

For me, this situation appears if you have published a document allowing users to add sheets.

If after some time, a user add one ore more sheet(s) and you uncheck the security option allowing users to add sheets on your qvw document, the server is just notifying you there is a conflict with this security option.

This post should help you.

You will see a shared file Cleaning Tool is now included in the QlikView Server executable (since v 11.2 SR10) :

https://community.qlik.com/message/730746#730746

Gaëtan

[Anonymous]

I found further info Qlik had posted to our Support ticket:

Symptom: "CreateMetaData: Object ID ,already exists error in event log" errors in the Events.log Root cause: Bug ID QV-271 Resolution: other than error written to Events.log, no other issues. Bug will be addressed in a future service release.

[stevedark]

These discussions are all very interesting.  There certainly are SE_LOG lines that are written which are of no consequence (due to some debugging code finding its way into a production release).

That explains the entries: SE_LOG: User - GetGroups: DCName is empty. Fetching...

What does the warning message 'GetGroups: DCName is empty...' in the Server Event log mean and how d...

The CreateMeta data ones are I think pointing to an issue.

The corruption in the file is definitely a possibility.  However, I thought of a scenario, based on how we have dev and live in this environment which could lead to the situation.

We create in Dev, and then copy changes to Live after testing.  We don't always (although we should) rename sheets and objects when created.  So these are given the next name in sequence.  When objects are created through the QMC they are also given sequential IDs.  So, it would be possible to have an object in the core QVW and in the Shared file with the same ID.  I can see that this would cause an error, and the message above would kind of fit.

I've not had time to prove this assumption conclusively, but it would seem to follow.

I used the old PowerTool for cleaning shared files, and found there were quite a few users that had created sheets, but no objects.  Obviously just seeing what the Plus did without actually intending to put anything else on there.  Some of these were showing in the error log as issues (see the sheet ID in the error log above).  It was therefore safe to delete these and any other objects that looked redundant.  This has stopped those errors for the items that I deleted.

Now the noise has died down in the logs with those CreateMeta I can see a few more items I need to hit.

If you find this thread, and you are not able to obliterate objects from your shared file then I would look in your QVW file for objects with the name shown in the event log and rename them there.

If someone gets this issue and has time to look into it further, it would be interesting to know if when the warning shows the user who created the object in AccessPoint is no longer able to see that object, or if there is any other negative impact.

Regarding the conflict with the functionality being locked down after objects are created, that is not the situation in our case - as users can still add new objects.

Steve

[Anonymous]

We saw something similar yesterday and it ended up being corrupt PGO files causing the issue.

[Peter_Cammaert]

Strange...

This ID conflict between standard sheets and user-created sheets shouldn't really happen at all.

My understanding is that in QV Desktop, new sheets indeed get a default name that is the next one in sequence. If you ever made a sheet with ID SH1024, then the next one will be sometihng like SH1025 although the original one may not even exist anymore.

Whenever a user creates a new sheet in the AP, the sheet ID may start with an existing ID or a lookalike. But every user sheet will have an instance number attached to the base ID just like the error message in the OP shows: SH03-162. That particular sheet may have been copied from QVW-resident sheet SH03, and the -162 attachment should make it unique among the sheets in the shared object repository.

Being very careful, I would assume that there is no real issue in QVS. Just a lot of annoying "error" messages of which we also got quite a lot in the Windows Application event log. And this situation can indeed be fixed, in our case by running the QVS cleanup tool.

Could this be a case of QVS simply looking for the next free shared object ID, and erroneously reporting on one that it did find to be present?

[Anonymous]

For a Server Sheet object SH03-162 , the suffix -162 shows the last number of the ip address of the QV server that supported the user session when the user created that object, in this case 162. Check that out for yourself on one of your servers.

The 03 signifies that it is the 3rd Server Sheet object ever to be created for that document.

It should be noted that neither in AJAX nor the Plugin can an end user specify or change the object ID in any way.

Internally in the shared file, Server objects are always referred to as e.g. Server\SH03-162 where as Document objects (from the .QVW) are referred to as Document\SH03. So even if the Developer changed Document\SH03 and added a -162 to be SH03-162 so that there are two sheets with that apparent ID, the ID exists within a namespace of either Document\ or Server\ and so there can never be a clash.

If you use the Powertools Shared File Viewer and then File | Export to XML and look at the resulting file it's a fascinating read. Make sure you create a something like a Server object on a Document Sheet before this e.g. Server\LB01-02 on Document\SH01. You will see the XML not only contains a node to describe the Server\LB01-02 object but also an ObjectContent node which depicts on which sheet your List Box is placed, looks like this

<ObjectContent ID="Document\SH01" Owner="A_USER">

...

  <ContentMember>

      ...

    <ObjectID>Server\LB01-02</ObjectID>

This shows that A_USER has additional content on a sheet Document\SH01 provided by the QVW. And that that content is a user created list box Server\LB01-02

Elsewhere in the XML you will find the a node for the definition of Server\LB01-02 and another node for Metadata pertaining to Server\LB01-02 , owner, is it shard, who to, etc.

[Anonymous]

Use Shared File Repair from Power Tools, that should help u out, before repair, verify in the options and make a backup of them.

Shared files corruption could cause on the server:

Server inestabiliti

File deadlocking

Unexplained restarts

Restricts document access

Server object anomalies

Loss of server objects and bookmarks

Inconsisten server behavior.

That´s Qliktech´s answer