• Ginssuart (unregistered)

    frist

  • Ginssuart (unregistered)

    frist

    sorry for decimal post

  • (nodebb)

    TRWTF is a desktop application connecting directly to the database without a server in between. Someone can extract connection settings and just edit the database directly without any validation or security checks.

  • Jim Jam (unregistered) in reply to Maia-Everett

    Not necessarily. Such system usually allow editing data only via stored procedures, with all sorts of validations and permission checks within. So, properly implemented, it can be reasonably safe. But it is still a TRWTF, I fully agree on that.

  • (nodebb)

    Speaking from experience, if the worst they got is a wrong word in an error message I'd say the got off easy.

  • (nodebb) in reply to Maia-Everett

    I agree for the most part but some time it's not necessary. For instance one of our customers has a packing area in a processing plant with several packing lines and in every line there is a terminal with a label printing application that connects directly to a SQL Server in a local network. The app can only call one stored procedure that returns the next batch of labels, passing the line number as a parameter. As long as the network is properly segmented and the BD user is properly configured to only allow exec for the required SPs it doesn't really matter if someone gets the credentials and since they can only be used locally it's easy to detect missuse.

  • (nodebb) in reply to AGlezB

    So, what you're saying is, in essence:

    connecting directly to the DB server itself from the endpoints is OK if everything else is completely secured

    I mean, sure, everything else should be completely secured, but that's a honking big pile of details you have to get right every time you implement this again, and that you have to revalidate at any infrastructure change, addition of new functionality, or whatever. Good luck with that.

  • (author) in reply to Maia-Everett

    I mean, there's a world where the database is managed locally (Sqlite, or in Microsoft land there was explicitly a SQL Server for Applications or something like that that bundled a database with the app). I've worked with a lot of apps that did 90% of their work in a local database and then synced to a central database rarely (because I was building software for factories which didn't have reliable Internet connections and had to work 100% offline). The sync would go more through an N-tier approach, but obviously the local database didn't.

    Though, obviously, based on the error, this is connecting to a real server, so yeah, I'm rambling with no real point.

  • (nodebb)

    My beef with this is that someone actually got paid to decide to use Doubles to calculate financial data despite enormous infomation available about how bad this is.

  • Argle (unregistered) in reply to mynameishidden

    My beef with this is that someone actually got paid to decide to use Doubles to calculate financial data despite enormous infomation available about how bad this is.

    I once had trouble explaining to a co-worker (whose experience up to that point was in finance and web-applications) why his decision to store engineering data in a database (gauss, teslas, approximated voltages, and wattage) as decimal instead of float/double was a bad idea.

  • Brian (unregistered) in reply to mynameishidden

    This seems depressingly common. I once worked for a fintech startup that was using floats for all its financial data. When I suggested changing to fixed-point, the CTO (!) said we weren't dealing with numbers big enough to matter.

    He was right, in a roundabout way: the company folded a few months later, partly due to a dearth of users, so the implementation really didn't matter.

  • (nodebb)

    And of course, even if the global replace had worked, just changing from double to decimal won't magically fix all rounding errors. If I want to divide a dollar between three people, I'll have a cent left over which needs to be accounted for.

  • David beckCheese (unregistered)

    I don't know what's wrong here.

  • Mark L (unregistered)

    Back around 1975 I worked for a computer service bureau. We had an IBM 370 model 145, a 32-bit machine. We provided computer services such as accounting for companies that did not have their own computers.

    We took on a new customer that migrated their accounting system to ours from a different computer. I think it was a GE-600. The accounting system was written in Fortran. Yes, Fortran. I don't know why. But not problem. The 370 had a Fortran compiler.

    When the first report was printed, the numbers didn't quite match up. $20,000.12 plus $20,000.12 yielded $40,000.25.

    You've probably figured it out. The programmers used floating point, because Fortran didn't have fixed-point like COBOL did. The mantissa for the 36-bit computer had 28 bits but in the 370 the mantissa had 24 bits.

    So we had to go through the code, changing all the floats to doubles.

  • COBOL Dilettante (unregistered)

    That reminds me of the hilarious time when someone tried to move a S9(5)V9(7) value to a S(9)5V9(5) field.

  • patrick (unregistered)

    Ah well, what comes adecimal, goes adecimal

  • (nodebb) in reply to jeremypnet

    Actually this is what the modulo operator is for.

  • Tinkle (unregistered) in reply to jeremypnet

    That is what my rounding account is for - just pop the cent in there so it does not get lost.

Leave a comment on “The Rounding Error”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article