Hi,

It should work with NodeName(not Id) when the document with the same name exists it should create a reference on the PRO version. I assume you have documents on Brands with the same name?

Best,

Richard

Hmm seem like mapping didn't happen if it shows you the normal names. Sure names are exactly the same?

I am using the latest version of CMS Import pro but I have the same error as above. I have a collection of document types in the root called "Services" and these have a name and id. I have another document type at the same level in the root called "Packages" and one of the fields on the Package type is a Multinode Treepicker2 which points to the Services node as Package can have multiple child services. When running a CMSImport for Packages I pass across a Service name which exists but it does not map and I get the error: Failed to retrieve entity data for ids "blah blah blah". Any ideas how to fix?

Hi Robert Have you tried withy the hotfix release as well?

No, I tried the link to the dropbox above but it returns a 404. Where can I get the hotfix release?

This one should be ok for now https://www.dropbox.com/s/kg4pglvlkk7n11d/cmsimport37_4.zip?dl=0

Hi Richard I installed the hotfix and it works if I pass a csv list of names. However when I pass a csv list of ID's it does not map. How can we get the ID csv list to map?

Hi Robert,

That is a bit strange since selection is

var nodeIds = (from v in csv select childnodes.FirstOrDefault(n => n.NodeId == v.ToInt() || n.NodeName.Equals(v.Trim(), StringComparison.CurrentCultureIgnoreCase)) into node where node != null select node.UID).ToList();

So should except node id as well.

Sorry I meant to clarify that it's an ID property not the real nodeid. So we have a document type called Service and it has two propeties defined, ServiceId and ServiceName. We import these values from our own central database via csmimport to a document type called Package which has a MNTP of Services. When I do the package import and pass across a csv list of ServiceName then they map correctly but we want to pass across the csv list of ServiceId how could we get that to work?

Well we could just change our node names to use the serviceid instead so we will do this.

That will work out of the box indeed so might be the best option thye other opion requires a bit of coding

Richard

Running 3.7.5 on 7.7.9 I now have the same problem with the MNTP not finding the values. Been using this great tool for a couple of years, but this latest version seems to have broken the MNTP mapping when used as content picker. Import just hangs.

Ignore the MNTP and all runs as expected.

Tried to get your fix detailed in posts above, but it is no longer available. Could you provide the fix please.

Thanks

Simon

Hi Simon,

What are the values you are trying to map. Current version includes the fix mentioned above.

Best,

Richard

Richard

Just simple node names of categories. Just cut it all back to a single product for testing, also tried the ID but to no avail.

Import creates the new node but it remains empty of content and just hangs.

The datatype of the MNTP is only used for these Categories.

At a bit of a loss as to where to go from here. As I have used your package on multiple sites without issue.

Just ripping it all out and re-installing, back to you if that fails to solve it!

Simon

Hi Simon,

Best to check the log if it hangs then it must be an exception that causes it and those will be logged,

Best,

Richard

Richard

That is the odd thing, it returns nothing to the log file.

I have ripped it out completely and re-installed, same result

It appears to get stuck in a loop as the SQL process runs at 50% until I quit the process manually. It never seems to find the node by required by dataType and nodeName. This appears to be why it logs no error. I assume there is a large timeout set on the page which is why it never gets there.

Any other ideas?

Thanks

Simon

What is the datasource you are using?

Richard

Coming from MS SQL on another web server.

Just realised that I have not been waiting long enough for it to complete!

Without the MNTP element a single product import takes a second or two, when I include it, the import took 35 minutes (see attached).

Surely something must be amiss with this?

Thanks

Simon!

Richard

Just as an update, I amended the import to look for the MNTP value by ID and it took 35:16 to complete, which is within 4 seconds of looking for the node by name.

It must be cycling through in a very laborious way to take that long and be that consistent in terms of time. The whole time it is running, SQL is using around 50% of the processor (This is currently on a dedicated server on its own, with only me accessing it).

Any further thoughts?

Simon

I see why that might be slow.

CMSImport will determine if the name of a childnode of the configured MNTP matches the name of the value that you map against the property to import. So if that has a lot of childnodes it will scan all those nodes. Since the childnode collection can be updated as well during import I can't cache this.

What would help propably is narrow the possible childnodes by specifying an xptah or rootnode id on the MNTP configuration.

Hope this helps.

Richard

Richard

Tried the Xpath idea, took even longer at 48 minutes!

Something must have changed with this version of your software as the initial data for this site was imported using the same settings and went without a hitch on an earlier version, that was 7 months ago.

The interface states that the MNTP uses the dataType configuration to look up the values. In this case there are only 38 nodes on that dataType so I would not expect it to take any time at all.

I cannot see that anything our end can be at fault.

Any further thoughts?

Thanks for your support in this.

Simon

Hi Simon,

This part of the software haven't been touched for years as well. Maybe got a lot of more nodes over the last 7 months since?

Tried rootnode id config to narrow down options as well?

I can see room for improvement for these lookups but require a fundamental change in the current solution which isn't a quick fix..

Best,

Richard

is working on a reply...