• Dave Null (unregistered)

    cat /dev/null>/dev/db

  • klerf (unregistered)

    TRWTF is putting code into production and only then checking it into source control.

  • Zug (unregistered)

    I take it that the obvious fix didn't work: $query .= odbc_iif("SUM(price) = 0", 0.0, "SUM(priceact)/SUM(" . odbc_iif("price != 0", 1, 0) . ")") . " AS price_avg ";

  • my name is missing (unregistered)

    The real WTF is people using something that hasn't even been patched in more than a decade. Security? we don't need no stinking security.

  • Reginald P. Smithington (unregistered)

    I still QA a FoxPro codebase. It keeps me gainfully employed. Really what gives it legs is the fact that you can use a SQL backend and keep your old FoxPro code for the frontend.

  • Chronomium (unregistered)

    FoxPro's opinion of determining datatypes is The Root Absolute Real WTF here. Holy giblets.

    "0" is not a single-digit number. Well it is, but it's also a two-digit number, a three-digit number, and in fact has an infinite number of digits in both directions. Deciding that a number is even an int or a float based on an example being 0 is futile. I wouldn't even think 0 being the first entry in a number set is uncommon, so there's no way this is a rare problem.

    Total design failure.

  • LCrawford (unregistered) in reply to Chronomium

    Clearly, a "0" is a candidate for storage as a bit field. Also a bit field can be a Boolean. So, store a "0", then store a "9.99", catch the exception, then try to retrieve the "9.99". Result? FILE_NOT_FOUND , so we must expect this field to produce True, False, or FILE_NOT_FOUND.

  • Warrier (unregistered) in reply to my name is missing

    Fortunately, FoxPro is not supported by modern malware

  • Dude (unregistered)

    Wouldn't saying odbc_iif("SUM(price) = 0", 0.00... be an option? Then it's not implicitly an integer, but explicitly a decimal/float/double/whatevertypethat supportsdecimals

  • Geoff (unregistered)

    irb(main):001:0> x = 0 => 0 irb(main):002:0> x.class.name => "Fixnum" irb(main):003:0> y = 0.0 => 0.0 irb(main):004:0> y.class.name => "Float"

    Lots of languages behave that way.

  • Zenith (unregistered) in reply to my name is missing

    The Real WTF is the defeatist mentality that only constant patching is secure. Back when programming was a profession practiced by professionals, a product could be usable on release. It's only with the advent of code monkeyism from hindustan that quality had taken such a massive nosedive thar has scared people into the cult of neverending patchwork.

  • Reginald P. Smithington (unregistered) in reply to LCrawford

    Trying to store the number 0 in a bit field will throw an error in FoxPro. The logical datatype supports values ".T." and ".F."

  • (nodebb) in reply to klerf

    TRWTF is putting code into production and only then checking it into source control.

    It sure would be! Just as well it didn't happen in that order in real life!

  • (nodebb) in reply to Dude

    So oddly, decimals seemed to be stripped, so "0.00" was effectively the same as "0" and would crash in the same way. However, there's another place in the code that we use "0000000" as a result, to make sure that there's enough of an int size first-row result for when another SUM() has digits in the millions :)

  • Wim de Lange (unregistered)

    I'm a little offended by this article. I've programmed for years in FoxPro as a tool for the smaller companies (up to 100 people) where Oracle and SQLserver are too expensive and it was a good product and a very fast database. If you use a 0 in your query instead of 0.00 then it is possible that the column in the created temporary table is integer instead of number. That is no WTF, that is standard FoxPro knowledge. And as others said, common to other languages as well.

    The real WTF with FoxPro is that if the users are connecting to a FoxPro database directly, they can bring down the whole table to his knees, making it unusable, by switching off (or crashing) their PC on the wrong moment. For that reason we switched the database to SQLServer while still using FoxPro as the language.

  • Patrick (unregistered)

    I've had the "pleasure" of working with a certain piece of crap written in FoxPro. Not only is the piece of crap in question insanely expensive - it's also software that human lives depend on. Yes - people can actually die if it fails. Trying to actually use it is ... fun. The entire thing is singlethreaded and blocked, so the damn thing stops pumping window messages when it's, for example, making a heavy DB query...

    It takes a small army of overpriced consultants to keep the damn thing running.

  • eric bloedow (unregistered)

    i am reminded of an old story where someone used a forced divide-by-zero instead of a Stop or End command! i forget his weird excuse.

  • sigh (unregistered) in reply to Zenith

    "It's only with ~~the advent of code monkeyism from hindustan~~ the advent of internet connected computers under constant security threat ~~that quality had taken such a massive nosedive~~ causing people to lose their privacy, money and security ~~thar has scared people into the cult of~~ that has lead to actual professionals realizing that the only way to keep closing the gap with hostile actors is neverending patchwork." FTFY

  • mike (unregistered) in reply to my name is missing

    Lol, the "data access layer" (I'm not sure that's the right term tbh) in the apps I support uses the open source version of LLBLGEN. LLBLGEN stopped being open source in 2002. The apps were written between 2008 and 2014...

  • [email protected] (unregistered) in reply to my name is missing

    This must happen a lot. We still have customers running on a Sybase database.

    I remember one Sybase db update completely ruining the production databases. From then on patches on our Sybase dbs were no longer done...

  • Zenith (unregistered) in reply to sigh

    Sorry you can't design a system that works and is secure but some of us can.

  • someone who's actually used FoxPro (unregistered)

    FoxPro does not determine the type of a field by looking at its value in the first record.

    It determines the field type in exactly the same way that SQL databases do: by looking at the table definition (while FoxPro's programming language is dynamically typed, its database engine most definitely is not).

    I'm not sure what exactly was actually going on here, but the explanation provided in the article is clearly wrong.

  • Guest Me Not! (unregistered) in reply to someone who's actually used FoxPro

    The article is fabricated, so don't think a lot over it.

  • peevee (unregistered) in reply to Reginald P. Smithington

    "Trying to store the number 0 in a bit field will throw an error in FoxPro. The logical datatype supports values ".T." and ".F.""

    .T. .R. .W. .T. .F.

Leave a comment on “Crazy Like a Fox(Pro)”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article