I'm about to pull my hair out

[fergmj]

ok. I am a decent perl programmer (I think) and I have finished my application and everything works except for ONE issue and I am about to rip my hair out over it so I am asking for some help. I've been staring at this for a long time so maybe I'm just too close to the problem and I can't see it.

So I have a block of code and it executes as it should

elsif ($beginning eq "edit")
    {
    my $edititem = $q->param("id");
    if (my $row = select_item ($dbh, $edititem))
        {
        display_edit_form ($row);
        }
    else
        {
        print "<FONT FACE='Arial' SIZE=2>No record with that ID was found";
        display_current_items_print ($dbh);
        }
    }

I get to the select_item subroutine just fine but in this subroutine, it is getting locked up on the $sth->execute($id). In fact if I just hard code in an id and make

my $sql = qq{ SELECT * FROM export WHERE id = 36};

it still doesn't work
it just gets stuck and never does anything

any ideas -- I am open to any comments -- THANK YOU in advance!

sub select_item
	{
        my ($dbh, $id) = @_;
        my ($sth, $row);
        my $sql = qq{ SELECT * FROM export WHERE id = ?};
        $sth = $dbh->prepare ( $sql ) or die $dbh->errstr;
        $sth->execute($id) or die $dbh->errstr;
	$row = $sth->fetchrow_hashref();
	$sth->finish();
        return ($row);
	}

 

[mikrom]

I'm not sure why rvBasic feels that auto-incrementing is a bad idea

Here I agree with rvBasic at 100%

I explain why it's IMHO a bad idea:
As our autoincrement-table was recreated I compared it with the original production table and saw that the autoincrement-field by the repaired test table has different values as by original production table, that is the records are numbered in other way as by the original, so searchig by this field in select-where-clause would give different results.
But we use this autoincrement field only as an unique index for COBOL programs - we do not search by it in select-where-clause.

 

[mikrom]

PaulTEG,

Thanks for advice. It's probably possible in DB2 too. I will search for it in manuals

 

[rvBasic]

mikrom captures the major problem with auto-incrementing fields: their values are not stable and can change (without your knowledge). Searching on previously retained values is not guaranteed to give consistent result. I believe that some data base systeems (Oracle ?) do not even support them natively.

Although it seems counterproductive to re-invent the wheel, you can always define a field as numeric (or even alphameric) and use your own written auto-increment routine when adding a new record to the table. As the underlying database management system is now not aware of the "auto-incrementation" it will not try to change the value when re-organizing the table.


_________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]

 

[PaulTEG]

if you restore a mysql database from a dump, then the original auto incremented values should be the same as the original database, unless you chose to recreate the data without the autoincremented key, and the autoincrement value is greater than the original value.

Auto increment is available AFAIK on pretty much every RDBMS, and I've yet to have problem with it ...

Paul
------------------------------------
Spend an hour a week on CPAN, helps cure all known programming ailments ;-)