Decisions, decisions... app flow control - NULL

[ATS16805]

hi there. my current project is to be my first venture into purely object oriented structure for database access ( as much as is practical... at least).

this probably doesn't have as much to do w/ classes and their lot as it does with basic development methodology-- or even strategic HTML form planning. i dunno..

okay-- i just realized that the several "blank entries" here in the test (MySQL 5) database i'm using on localhost are probably NOT going to be in the production model. (meaning-- throughout development thus far, i've duplicated entries by hitting submit multiple times, and all that jazz-- you've probably been there). i've left the blank stuff in there-- at first just because it didn't occurr to me that it's not a real reflection of what might be in production, but then i thought-- why not design the app to handle NULL entries... ya never know what kind of circumstance previously unrevealed might lead to such an entry by the client, and if the app can't handle a blank field where all of the code is designed to have values... then i suppose that's going to be a problem.

i may not be that great w/ programming-- but i do try to plan ahead. perhaps one of the reasons i am where i am (ie. this is my first venture w/ OOP stuff...) is because of the extensive amout of trial and error i tend to do in quite an OCD sort of habit. if nothing else, i suppose i've at least partially filled the emptiness left by the lacking of formal CompSci / software engineering education. blah, blah...

i'm looking for opinion from those of you who've been around the block (or those of you who are in that trial and error learning stage-- because of your attention to detail and fresh-minded research). How would you handle the situation in which queries might be executed on fields which aren't populated? OR-- perhaps i could reverse that, and perhaps more the responsible method-- to avoid letting NULL values go into the database at all-- with good ol' conditional logic, or flow control even based on MySQL error and/or javascript magic (although i'd rather avoid javascript for accessibility's sake).

here i face two problems:
1.) i'm unfamiliar w/ technique for using mysql error to control flow-- i tend to just think of an app 'breaking' when there's a mysql error-- but i know it doesn't need to be that way (for use of an "Error_Handler" class, perhaps?)
2.) i'm undecided on how to approach it-- "if / then" logic? or perhaps something more simple, tied to the HTML Form itself-- disallowing an incomplete entry.

hmmm... i feel kinda stupid asking for advice on this-- considering it's probably a rather rudimentary concept, but i'd rather feel stupid here w/ you than to feel stupid telling a client why his app is all messed up. hehe

thanks!!

[NogDog]

Well, the place to start for any columns which are not to be allowed to be null is to define them as "NOT NULL" in your table column definition. If you want to trap that error in your PHP code, you can look for an error code of 1048:

// method where query is executed:
function exectueQuery($sql)
{
  $result = mysql_query($sql).
  if(!$result)
  {
    $this->error(mysql_errno())
  }
  else
  {
    // continue processing...
  }
}

// method to handle mysql errors:
function error($errno)
{
  switch($errno)
  {
    case 1048:
      // handle "null not allowed" error here
      break;
    case 1054:
      // handle "unknown column" error here
      break;
    // etc....
    default:
      // default error-handler here
  }
}

[ATS16805]

hey there, thank you very much for the advice. this is precisely the type of thing i'm looking for. -- let me ask you this, considering your reply...
(and btw-- yeah, i've got the not null bit going, but like you illustrated, it's the php part i need to manipulate)

in the past, i really haven't interacted w/ the mysql_error() other than just the ever so common, "...or die(mysql_error());.." and i guess i was always just happy to ensure that an app would never get to that part. but from most OOP php stuff i've seen, i recognize a commonality of harnising the mysql_error-- in an error reporting class (obviously someting i would have not entertained prior to fiddlin' w/ Class stuff). just putting two and 2 together, i'm guessing it's because-- once an app begins getting large enough to the point that several Classes are involved, and all kinds of wild stuff is going on-- to attempt to be either dead or not-dead just doesn't provide enough options for the vast nature of the app... ? is this why i tend to see more of it in OOP stye? OR-- is this method a prerequesite?

(sorry for so many questions... i type as i think...)

EDIT: -- hey! nogdog's web site(s) definitely worth a look. very well done, and thoughtfully designed, i think.