How many fields does XML port support for export or import

tabularasa

does anybody know.

Savatage

Have you created an xml port and come across and error of somekind or are you just asking for sake of knowledge?

tabularasa

Kind of funny scenario. I have to write import for a file with 256 fields and I know that the dataport can handle up to 255 My question would probably be better as following, Can xml ports handle more than or equal to 256 fields. I am going to take another route than xml port if these limitations are on the xml ports.

kriki

[Topic moved from 'NAV Three Tier' forum to 'NAV/Navision Classic Client' forum]

davmac1

Why did you move this to Classic? This question is revolving around features of xmlports when running for the role tailored client. (See page 10-24 of the 2009 Dev I training manual.)
We are trying to import text fieldsusing the fixed text option of the xmlport and we are hoping someone has the answer to max fields restrictions which we don't see in the manual or find an answer using google.

Savatage

I've looked around myself and haven't ben able to find any reference to max fields.
Are you mapping the data to global variables & then importing/exporting?
I would ask..do you really need that many fields?
Else, there's only 1 quick way to find out.....build a 256 field port.

davmac1

We are getting a file from an outside vendor (Concur) and it comes with 256 fields - most of which are not used.
We were hoping for a quick answer rather than spending the time it would take to handle 256 fields.
We could use SSIS, but then our error handling will be in SSIS.
Plus it is part of a whole series of automated processes.

Our client is on the basic plan with Concur which means they get the standard offering.

DenSter

tabularasa wrote:

I know that the dataport can handle up to 255

Actually dataports can handle more than 255 fields.

I've built a dataport for Concur and had the same question about the sheer number of fields. I ended up just creating the dataport to see if it would work, and it did. Not to say that the same applies to XMLPorts, but since that is a new line per element I would expect it not to be a problem.

davmac1

Thanks.
Did you ever have problems with Concur consistently creating files correctly?
We have run into one so far and they blamed it on a new customer verification requirement -though I don't see how you can blame an end user for badly formatted data. (Though it would dramatically drop the development effort!)

DenSter

Not personally, but I heard from my customer that Concur changes their schema without notice, it has happened to them a number of times. That might mean "we had to change the schema due to a new customer's requirement". Probably a big one because it sounds like they are not willing to just customize file format, it seems like it's a all-or-nothing kind of deal.

davmac1

Did Concur use pipe (|) as a delimiter for your customer?
It looks like Navision cannot handle that because it is used as an OR condition.
Did you find a way to handle that or did they use a different separator?

DenSter

Field start and end delimiter = <None>
Field separator = |

This has been in production for a while so I know it is working. I don't see how a | as part of a field value can ever be interpreted as an OR in a filter when data is imported. It doesn't apply field values as filters unless you program it to do that.

I've had lots of issues with delimiters and separators in dataports. The only one that I've found to be 100% reliable is <None> as start and end delimiter and <TAB> as separator. It doesn't look like Concur is willing to provide a different format though.

davmac1

thanks four response.
my preference is the same asyous - but Concur seems pretty set in their ways.