True. I agree it is better, but one thing I ran into recently here is that another coder looked at some of my code where a table had a default for inserts and a trigger for updates for maintaining the date and she didn't understand why I could get away with not supplying a value for that column. A problem easily fixed by adding a comment to the code. E.g.
# date modified field has in-server mechanism to maintain values, no need for application do so... (something to that effect) > -----Original Message----- > From: David N Murray [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 14, 2002 11:59 AM > To: Kipp, James > Cc: [EMAIL PROTECTED] > Subject: RE: best way to insert date/time into oracle table > > > Why not just put it as a constraint on the table to supply a > default value > of SYSDATE for the column? Then you don't have to deal with > it from the > program side at all. > > On Jun 14, Kipp, James scribed: > > > THANKS! I just found that out the hardway :) > > Thanks all for your help. SYSDATE is the best way to go for > my situation > > > > > > > -----Original Message----- > > > From: Jeff Seger [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, June 14, 2002 2:35 PM > > > To: Kipp, James > > > Cc: [EMAIL PROTECTED] > > > Subject: RE: best way to insert date/time into oracle table > > > > > > > > > Don't put SYSDATE in the execute. Put it in the prepared > statement: > > > > > > > > > my $sth = $dbh->prepare( "INSERT INTO stats VALUES > > > (SYSDATE,?,?,?,?)" ) > > > or die "Cannot prepare SQL statements from > $DBI::errstr\n"; > > > > > > foreach (@stats){ > > > chomp; > > > ($host, $user $cpu_pct, $mem_pct = split( /,/ ); > > > > > > > > > >
