It's Not A Number
-
So I'm writing a system that deals with so-called UBNs (Unique Bedrijfs/Company Numbers). The value is 7 characters long for Dutch companies in the branch I'm working for. However... Some aren't, so you get a leading 0, like 0123456. Now, I have an import, which does not give me the leading 0. As a result my customer omitted the leading 0 from their master data as well. However, we have a service that customers connect to, which does use the leading 0. So, made a fix for the import and forced this UBN to be at least 7 characters, problem solved... Except that I just found out some third party software does not include a leading 0 when accessing our service (even though it's set in the settings!) X| Event their logs show the leading 0, but my logs say differently. Who the hell comes up with this shit? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I'm writing a system that deals with so-called UBNs (Unique Bedrijfs/Company Numbers). The value is 7 characters long for Dutch companies in the branch I'm working for. However... Some aren't, so you get a leading 0, like 0123456. Now, I have an import, which does not give me the leading 0. As a result my customer omitted the leading 0 from their master data as well. However, we have a service that customers connect to, which does use the leading 0. So, made a fix for the import and forced this UBN to be at least 7 characters, problem solved... Except that I just found out some third party software does not include a leading 0 when accessing our service (even though it's set in the settings!) X| Event their logs show the leading 0, but my logs say differently. Who the hell comes up with this shit? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
About ten years ago I had to interface with a third-party system via sockets. The specification for the socket API specified that each message had to be identified by a ten-digit ID -- any ten digits would do, it just had to be unique. I decided to use the first two digits to identify (to myself) what type of message it was. For most messages I used "00", but for some special messages (like when querying the health of the other system) I used "99" or "98". BOOM! The response was always that the message was invalid and the system was resetting. I contacted the developer at the vendor (the guru who developed and documented the API) and he said that my messages should have been valid and he had no idea why the system was behaving as I had described it to him. A few days later he told me the reason -- the developers of the application hadn't understood the API specification and had assumed that the ID was a 32-bit integer (!) and they were trying to parse the ten digits :sigh: . Once he got them straightened out they fixed their code and all was good after we installed an update. Whether the fix was to use a string or a 64-bit integer on their side I will never know.
-
About ten years ago I had to interface with a third-party system via sockets. The specification for the socket API specified that each message had to be identified by a ten-digit ID -- any ten digits would do, it just had to be unique. I decided to use the first two digits to identify (to myself) what type of message it was. For most messages I used "00", but for some special messages (like when querying the health of the other system) I used "99" or "98". BOOM! The response was always that the message was invalid and the system was resetting. I contacted the developer at the vendor (the guru who developed and documented the API) and he said that my messages should have been valid and he had no idea why the system was behaving as I had described it to him. A few days later he told me the reason -- the developers of the application hadn't understood the API specification and had assumed that the ID was a 32-bit integer (!) and they were trying to parse the ten digits :sigh: . Once he got them straightened out they fixed their code and all was good after we installed an update. Whether the fix was to use a string or a 64-bit integer on their side I will never know.
Been there, done that :laugh: The "standard" I'm currently using defines fields and values in a message. I've had to exchange messages with two parties so far, and both had their own "interpretation" of which fields were mandatory. For the SOAP definition I had to create a completely different version :sigh: The latest version of the spec, which is actually a pretty detailed document, is about 15 years old, so that shouldn't be the problem :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I'm writing a system that deals with so-called UBNs (Unique Bedrijfs/Company Numbers). The value is 7 characters long for Dutch companies in the branch I'm working for. However... Some aren't, so you get a leading 0, like 0123456. Now, I have an import, which does not give me the leading 0. As a result my customer omitted the leading 0 from their master data as well. However, we have a service that customers connect to, which does use the leading 0. So, made a fix for the import and forced this UBN to be at least 7 characters, problem solved... Except that I just found out some third party software does not include a leading 0 when accessing our service (even though it's set in the settings!) X| Event their logs show the leading 0, but my logs say differently. Who the hell comes up with this shit? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Ah stop your bitching, I worked with a financial system where the traders were allowed to enter 1.23m or 1.23 mil or basically anything they liked for numerical values. Try doing financial regulatory reports on such shite that had to be accurate to the cent.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
So I'm writing a system that deals with so-called UBNs (Unique Bedrijfs/Company Numbers). The value is 7 characters long for Dutch companies in the branch I'm working for. However... Some aren't, so you get a leading 0, like 0123456. Now, I have an import, which does not give me the leading 0. As a result my customer omitted the leading 0 from their master data as well. However, we have a service that customers connect to, which does use the leading 0. So, made a fix for the import and forced this UBN to be at least 7 characters, problem solved... Except that I just found out some third party software does not include a leading 0 when accessing our service (even though it's set in the settings!) X| Event their logs show the leading 0, but my logs say differently. Who the hell comes up with this shit? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
1. Excel messes up leading 0s 2. Octal nightmare 3. Blame it on EBCDIC, space comes after 9 in ordinal order! I think I learned these from a David Letterman top ten list, but I forgot the other 7.
englebart wrote:
Excel messes up leading 0s
And more! I get a CSV file from a customer, but they often edit it using Excel. There go the leading zeroes, decimals, date formats... X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Ah stop your bitching, I worked with a financial system where the traders were allowed to enter 1.23m or 1.23 mil or basically anything they liked for numerical values. Try doing financial regulatory reports on such shite that had to be accurate to the cent.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Mycroft Holmes wrote:
or basically anything they liked for except numerical values.
FTFY :laugh: Why would you even want that? :wtf:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I'm writing a system that deals with so-called UBNs (Unique Bedrijfs/Company Numbers). The value is 7 characters long for Dutch companies in the branch I'm working for. However... Some aren't, so you get a leading 0, like 0123456. Now, I have an import, which does not give me the leading 0. As a result my customer omitted the leading 0 from their master data as well. However, we have a service that customers connect to, which does use the leading 0. So, made a fix for the import and forced this UBN to be at least 7 characters, problem solved... Except that I just found out some third party software does not include a leading 0 when accessing our service (even though it's set in the settings!) X| Event their logs show the leading 0, but my logs say differently. Who the hell comes up with this shit? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
So I'm writing a system that deals with so-called UBNs (Unique Bedrijfs/Company Numbers). The value is 7 characters long for Dutch companies in the branch I'm working for. However... Some aren't, so you get a leading 0, like 0123456. Now, I have an import, which does not give me the leading 0. As a result my customer omitted the leading 0 from their master data as well. However, we have a service that customers connect to, which does use the leading 0. So, made a fix for the import and forced this UBN to be at least 7 characters, problem solved... Except that I just found out some third party software does not include a leading 0 when accessing our service (even though it's set in the settings!) X| Event their logs show the leading 0, but my logs say differently. Who the hell comes up with this shit? :((
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
I never, ever start a numerical sequence with leading zeros. Never. Add a 1 at the beginning.
-
I never, ever start a numerical sequence with leading zeros. Never. Add a 1 at the beginning.
To be clear, it's not my number. It's some government issued number :sigh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Well, in my case it was an Admin Manager who passed out a 'file format' to 40 or so customers for a CSV return with (30+) columns described as 'Number', 'Text' and 'Date'.... :sigh:
He should add "Decimal" just to be 100% clear :laugh:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
Mycroft Holmes wrote:
or basically anything they liked for except numerical values.
FTFY :laugh: Why would you even want that? :wtf:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
Trading platform and guess who made the bank the most money, so traders (lazy, ignorant, opinionated arseholes) get to dictate what they want.
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
Optimist. With our luck we only get AS, not AI.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
It´s always better to be an optimist. We can´t live while we try to see everything as a problem. https://www.dampfi.ch/ helped me to calm down with some nice flavers for example :)
