Comment On Form Invalidation

This ("There is a field...") is typical if the application doesn't check the field sizes; when the insert into the database fails, all it can do (just looking at the error code) is to tell the user that for at least one field the value is too large.

and Data Entry Jesus wept...

Funny. I'm pretty sure that it took longer to write the FAQ article than it would have to correct the bug.

On the bright side, though, you may avoid the draft due to computer error!

Error, there is. Size or type field, you must.

R.Flowers:

Funny. I'm pretty sure that it took longer to write the FAQ article than it would have to correct the bug.

The FAQ was probably not written by the programmer(s).

There is even a WTF in the FAQ: It says Date of Birth, and the form says Birthday. A small nit for sure, but its there.

Anonymous:

There is even a WTF in the FAQ: It says Date of Birth, and the form says Birthday. A small nit for sure, but its there.

I don't think it's the same program. Note that in the example screen, the birthday was entered with slashes.

Anonymous:

There is even a WTF in the FAQ: It says Date of Birth, and the form says Birthday. A small nit for sure, but its there.

The FAQ is from a different system...

Anonymous:

There is even a WTF in the FAQ: It says Date of Birth, and the form says Birthday. A small nit for sure, but its there.

The FAQ is for the web site, not the program.

The Real WTF™ is the Selective "Service" exists in the first place.

My  name is Harsh and I'm here to say,
user acceptance testing is a fun way,
to test the application and make people glad,
you call it valid, I call it salad,
Cint made me think C,
Who would have thought it was VB?
The REAL WTF is the language it was written in,
finding that out made me sit and spin,
spin and spin,
till I felt like shit,
then I puked and wallowed in it.

On the second error.....

For some reason, VB programmers don't know how to properly trap errors. Somehow they all know about "On Error Resume Next", but ask them what it actually does and they stare at you with a blank look as if they don't need to know. This is one of those cases. In this case, the fix is literally 5 lines. Well, the fix could be 20 lines if you want to add all possible failes and detailed instructions for fixing. Although, it could probably be squeezed... who knows.... the POINT I'm trying to make is that anyone who only knows how to "program" in vb, doesn't know how to program. What frustrates me even more is that VB tends to make the people who fall into that category think that they actually can program. I hate VB. I hate VB so much... OH SO MUCH....

Today I got a support e-mail:
"Do you have this sample code to free the image in memory in VB?"

The customer is using .NET. The e-mail was a resonse.... The original was the exact code they ask for (15 lines including DLL Imports)... The problem with the code? The code was in...... C#. This person was unable to translate 15 lines of C# to VB.NET.

Times like this I want to wrap my hands around someone's neck... Awell....

The problem could be avoided by just setting the maxchars property on the html controls. . .

Sorry, Uncle Sam, I couldn't register for the draft because my birthday caused an integer overflow!

I can't enter my date as 5/20/1981?  I have to enter 05201981?  Lazy programmers!

Hey, my capatcha test is "truthiness".  Have you given royalties to Steven Colbert?

I like maintaining other people's garbage web apps.  Like when they use vbscript's CInt() on the id from the querystring to weed out sql injection attacks.  I like how it always weeds out the record itself when the identifiers(always autoincrement) get bigger than 32767.

ammoQ:

R.Flowers:

Funny. I'm pretty sure that it took longer to write the FAQ article than it would have to correct the bug.

The FAQ was probably not written by the programmer(s).

That wouldn't make the point less valid.

The following could have happened:



- lazy or incompetent or both programmer uses CInt(input).

- Within half an hour, that part is tested and judged to accurately process numbers and reject NaNs. Spec fulfilled!

- weeks later, the product is shipped.

- within days, a call comes in, stating that particular error message

- the support team contacts the development team there is an error such and such.
- the development team looks into it.
- the next day, the development team communicates back what the cause is.
- the support team talks to management about what needs to be done.
- the next day, management decides not issue a patch, but to add to the documentation.
- somewhere in the week after that, an entry gets added to the FAQ with this problem and its solution -- which really is a workaround, not a fix.
- the problem remains in the FAQ forever and never gets solved.


OR

- The programmer formats the input with a few deft keystrokes in 5 minutes.
- The world is a happier place.

Anonymous:

The problem could be avoided by just setting the maxchars property on the html controls. . .

The first program doesn't look like a web application to me.

GoatCheez:

Today I got a support e-mail:
"Do you have this sample code to free the image in memory in VB?"

The customer is using .NET. The e-mail was a resonse.... The original was the exact code they ask for (15 lines including DLL Imports)... The problem with the code? The code was in...... C#. This person was unable to translate 15 lines of C# to VB.NET.

Times like this I want to wrap my hands around someone's neck... Awell....

Wow, excellent customer service there, your customer asks for VB code sample and you reply with C# code. I guess YOU were unable to translate the VB.NET code to C#, but hey, the customer is always wrong. Way to go!

dhromed:

ammoQ:

R.Flowers:

Funny. I'm pretty sure that it took longer to write the FAQ article than it would have to correct the bug.

The FAQ was probably not written by the programmer(s).

That wouldn't make the point less valid.

The following could have happened:



- lazy or incompetent or both programmer uses CInt(input).
(snip)
- the problem remains in the FAQ forever and never gets solved.


OR

- The programmer formats the input with a few deft keystrokes in 5 minutes.
- The world is a happier place.

True, but maybe the program was written by someone who is no longer available (maybe a contractor or he got fired, doesn't seem too unlikely...); nobody wants to touch the source unless there is a really strong reason to do so; as long as it can be "fixed" in the FAQ, they go the "safe" way.

pjsson:

GoatCheez:

Today I got a support e-mail:
"Do you have this sample code to free the image in memory in VB?"

The customer is using .NET. The e-mail was a resonse.... The original was the exact code they ask for (15 lines including DLL Imports)... The problem with the code? The code was in...... C#. This person was unable to translate 15 lines of C# to VB.NET.

Times like this I want to wrap my hands around someone's neck... Awell....

Wow, excellent customer service there, your customer asks for VB code sample and you reply with C# code. I guess YOU were unable to translate the VB.NET code to C#, but hey, the customer is always wrong. Way to go!

READ WHAT IS SAID. The customer never specified the language at first. I did reply with translated VB code. I also replied nicely...

if(validation_error) exit(1); // bad user, no cookie for you

That is some WTF! Having said that, I always find it difficult having to fit a lot of input fields on one page. It's difficult to end up getting it looking OK without being confusing or messy!

Of course, error messages like "There is a field that doesn't fit the size or type" make things a hundred times worse...

I like it: http://www.sss.gov/regver/faqweb.htm

I bet the code behind that error is something like

foreach (Control c in this.Controls)
{
    if (c is TextBox && c.Text.Length > 25)
    {
       MessageBox.Show("Some horribly vaugue message");
    }
}

Sadly, anyone who has dealt with the FAFSA or paid student loans online has
undoubtedly noticed that they require DOB in MMDDYYYY format. Because,
lord knows, modern languages are completely unable to parse
human-readable dates.

FWIW, in Connecticut (and elsewhere, I
would imagine) entering dates into crime information searches is still
largely done in this format. I assume that this is so deeply entrenched
in Gub'ment functioning that they don't even realize it's a WTF.

The WTF for me is that the developers clearly don't know the rule against forcing users to input data in "special magic" formats.  It's perfectly simple to break out dates into drops (or a combo of drops and year entry inputs, because I actually don't like indefinitely-long year drops).

It's even more simple to check each input field for correct input and then hook up an error message for incorrect inputs tied to the ID of the input field generating the error.  Sheesh.  Give me a break.  This is form validation 101 stuff.

 

Captcha == "paula"  Heh.  (Well, before I remember to log in, anyway.)

ammoQ:

... maybe the program was written by someone who is no longer available (maybe a contractor or he got fired, doesn't seem too unlikely...); nobody wants to touch the source unless there is a really strong reason to do so; as long as it can be "fixed" in the FAQ, they go the "safe" way.

OK, but this is the Selective Service. Maybe I'm expecting too much.

Developer: Ah, crap! Somebody put '--; DROP TABLE tblPotentialDraftees' instead of their last name. Oh, well, screw it - they'll never bring back the draft anyway!

<cue Operation Iranian Shitstorm>

Uncle Sam: Now, we just need a few hundred thousand more troops... What!? No names!? Where are those three government contractors we hired?

Enter stage left: You wanted us boss? Woo-woo-woo! Nyuk-nyuk!

* Please don't make fun of me if my SQL injection is wrong. :)
** Please note that my little skit does not neccessarily reflect my opinion of the Selective Service.

alias:

I bet the code behind that error is something like

foreach (Control c in this.Controls)
{
    if (c is TextBox && c.Text.Length > 25)
    {
       MessageBox.Show("Some horribly vaugue message");
    }
}

I bet on something like this (read my First message):

function insert_foobar(p_foo in varchar2, p_bar in varchar2) return varchar2 is
  e_tooLong EXCEPTION;
  PRAGMA exception_init(e_tooLong,-4061);
begin
  insert into foobar(foo, bar) values (p_foo, p_bar);
  return null; /* null indicates success */
exception
  when e_tooLong then
    return 'There is field that it doesn't fit the field size or type';
end;


Poultine:

Sadly, anyone who has dealt with the FAFSA or paid student loans online has undoubtedly noticed that they require DOB in MMDDYYYY format. Because, lord knows, modern languages are completely unable to parse human-readable dates.

FWIW, in Connecticut (and elsewhere, I would imagine) entering dates into crime information searches is still largely done in this format. I assume that this is so deeply entrenched in Gub'ment functioning that they don't even realize it's a WTF.

"Government and WTF, perfect together"

 

The (US) Internal Revenue Service, whose slogan is:

"We've got what it takes to take what you've got"

I love me some Engrish!!!!

What's next? I suggest this:

"The database server reported some bogus error messages, and refused to enter your data in the tables. If you want to know what went wrong, please ask the database server. I did my best, but he is so headstrong with all those contraints and all."

GoatCheez:

On the second error.....

For some reason, VB programmers don't know how to properly trap errors. Somehow they all know about "On Error Resume Next", but ask them what it actually does and they stare at you with a blank look as if they don't need to know. This is one of those cases. In this case, the fix is literally 5 lines. Well, the fix could be 20 lines if you want to add all possible failes and detailed instructions for fixing. Although, it could probably be squeezed... who knows.... the POINT I'm trying to make is that anyone who only knows how to "program" in vb, doesn't know how to program. What frustrates me even more is that VB tends to make the people who fall into that category think that they actually can program. I hate VB. I hate VB so much... OH SO MUCH....

Today I got a support e-mail:
"Do you have this sample code to free the image in memory in VB?"

The customer is using .NET. The e-mail was a resonse.... The original was the exact code they ask for (15 lines including DLL Imports)... The problem with the code? The code was in...... C#. This person was unable to translate 15 lines of C# to VB.NET.

Times like this I want to wrap my hands around someone's neck... Awell....

One shouldn't make generalizations. Some VB programmers actually have a clue. And they can even spell 'response' and 'fails'.

mrprogguy:

The WTF for me is that the developers clearly don't know the rule against forcing users to input data in "special magic" formats.  It's perfectly simple to break out dates into drops (or a combo of drops and year entry inputs, because I actually don't like indefinitely-long year drops).

It depends on. A power-user who uses the program 9-5 every day probably prefers a simple text field for date input instead of three drop-downs. An occasional user of a web application is better served with three fields (drop downs, combos) or some kind of date picker.

It's even more simple to check each input field for correct input and then hook up an error message for incorrect inputs tied to the ID of the input field generating the error.  Sheesh.  Give me a break.  This is form validation 101 stuff.

It's simple, but it might also violate the DRY (don't repeat yourself) principle. If the maximum length of the form field is not automatically connected to the size of the corresponding database column, it's more than likely that they will differ sooner or later.

GoatCheez:

On the second error.....


.... The original was the exact code they ask for (15 lines including DLL Imports)... The problem with the code?

oh....
...AND they don't match present with past tense in the same sentence....

Poultine:

Sadly, anyone who has dealt with the FAFSA or paid student loans online has undoubtedly noticed that they require DOB in MMDDYYYY format. Because, lord knows, modern languages are completely unable to parse human-readable dates.

FWIW, in Connecticut (and elsewhere, I would imagine) entering dates into crime information searches is still largely done in this format. I assume that this is so deeply entrenched in Gub'ment functioning that they don't even realize it's a WTF.

Of course, it's a government agency...  What's more surprising is that the instructions aren't something like this...

1.  Fill out form online.  Handwritten forms not accepted.

2.  Print 3 copies of form.

3.  Fax 1 copy to your local branch office (include a self-abused stomped antelope if you want this form returned to you...  ;)  )

4.  Bury 1 copy in a coffee can in your backyard, next to the dead hamster.

5.  Place the final copy on a wooden table (oak preferred).  Photograph paper, ensuring 2" wood border on all sides.  Develop film (digital not accepted).  Order print in 8x10 extra glossy, with frame.  Photocopy print, and fax to ISP to scan and put on web page.  Burn original over gas ring on stove.

 

The vague message is, I'm sure, just a programmer having fun.

Alex Papadimoulis:

This is no longer a mere FAQ. They should adopt industry-wide best practice and call it a "Knowledge Base".

I find it amusing that only VB developers comment on grammatical and spelling errors on here.

And of course, since they're using client-side VBScript, the validation will only work in IE.

Anonymous:

I find it amusing that only VB developers comment on grammatical and spelling errors on here.

As do I. As do I...

Anonymous:

I like it: http://www.sss.gov/regver/faqweb.htm

Hehe, a quick search and you find a few more:

http://support.salescart.com/faq-advanced.htm#q10
http://www.liberum.org/snitz/topic.asp?TOPIC_ID=3824

What's the best way to handle database validation to be immune from format changes? Say you work in a large organization and several applications access a database. The DBA for some reason changes a format, for example increasing length of some string column. Do all applications need to be changed or is it possible to query a database for data constraints? Haven't done any DB programming since SQL Server 97 and our application owned the DB scheme so we never had this problem.

pjsson:

Anonymous:

I like it: http://www.sss.gov/regver/faqweb.htm

Hehe, a quick search and you find a few more:

http://support.salescart.com/faq-advanced.htm#q10
http://www.liberum.org/snitz/topic.asp?TOPIC_ID=3824

What's the best way to handle database validation to be immune from format changes? Say you work in a large organization and several applications access a database. The DBA for some reason changes a format, for example increasing length of some string column. Do all applications need to be changed or is it possible to query a database for data constraints? Haven't done any DB programming since SQL Server 97 and our application owned the DB scheme so we never had this problem.

Another great use of stored procedures.   In .NET, the CommandBuilder class lets you query a stored procedure to see what datatypes and lengths all of its parameters are.  From there, your app has all it needs to know about the database schema and can validate input.  This does require an extra round-trip to the database rather than setting the parameters at the client, but it results in more accurate parameters and handles the situation you describe.  Also, your code is a little shorter and easier. 

Older ADO has a refresh() method (or something like that, don't remmeber exactly the name) of a command object that does the same.

Funny, that's a great question and something that is usually overlooked in the "stored procedures versus in-line code" debate.

- Jeff

dhromed:

ammoQ:

R.Flowers:

Funny. I'm pretty sure that it took longer to write
the FAQ article than it would have to correct the bug.

The FAQ was probably not written by the programmer(s).

That wouldn't make the point less valid.

The following could have happened:



- lazy or incompetent or both programmer uses CInt(input).

- Within half an hour, that part is tested and judged to accurately process numbers and reject NaNs. Spec fulfilled!

- weeks later, the product is shipped.

- within days, a call comes in, stating that particular error message

- the support team contacts the development team there is an error such and such.
- the development team looks into it.
- the next day, the development team communicates back what the cause is.
- the support team talks to management about what needs to be done.
- the next day, management decides not issue a patch, but to add to the documentation.
-
somewhere in the week after that, an entry gets added to the FAQ with
this problem and its solution -- which really is a workaround, not a
fix.
- the problem remains in the FAQ forever and never gets solved.


OR

- The programmer formats the input with a few deft keystrokes in 5 minutes.
- The world is a happier place.

To be fair you left some parts out of option 2.

• ...


• 
  The next day, management decides to fix the issue.
  


• 
  The issue is added to the issues log
  


• 
  The requirements, test, development and support teams give thier estimates for how long the fix will take.
  


• 
  A project planning meeting is held to discuss the priority rankng of the issue versus other open issues.
  


• 
  A project planning meeting is held to discuss which group will supply funding for fix to the issue.
  


• 
  A project planning meeting is held to discuss changes to the timeline to account for the addition of the issue to the project plan.
  


• 
  The programmer formats the input with a few deft keystrokes in 5 minutes.
  


• 
  That part is tested by the test team and judged to accurately address the issue.
  


• 
  A project planning meeting is held to develope a deployment plan for the fix.
  


• 
  A change request is issued to apply the fix to the UAT testing environment
  


• 
  The change request is finally approved after several minor typos are fixed.
  


• 
  That part is tested by the user acceptance test team and judged to accurately address the issue.
  


• 
  A change request is issued to apply the fix to the Beta testing environment
  


• 
  The change request is finally approved after several minor typos are fixed.
  


• 
  That part is tested by the beta test team and judged to accurately address the issue.
  


• 
  A change request is issued to apply the fix to production
  


• 
  The change request is finally approved after several minor typos are fixed.
  


• 
  Weeks later, the product is shipped.
  

pjsson:

Anonymous:

I like it: http://www.sss.gov/regver/faqweb.htm

Hehe, a quick search and you find a few more:

http://support.salescart.com/faq-advanced.htm#q10
http://www.liberum.org/snitz/topic.asp?TOPIC_ID=3824

What's the best way to handle database validation to be immune from format changes? Say you work in a large organization and several applications access a database. The DBA for some reason changes a format, for example increasing length of some string column. Do all applications need to be changed or is it possible to query a database for data constraints? Haven't done any DB programming since SQL Server 97 and our application owned the DB scheme so we never had this problem.

In Oracle, you could the something like this (this code could easily be generated):

function insert_foobar(p_foo in varchar2, p_bar in varchar2) return varchar2 is
   r_foobar foobar%rowtype;
begin
  begin
    r_foobar.foo := p_foo;
  exception
    when others then return 'foo is wrong';
  end;
  begin
    r_foobar.bar := p_bar;
  exception
    when others then return 'bar is wrong';
  end;
  insert into foobar values r_foobar;
  retun null; /* null indicates success */
end;

Using PRAGMA exception_init would allow for more detailed error checking.

I'm sure the next entry in the FAQ contains "/regver/register_nc.asp, line 243 .... entering non-numeric data in the Doc. Expire field". And so on, a special FAQ entry for every field with a different line number.

GalacticCowboy:

(include a self-abused stomped antelope if you want this form returned to you...  ;)  )

I've never heard that one.  I like it.

captcha=awesomeness

GoatCheez:

On the second error.....

... anyone who only knows how to "program" in vb, doesn't know how to program. What frustrates me even more is that VB tends to make the people who fall into that category think that they actually can program. I hate VB. I hate VB so much... OH SO MUCH....

Lighten up Francis

Anonymous:

I'm sure the next entry in the FAQ contains "/regver/register_nc.asp, line 243 .... entering non-numeric data in the Doc. Expire field". And so on, a special FAQ entry for every field with a different line number.

And that's why it is so hard to fix one single error - the line numbers would change, the whole FAQ would become invalid...