Any idea on why i cannot access property CTRSUM_KEY?

property does exist

Hard to say without seeing the full query. If the query below is indicative, then you are returning distinct “node”, and I think you mean to return distinct n?

That's the query which appears when clicking on the label name displayed on the left. Nothing special. Works for other labels, works for other labels containing "".
I'm importing data from CSV using apoc.load.csv.
I've renamed the column to CTRSUMKEY, issue persists.

Thought it would be due to data containing "
" : no.

Removed all "_" from values, issue still present :

Really strange.
@michael_hunger ?

Might be whitespace before or after it. Try doing this, then checking the values in the Text result view to make sure there's no extra whitespace:

RETURN keys(n) as keys

And if it's there and looks correct, maybe copy/paste that to a text file and see if there are any unusual and unexpected characters in there.

There is no whitespace, i've checked several times. Also the export is done from an Oracle table, which export i've used on a lot other tables, with no issue. Even if so, i was not expecting to not being able to access the property. Not even using "`" worked.

Agreed, something very strange is happening here.

You could try a consistency check of your offline db to see if there's anything off here.

I'm still suspicious about any text anomalies here. You could try these to see if there's anything weird:

See if the key begins with a prefix. If you get a hit, keep extending the prefix and see if it breaks somewhere. (You can also try with ENDS WITH if this breaks right from the start)

RETURN [key in keys[n] WHERE key STARTS WITH 'CTR'] as ctrSumKeyProp;

For the row with CTRSUMKEY, check if it think the key name and provided string are equal.

UNWIND keys(n) as key
WITH key, 'CTRSUMKEY' as ctrSumKeyProp
RETURN key, ctrSumKeyProp, key = ctrSumKeyProp as isEqual

Good morning (if applicable :slight_smile: )

I'll check again for inconsistent values.

Well.............issue is due to encoding.
Due to a recent update, our server is using "UTF-8-BOM" instead of previously "ANSI".

Quite a strange issue, as it affected only this column.
If needed, i can provide the file, to further investigate.