I just had a call to review an error that was occurring with an integration that I had developed.
The integration was adding records to a Dynamics GP ISV solution and while importing a large data file, it reported 6 errors. The ISV solution simply returned the generic .NET / SQL error indicating that a "string or binary data would be truncated."
The ISV has almost no documentation on their API, and the error message didn't tell us which field was causing the problem, so we reviewed the records that were getting the error, and saw that the customer names were very long. We assumed that a long company name was the problem. Looking at the ISV tables, I found that it only allowed 50 characters for the company name, unlike GP, which allows 65 characters.
Fine, so now that we found the likely issue, I had to modify my import to truncate the company name at 50 characters.
I opened my C# code and quickly added Substring(0, 50) to the company name string, and tested that change, wondering if it would work. C# developers will probably guess what happened.
"Index and length must refer to a location within the string"
Lovely. Okay, so off to Google to search for "C# truncate string". That search led me to this StackOverflow discussion of the topic, where I saw, thankfully, that I wasn't the only one with this question. Although I found a few solutions to the problem, what was very disappointing was that there was even a discussion of the topic and that there were multiple solutions to the problem.
Seriously? A modern business programming language can't just truncate a string? We have to measure the length of the string and make sure that we send in a valid length value? That's like selling someone a Corvette and then telling them they have to adjust the timing of the engine themselves if they want to go over 50 mph. Why in the world haven't they provided a means of natively truncating a string?
As one post on the StackOverflow thread points out, the Visual Basic Left function provides such functionality without throwing an error, so why does C# insist on making developers across the world all write their own quasi-functions to perform such rudimentary tasks?
How about the C# "Right" string function? Oh, you mean the one that doesn't exist? Ya, that one, where you have to create your own quasi-function, or yet again reference VisualBasic to perform a simple, obvious task.
It's just silly. A purist says something like what was mentioned on the StackOverflow thread: "That's probably why the member function doesn't exist -- it doesn't follow the semantics of the datatype." Seriously, that's the explanation or justification of why this modern language is wearing polyester bell bottoms? The semantics of the datatype? As in the string data type, where people actually need to truncate strings?
Don't get me wrong, I really like C# and now prefer it very much over VB, but when I come across annoying gaps in functionality like this, it just makes me shake my head.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
No comments:
Post a Comment