Hi,
consider using the CSV reader rather than the TextFile reader, it will handle all this for you.
CSV files can be surprisingly tricky sometimes.
David
Thanks David, I used the .CSV input method, but it was the UnconditionalFeatureMerger that did the job.
Unconditional merges regardless of any attribute, creating unescesary mergingcomparisons).
Mostly used to add a certain attribute to all others (like for instance a centre point to a pointfeatureset) or to intentionaly create a catresian product.
I think you might have had an issue with enconding?
I noticed that txt files can lead to different encodings because the reader does not recognise the text as the system encoding unless you specificaly enter it. (luckily 2014 txt reader lets you enter the encoding)
When you then try to merge them, every attribute where the encodings differ, will not get merged.
Unconditional will mask this, because it creates a common merge attribute at runtime, wich will adhere to systemencoding of course)
Of course it might also be possible that there is a large difference in lcense files or in the attribute itself... and that the merger was actually correct.
This will be evident when you test the licenses after having unconditionaly merged them.
In 2012 and 2013 i had to use tcl encoder function to fix it.
Gio,
how do you determine what encoding the Text file is? because I feel that is the issue when using FeatureMerger, only select records match up . . .(i'm using 2014). I tried using an encoding type of 'System' but the FeatureMerger still only spits out 100 records out of 900? Both column types are TEXT. . yet the only matching records are these types 'J0004923K' it drops any that are just numeric ex:(0015342)
I also brought the TXT in as a .CSV and in the preview it looks like a normal table that the two IDs can match up with, but no luck with that option either.
You can use the datainspector to check if the encodings are correct.
Check the merged, not merged and not referenced using inspectors (on the merger where the fails occur). Then lookup the encodings in the feature information window.
Check if there is a mismatch.
Rater then setting the encoding to system on the the textreader, enter/choose the target encoding.
I found a script where this issue occured.
At the merger a mix of utf8 and windows1252 GUID's arrived.
I used following tcl function in a creator to solve this:
attribute name (wich i used): GUID_utf8
attribute value:
@Evaluate(lencoding convertfrom {@Value(GUID)}])
this will convert to system encoding (as i do not use any parameters in the function).
in my case it would convert to utf8
