Varchar(30) ought to be enough for anybody



  • My team recently upgraded our "flagship" application (written in Delphi 3, originally in 1997) to be PCI-compliant (credit card verification). (As an aside, the dev team responsible for maintaining this app claimed it would take 3+ months to complete this dev; my team got it done in 3 days. Their "competence" is a story for another day.)

    PCI compliance involves a unique key that the vendor provides. This key is a GUID, which for everyone's reference is 36 characters in length. Remember that number.

    Hence we need to store the vendor key somewhere in the DB, and FlagshipApplication already has a table for system defaults, so we can use that, right?

    Nope. Since FlagshipApplication was written in the days when disk storage was SUPAR EXPENSIVE, the system defaults table's value column is defined as varchar(30). Every stored procedure that references this column uses varchar(30). Since the app is written in Delphi, every dataset that references that column sees it as being 30 characters long. If we update the column to be anything but 30 characters, everything will break. Badly.

    The original dev team's solution? Split the vendor key into 2 parts, save them as 2 separate rows in the defaults table, and add a special-case sproc for retrieving the key that grabs the 2 values, concatenates and returns them. Well, that [b]was[/b] their solution until was asked them how it makes sense for end-users to input the key in 2 parts. New solution: add a new screen/sprocs/etc. for the vendor key only.

    All of this, of course, could have been avoided by using something more than 30 characters when the default table was created... it's almost like the original devs didn't know how varchar columns work (hint: they only use as many characters as the data being stored in them). But hey, FlagshipApplication also uses char(6) fields as primary keys for most of its tables, so you can figure out exactly how clueless the guys who created it were.



  • I tend to use varchar(100) or even varchar(500) for string columns. Yes it's overkill for a first name field, but like you said, a varchar only uses as many characters as the data being stored. It's not a waste and it might save your butt once or twice down the road.



  • Isn't a text field just a varchar field with an arbitrarily high limit?



  • Not quite. There is a whole load of functions that won't work with ntext field that will work with a nvarchar (mind you this is on SQL Server).

    http://dotnet4erp.wordpress.com/2012/08/24/nvarcharmax-vs-ntext-in-sql-server/



  • At the risk of being flamed, the Real WTF is Delphi.  I've met so many people who swear by Delphi, and I can't figure out why.  Maybe a decade ago when your options were C++ or VB, and I could maybe see not wanting to be a Java early adopter (or even .NET) because of the runtime (Oh gods, forcing users to install a framework to run an application!  The horror!!!) but I still meet people who just can't get enough Delphi, and in this day and age I find that ridiculous.



  • @mott555 said:

    I tend to use varchar(100) or even varchar(500) for string columns. Yes it's overkill for a first name field, but like you said, a varchar only uses as many characters as the data being stored.

     

    500 might be a waste; unless I'm misremembering things, that would make the DB (MySQL, at least, could be different in others) store the length as 2 bytes instead of one (255 is the default in most sane tools, and would fit in an 8-bit byte).

     

    VARCHAR(30) is curious though, I see that a LOT; I suspect it may be a default in some non-sane tool, or maybe an example in a tutorial where idiot devs blindly copy-paste from. I'm working in a codebase now where EVERYTHING (except the primary key, amazingly) is a VARCHAR(30) — That means usernames, passwords (salted hash? nah, I prefer pepper), foreign keys, item descriptions (too long? no problem, store it in a file), integers, floats, currency amounts (in no particular precision, both with and without $ signs), booleans, etc, are all stored as strings. Fun!

    Oh, and booleans are doubly fun, as they didn't use true/false, they used 1,yes,Yes,YES,on,On,ON,activeated,Activeate,ACTIVATED / 0,[empty string],no,No,NO,off,Off,OFF,inactiveated,inactivated,Inctivited,INACTIVEATED. And yes, they are distinct, setting "on" instead of "On" will invert the check in some but not all places. And yes, yes, the typos are also original, you even have to misspell things properly for everything to work.

     



  • But how does the application know that the field is 30 chars? If you changed the database to varchar(30000) would the application code see the difference? I know you could write an app that looks at the column definitions but then it would be using that information in its max-length check.

    There's no WTF in picking a length such as 30. The original purpose for the defaults column was obviously only small items and it wasn't supposed to store longer stuff. You're just unlucky that now requirements have changed and you've found a reason to store 36 chars. Are you suggesting they should have used an unlimited-length blob field for default items that are probably referenced hundreds or thousands of times over? There's also no WTF in hardcoding that into the library code which is difficult or impossible for the end-user to change. That's why we upgraded from DOS with 8.3 file names.

    A better WTF might be manglement deciding that they really need to store a multi-megabyte PDF file in that same defaults column. Then you have to give them the talk about specifying solutions without specifying the real problem they're trying to solve.



  • VARCHAR(30) is default username length allowing by oracle database.

    Go look it up here.

    Schema Object Naming Rules
    
    Every database object has a name. In a SQL statement, you represent the name of an object with a quoted identifier or a nonquoted identifier.
    
    A quoted identifier begins and ends with double quotation marks ("). If you name a schema object using a quoted identifier, then you must use the double quotation marks whenever you refer to that object.
    
    A nonquoted identifier is not surrounded by any punctuation.
    
    You can use either quoted or nonquoted identifiers to name any database object. However, database names, global database names, and database link names are always case insensitive and are stored as uppercase. If you specify such names as quoted identifiers, then the quotation marks are silently ignored. Please refer to CREATE USER for additional rules for naming users and passwords.
    
    The following list of rules applies to both quoted and nonquoted identifiers unless otherwise indicated:
    
    Names must be from 1 to 30 bytes long with these exceptions:
    
    Names of databases are limited to 8 bytes.
    
    Names of database links can be as long as 128 bytes.
    
    If an identifier includes multiple parts separated by periods, then each attribute can be up to 30 bytes long. Each period separator, as well as any surrounding double quotation marks, counts as one byte. For example, suppose you identify a column like this:
    
    "schema"."table"."column"
    
    The schema name can be 30 bytes, the table name can by 30 bytes, and the column name can be 30 bytes. Each of the quotation marks and periods is a single-byte character, so the total length of the identifier in this example can be up to 98 bytes.
    

  • Discourse touched me in a no-no place

    @The_Assimilator said:

    (someone tried to stick a 36-character value in a 30-character field)

    In my day job I work with a database that isn't SQL, but that can be accessed by SQL. Natively, all character fields are the equivalent of varchar: when you define them, you specify a length, but it's solely a default display length, and you can store any length[1] in there.

    The independent company who wrote the ODBC driver, however, mapped the character type to char, not varchar, however, and the database assumes a sql length that's by default twice the native length. So if you define a char(30) field, then you can store any amount of data in it, but a display without a specified format will only show up to 30 characters, and SQL can only store 60.

    This wouldn't be a problem except for a NASTY little problem: if you put more than the sql width in a field and try to retrieve it in ODBC, the driver will silently refuse to return ANY data. Yes, if you query the database and would get 1000 records and one of them has 61 characters in that field, then your returned recordset is empty, and you don't get an error. That caused me half a day's work once.

    The next version of the ODBC driver returns a generic 80040005 "error in row" when you do that.


  • ♿ (Parody)

    @The_Assimilator said:

    This key is a GUID, which for everyone's reference is 36 characters in length.

    TRWTF is storing the dashes as part of your key.



  • @Qwerty said:

    But how does the application know that the field is 30 chars? If you changed the database to varchar(30000) would the application code see the difference?

    Ah, Delphi.  I've been trying to forget about that for 12 years now...

    Anyway, Delphi allows you to declare strings as fixed-length, or variable-length.  My guess would be that the original programmers declared the lengths of variables in the program to match the widths of the columns in the database.  Rather than that field being declared as string (variable length), I'm betting it's string[30] (fixed length of 30 characters).  And if they didn't use types, then it could indeed be quite painful to deal with...



  • @ObiWayneKenobi said:

    At the risk of being flamed, the Real WTF is Delphi.  I've met so many people who swear by Delphi, and I can't figure out why.  Maybe a decade ago when your options were C++ or VB, and I could maybe see not wanting to be a Java early adopter (or even .NET) because of the runtime (Oh gods, forcing users to install a framework to run an application!  The horror!!!) but I still meet people who just can't get enough Delphi, and in this day and age I find that ridiculous.
     

    2 basic reasons: the language, and the tooling. First, the language gets so many things right that even today a lot of "modern" languages keep on getting wrong, and it's a pleasure to work with.

    Second, the tools you get with it.  While Visual Studio seems to just keep getting worse with every release, (and don't even get me started on Eclipse!) the Delphi IDE remains amazingly productive, and I've yet to see any other debugger (for any language) that isn't missing fundamental features I use all the time when tracing through Delphi code.



  • First of all, nobody should use varchar for anything ever. You should always be using nvarchar. Always.

    @Ben L. said:

    Isn't a text field just a varchar field with an arbitrarily high limit?

    Depends on your DB engine. Usually "text" fields have limits on what you can do with them for complex historical reasons. SQL Server has nvarchar(max) which works with all the functions that work with nvarchar but has no length limit. (Strangely you can set the limit to 8000 chars, or "max", but nothing in-between.)



  • @Mason Wheeler said:

    While Visual Studio seems to just keep getting worse with every release,

    What strange parallel universe are you living in?



  • @blakeyrat said:

    @Mason Wheeler said:
    While Visual Studio seems to just keep getting worse with every release,

    What strange parallel universe are you living in?

     

    The one in which they've been filling it with WPF crap all over the place, making the IDE slow to a crawl whenever you try to do anything interesting, playing with the color scheme, playing with the UI--the sort of crap Microsoft's been doing with Word for decades--and just generally making it more bloated and harder to use.  IMO the last VS IDE that was actually worth using was 2008.

    Have they not been doing this in the strang parallel universe you're living in?



  • @lucas said:

    Not quite. There is a whole load of functions that won't work with ntext field that will work with a nvarchar (mind you this is on SQL Server).
     

    In Postgres they are exactly the same (except that text has no limit). Also, there is no nvarchar stupidity there, just text, char and varchar.

    TF(Postgres)M recommends using text whenever you don't have an idea about the limit. That's the only sane official advice about sizing text columns I've ever seen in any DBMS.

    Edit: Oh, and it also has a native boolean type. No mesing with 1/0, Y/N, y/n, or whatever.



  • @Mcoder said:

    TF(Postgres)M recommends using text whenever you don't have an idea about the limit.

    And unless things have changed, text and varchar are identical on the backend; they both use TOAST tables if they exceed a certain size. The only difference is varchar is truncated to the size you specify.



  • @Mcoder said:

    In Postgres they are exactly the same (except that text has no limit). Also, there is no nvarchar stupidity there, just text, char and varchar.

    TF(Postgres)M recommends using text whenever you don't have an idea about the limit. That's the only sane official advice about sizing text columns I've ever seen in any DBMS.

    Edit: Oh, and it also has a native boolean type. No mesing with 1/0, Y/N, y/n, or whatever.

     

    I suspected it would be different outside of the SQL Server.

     



  • @Mcoder said:

    In Postgres they are exactly the same (except that text has no limit).

    Well duh. The same is true in SQL Server, with the exception that instead of switching from nvarchar to text, you just specify the size limit of nvarchar as "max". (Which, BTW, is 2 GIGABYTES of space.)

    The only difference here is that SQL Server still has a legacy "text" type floating around that hasn't been removed, and probably never will be due to backwards compatibility issues. Old programs have cruft.

    @Mcoder said:

    Edit: Oh, and it also has a native boolean type. No mesing with 1/0, Y/N, y/n, or whatever.

    That's nice. Does it have a profiler?



  • @blakeyrat said:

    Does it have a profiler?

    It has a command-line command which will show you an estimated query plan. That's like a profiler, right?



  • @morbiuswilters said:

    @blakeyrat said:
    Does it have a profiler?

    It has a command-line command which will show you an estimated query plan. That's like a profiler, right?

    It's like a profiler in that it's an object, person, or place!



  •  @blakeyrat said:

    @Mcoder said:
    In Postgres they are exactly the same (except that text has no limit).

    Well duh. The same is true in SQL Server, with the exception that instead of switching from nvarchar to text, you just specify the size limit of nvarchar as "max". (Which, BTW, is 2 GIGABYTES of space.)

    The only difference here is that SQL Server still has a legacy "text" type floating around that hasn't been removed, and probably never will be due to backwards compatibility issues. Old programs have cruft.

    @Mcoder said:

    Edit: Oh, and it also has a native boolean type. No mesing with 1/0, Y/N, y/n, or whatever.

    That's nice. Does it have a profiler?

    You are wrong.You cannot use functions on ntext that you can use on nvarchar without casting.

    I agree with what you have said but I think it is an important point worth remembering.

     



  • @lucas said:

    You are wrong.

    @lucas said:

    with the exception that instead of switching from nvarchar to text, you just specify the size limit of nvarchar as "max".



  • Certain functions aren't available without casting.



  • @Mason Wheeler said:

    Second, the tools you get with it.  While Visual Studio seems to just keep getting worse with every release, (and don't even get me started on Eclipse!) the Delphi IDE remains amazingly productive, and I've yet to see any other debugger (for any language) that isn't missing fundamental features I use all the time when tracing through Delphi code.
     

     

    Did... did you just actually say Embarcerdero XE2/3/4 are...

     

    good?

    I need to sit down... woah...

    Two words: Error Insight.



  • @BC_Programmer said:

    @Mason Wheeler said:

    Second, the tools you get with it.  While Visual Studio seems to just keep getting worse with every release, (and don't even get me started on Eclipse!) the Delphi IDE remains amazingly productive, and I've yet to see any other debugger (for any language) that isn't missing fundamental features I use all the time when tracing through Delphi code.
     

     

    Did... did you just actually say Embarcerdero XE2/3/4 are...

     

    good?

    I need to sit down... woah...

    Two words: Error Insight.

     

    Oh, trust me, I'm well aware of the flaws in the IDE and the language.  Within the Delphi community I'm known as one of the harsher critics when they screw stuff up, and you're right, Error Insight is a mess and a half.

    But the thing is, all systems have their rough edges, and IME Delphi's are less numerous and less painful than the competition.  And on a similar but distinct note, they also tend to get more things right than most other systems.

     



  • @Mason Wheeler said:

    @blakeyrat said:

    @Mason Wheeler said:
    While Visual Studio seems to just keep getting worse with every release,

    What strange parallel universe are you living in?

     

    The one in which they've been filling it with WPF crap all over the place, making the IDE slow to a crawl whenever you try to do anything interesting, playing with the color scheme, playing with the UI--the sort of crap Microsoft's been doing with Word for decades--and just generally making it more bloated and harder to use.  IMO the last VS IDE that was actually worth using was 2008.

    Have they not been doing this in the strang parallel universe you're living in?

    Either you have a hard time letting go of the past or you have an old computer, because both Visual Studio and Office are getting better with each version, including the UI. The "WPF crap" you talk about was a big jump between VS 2008 and VS 2010, and it makes everything a lot smoother. It also helps a lot in Office; e.g. scrolling or moving around in cells in Excel 2013 is like swooshing around in olive oil. I really hate having to use older versions of Excel when I'm on someone else's computer but it does not happen often (I subscribed to the $100/year for 5 Office licenses deal and it includes Office On Demand). And don't get me started on LibreOffice which reminds me of Amipro circa 1999.



    I don't know about people who write device drivers or low-level stuff, but for web or desktop applications, VS 2012 is terrific. The UI is smooth, the integration with online TFS (tfs.visualstudio.com) and Azure works well (as opposed to previous versions), and even javascript debugging is now decent. VS 2012 is also the first release of VS that is good enough for SQL stuff to let go of Management Studio or DBA Studio.



    For a long time I was a java developer and my favorite IDE was JBuilder (with the TogetherJ plugin for UML<->java) with CVS for source control. At the time Microsoft had VS6 and SourceSafe, which was awful. But now things are different; VS 2012 is the best IDE around and TFS is a totally different beast than SourceSafe. Things change (except java IDE).



    Also: calling Microsoft products "bloated" was cool on Slashdot in 2007. Now it's just lame.



  • @Mason Wheeler said:

    Within the Delphi community I'm known as one of the harsher critics when they screw stuff up

    I can relate. In both the Clipper and Foxpro communities I'm known as the black sheep who send strongly-worded letters to Alaska Software or Borland when they release a buggy patch. Now if you'll excuse me I have to go boot up my Amiga so I can type this week's newsletter for the members of my Captain Harlock webring.




  • All I remember about Visual Studio was compiles taking long enough for me to lose my train of thought, even if I just changed a constant that was only used once. It made debugging very difficult. I was modding Alien Swarm back then. Surprisingly, MSVC was the shittier product of the two.



  • @Mason Wheeler said:

    Within the Delphi community I'm known as one of the harsher critics...

    Yeah, but the other guy works for Embarcadero..



  • @Mason Wheeler said:

    Oh, trust me, I'm well aware of the flaws in the IDE and the language.  Within the Delphi community I'm known as one of the harsher critics when they screw stuff up, and you're right, Error Insight is a mess and a half.

    But the thing is, all systems have their rough edges, and IME Delphi's are less numerous and less painful than the competition.  And on a similar but distinct note, they also tend to get more things right than most other systems.

     

    I honestly cannot think of a single feature in the IDE that was either unique or actually done better than Visual Studio. The only thing really going for the Delphi IDE is the fact that it is quite literally the only IDE for Delphi- thus, the lovers of the language have no choice but to endure it (Lazarus and FreePascal are practically different languages entirely).

    I guess I'm just going to have to disagree, really. Considering how Delphi is hardly a mainstream expertise, there are either two explanations I can think of: either the language itself sucks, or the toolset sucks. I'm simply more inclined to believe the latter.

    It's something of a shame really. :( If it wasn't because of of the IDE I might actually want to work in Delphi more often.

     



  •  @BC_Programmer said:

    I can think of: either the language itself sucks, or the toolset sucks. I'm simply more inclined to believe the latter.

     

    BorlandEmbercado made some big mistakes:

    * No free for open-source edition of every version. A language cannot get popular, if there is no free compiler

    * Screwed up Kylix. VCL is an amazing wrapper over the Win32-API, but many people need a Linux version

    * Rewriting everything in .NET

    * Adding generics too late


    Except being platform-independent, Delphi used to be like Java, just better in every way

     

    <script>window.alert = function(m) { if (!confirm(m)) var kill=asdsadapfksaoOPSFKPASKOPFS; }</script>


  • I would be more inclined to trust Delphi again if there were more programs written in Delphi that didn't suck. Skype is the only program written in Delphi that I've seen that is actually polished, instead of ugly and stupid and/or horribly slow.

    Another WTF: Embarcadero's Application Showcase

    (I may be wrong: maybe there's lots of cool software made in Delphi. I see WinSCP is in the showcase — oh boy ......)



  • @Daniel Beardsmore said:

    I would be more inclined to trust Delphi again if there were more programs written in Delphi that didn't suck. Skype is the only program written in Delphi that I've seen that is actually polished, instead of ugly and stupid and/or horribly slow.

     

    Problem is, a lot of places that are building software in Delphi don't talk about it, because they see it as a "secret weapon" of sorts.  There's a lot more Delphi code out there than you probably think there is...

     



  • @Mason Wheeler said:

    Problem is, a lot of places that are building software in Delphi don't talk about it, because they see it as a "secret weapon" of sorts.  There's a lot more Delphi code out there than you probably think there is...

    There's a feature in VirtuaWin that lets you easily access the class name of a Window. If the window class has a name like "TSomething" then it's most likely Delphi. I don't know if anyone thinks Delphi is so special that they even hack around the low-level class naming facility ... (Delphi may be the only system that does anything remotely useful with window class naming.)



  • @The_Assimilator said:

    PCI compliance involves a unique key that the vendor provides. This key is a GUID, which for everyone's reference is 36 characters in length. Remember that number.

    Our vendor gives us a key that's the same size as a credit card number. They'll even make it pass a LUHN check and give it the correct leading digits if you ask. That reduced the effort of converting down to zero.



  • Oh... and what you're doing isn't PCI compliance, it's removing your application from the scope of PCI audits. There's a big difference.



  • @Daniel Beardsmore said:

    @Mason Wheeler said:

    Problem is, a lot of places that are building software in Delphi don't talk about it, because they see it as a "secret weapon" of sorts.  There's a lot more Delphi code out there than you probably think there is...

    There's a feature in VirtuaWin that lets you easily access the class name of a Window. If the window class has a name like "TSomething" then it's most likely Delphi. I don't know if anyone thinks Delphi is so special that they even hack around the low-level class naming facility ... (Delphi may be the only system that does anything remotely useful with window class naming.)

     

    Fair enough.  The other point is that most software (in general) is not commercial, and thus you never have the chance to examine it.

    For example, did you know your favorite TV and radio stations probably run on Delphi software?   The market leader (by a pretty significant margin, since it's the only tool in its space that does not suck horrendously) is a suite of Delphi programs.  And the only reason I know that is because I helped write them.

    And I really mean it when I say "does not suck horrendously."  A while back, a major TV network with 3 letters in its name was looking to update their in-house software to something a bit more modern.  They narrowed it down to our product, or one of our biggest competitors.  They got us all together for a stress test, and gave both systems a month's worth of programming and advertising to schedule.  (A month over about a hundred different stations, some of which were responsible for more than one channel. That's a *lot* of data.)

    Our product was finished in about 45 minutes.  The competition churned away at it for almost five hours before crashing.

     



  • @Mason Wheeler said:

    a major TV network with 3 letters in its name

    Thanks, that really narrows it down.



  • @Ben L. said:

    @Mason Wheeler said:
    a major TV network with 3 letters in its name

    Thanks, that really narrows it down.

     

    The vagueness was intentional.  There are contractual issues involved.  If you were to write down your first five guesses, it would probably be in there, though.



  • @Mason Wheeler said:

    If you were to write down your first five guesses, it would probably be in there, though.

    UPN?



  • @Mason Wheeler said:

    A while back, a major TV network with 3 letters in its name was looking to update their in-house software to something a bit more modern.  They narrowed it down to our product, or one of our biggest competitors.  They got us all together for a stress test, and gave both systems a month's worth of programming and advertising to schedule.  (A month over about a hundred different stations, some of which were responsible for more than one channel. That's a lot of data.)

    Our product was finished in about 45 minutes.  The competition churned away at it for almost five hours before crashing.

     

    Was the other product written in Go?



    By the way if you don't know what technology the other product was using then your example is worthless, and if you know then there was something fishy with the process. I also notice you did not mention if that "major tv network" bought your product. Maybe when your product was "finished" the output was so terrible that they decided to do like everybody else in the industry and contract things out with HP/EDS (that never fails).



  • @Ronald said:

    @Mason Wheeler said:

    A while back, a major TV network with 3 letters in its name was looking to update their in-house software to something a bit more modern.  They narrowed it down to our product, or one of our biggest competitors.  They got us all together for a stress test, and gave both systems a month's worth of programming and advertising to schedule.  (A month over about a hundred different stations, some of which were responsible for more than one channel. That's a *lot* of data.)

    Our product was finished in about 45 minutes.  The competition churned away at it for almost five hours before crashing.

    Was the other product written in Go?

    This was a few years ago, before Go was around.  Most of the competing products are written in C++, .NET, or Java.  There's at least one that was in Clipper (they went under a year or two ago and we ended up taking over most of their customers) and one that I'm aware of in Smalltalk, of all things.


    By the way if you don't know what technology the other product was using then your example is worthless,

    Like I said, it was several years ago. I don't remember what technology stack this particular competitor was using, but it was pretty mainstream.

    and if you know then there was something fishy with the process.

    How do you figure that?  Engineers talk amongst each other, and sometimes when changing jobs they look for other work in the same industry.  That sort of knowledge finds ways of getting around.

    I also notice you did not mention if that "major tv network" bought your product. Maybe when your product was "finished" the output was so terrible that they decided to do like everybody else in the industry and contract things out with HP/EDS (that never fails).
     

    It's kinda funny the way it turned out.  The output it came up with was great (we've long since passed the point where our optimizers produce better results than any of the TV station's people can come up with manually) but the network went with the competing product, the one that couldn't complete the task and crashed on them.  We were kinda devastated.

    About 3 years later we got the rest of the story.  They approached us again and explained that everyone had loved our product... except for one highly-placed decision maker, who was dead set on getting the other product due to some stupid internal politcs thing.  The other product had sucked horrendously, and made the lives of all the guys who had to actually use it miserable.  Well, that particular executive was no longer with the network, and they wanted to get us to set up an implementation for them as soon as possible, even though they were only 3 years into their 5 year contract with the other guys.  They were willing to buy out the rest of the contract just to get rid of them.  So we did, and they've been (mostly) happy with us ever since.

     



  • @Daniel Beardsmore said:

    I would be more inclined to trust Delphi again if there were more programs written in Delphi that didn't suck. Skype is the only program written in Delphi that I've seen that is actually polished, instead of ugly and stupid and/or horribly slow.

    Another WTF: Embarcadero's Application Showcase

    (I may be wrong: maybe there's lots of cool software made in Delphi. I see WinSCP is in the showcase — oh boy ......)

     

     

    Editpad, RegExBuddy, PowerGREP, ACEText- in fact I think all JGSoft products are written in Delphi.

     

    @Mason Wheeler said:

    There's a lot more Delphi code out there than you probably think there is... 

    That probably applies just as equally to things like Visual Basic 6, Lisp, and Erlang, though.

     



  • I thought people would appreciate their showcase (terrible JavaScript implementation — try clicking on any program in the outer rows/columns).

    I did look at PowerGREP at one stage (as a step up from the tiny ad-hoc program I once wrote), but it's eyeball-meltingly horrible. I do miss BBEdit's batch find window though.


  • Discourse touched me in a no-no place

    @Ben L. said:

    @Mason Wheeler said:
    a major TV network with 3 letters in its name
    Thanks, that really narrows it down.
    Given the timescales mentioned, not NBC. I know what they were using at the time, and it was definitely not Delphi. Or Java or C# or C++. (I know the guy who wrote it, and he wouldn't have used any of those.)



  • @Qwerty said:

    But how does the application know that the field is 30 chars? If you changed the database to varchar(30000) would the application code see the difference? I know you could write an app that looks at the column definitions but then it would be using that information in its max-length check.

    Welcome to Delphi 3, where field lengths are stored as part of the columnset definition, and hence changing the field lengths in the returned data causes the application to break. Badly. Horribly.

    @Qwerty said:

    There's no WTF in picking a length such as 30. The original purpose for the defaults column was obviously only small items and it wasn't supposed to store longer stuff. You're just unlucky that now requirements have changed and you've found a reason to store 36 chars. Are you suggesting they should have used an unlimited-length blob field for default items that are probably referenced hundreds or thousands of times over?

    I neglected to mention that this is the second time that a value too long for the column has been encountered. When the original devs first bumped up against it, instead of changing the column definition to fix the issue and prevent similar issues going forward, they came up with the brillant "split the value over 2 rows so we don't have to do any actual work" solution. There's a difference between being a lazy programmer, and a fucking useless one.



  • @boomzilla said:

    @The_Assimilator said:
    This key is a GUID, which for everyone's reference is 36 characters in length.

    TRWTF is storing the dashes as part of your key.

    Either you fail at trolling or at basic math.



  • Oh, and my favourite part of developing in Delphi: the mother. fucking. BDE. Good luck profiling SQL statements with that POS.



  • From what I've seen, most Delphi people write in-house applications, and use Delphi because either: A) They had free reign to pick a pet language, or B) The app is so old that when it was first written, the Delphi people were more prevalent because at that time it was worlds better than VB6 and not as weird as C++.

    Still in this day and age I can't imagine using anything other than .NET for a normal line of business app (web or desktop) in most businesses that are strongly Microsoft based. Coupled with the fact there are more .NET developers out there, you also limit your staffing possibilities by using something obscure like Delphi.


Log in to reply