Wrong info populating from pulldata()

[SofiaThordin]

I am trying to implement the pulldata() function in Survey123. This is my first time giving it a shot, so I anticipate the error lies in my work somewhere. I have drafted my survey's XLSform and uploaded the accompanying .csv file into the survey's media folder. What I want to do is be able to type a Parcel ID/Folio in, and then have address, owner, year built, etc. auto-populate in following text questions. I have succeeded in getting the pulldata() to work, since info is being populated into the form. However, the info being populated is wrong. You can see in the screenshot that only Address pulls correctly. I am pretty sure that I am referring to the correct column/table in my pulldata calculation, so the main question is why is it returning odd values? I have tried a handful of different Parcel IDs/Folios and all return the same thing. 

I am not super familiar with .csv files, so maybe something is wrong with the way I converted and saved the spreadsheet? My methodology was to 1) compile all the data I wanted into a shapefile in ArcMap 2) export attributes to dBASE 3) conversion tools > table to Excel 4) Open in Excel and save as .csv standard comma delimited. I will attach my XLSform and .csv here. 

Update: (attachments removed)

[RalphBeishline · Accepted solution]

I may be entirely wrong, but my initial suspect is that you have fields containing commas that are then treated as delimiters when saved as a .csv, which splits and pushes data around into unexpected fields.

Can you test this with a version of your .csv where you replace all the commas?

[SofiaThordin]

You know, you'd think with a name like "comma delimited" I would have picked up on that... sometimes the answer is just too obvious. Haha thank you, worked like a charm!

[AdamDaily]

Is there any way to tell Survey to ignore those commas or to use a different file format or calculation to pulldata from? I have data formatted to work with other systems that Id rather not have to change now and put back together later.

Why have a calculation field requiring the column heading name if its going to ignore that and allow a delimiter to take precedence? This not only adds incorrect values for that question, all future questions referencing the same file are now thrown off as well. From that point on, column names used in pulldata functions on future questions are also ignored, and instead Survey continues to break down the previous delimited field.