Developer forum

Hi Imar,

This could potentially lead to a lot more problems, especially relating to primary keys etc. 

Do you have some examples of the issues you run into, maybe the solution is something else. 

Best regards 
Rasmus Sanggaard

As an example a street name that is longer than 255 characters to be imported into AccessUserAddress. It's not uncommon to have junk in there like "old address do not use, use bla bla instead, watch out for the dog and call Bob before delivering your package". This currently crashes the entire integration and the only way to fix that is:

1. Fix the data. This is of course the best solution but cannot always be done on time for an integration engineer to continue working

2. A Table Script to trim the data. Lots of work for something as simple as truncating data

With this new option turned on, truncating would happen automatically and cap the length at 255.

And it won't be an issue for PK as they would not exceed the max length normally and you would not turn on this option for a PK column anyway. And if they would exceed the max length and you did turn on that setting, I think you have other problems to worry about also :-)

Imar

Hi Imar,

If it's a common issue that street names are typically longer than 255 char. then I think we should fix that instead, even though it was just an example. I believe it's a slippery slobe to allow for incomplete data and would just lead to other problems down the line. 

It's not something that is going on our backlog at this time, but I will keep it in mind if I get similar requests.

Best Regards

Rasmus Sanggaard 

Hi Imar,

There is an alternative by setting the "Persist successful rows and skip failing rows" option, so that records where e.g. the length of the address exceeds the maxlength of the database field will be skipped, while other records will be imported.

The feedback from the system is not the best, but perhaps that could be improved displaying the failing records, so the data issues can be handled.

Br.

Lars

Thanks Lars; we use that today already, but sometimes it's nice to be able to trim and still store the data.

What about a code provider then so I can assign something like @Code(value.Trim()) on a column where value is the input value of the column? That would open up lots of other interesting possibilities. It allows us to change data without having to write (and more importantly, deploy) a table script. It also makes that code more visible than a table script is today.

Imar

Late reply, but I really like that approach Lars. Will give that a try the next time.

Imar