in reply to Re^6: Relational table with perl DBI
in thread Relational table with perl DBI

Now I really got it. Using the placeholders method for filling the tables requires the precise order of the column. Using a hash means that all data is scrambled

Plus, in this aproach the 'event' column is in the same table as the article.

Is there a away to reorder a hash index following a specific pattern ? how can I get the 'event' column to be treate separetly of the article table ?

Replies are listed 'Best First'.
Re^8: Relational table with perl DBI
by Neighbour (Friar) on Mar 13, 2013 at 15:01 UTC
    That was what @{$hr_output}{@fields} was supposed to catch....it gives you the values of the hash in the order of @fields.
    You don't have to follow the exact same order as the fields are defined in the table, but you will have to follow the same order you specified in the INSERT-query, which is why I used @fields a lot at that point.
    Also, it seems I made a slight mistake for the last_insert_id-select. It should be<br? my $sth_select_last_insert_id = $dbh->prepare( qq( SELECT LAST_INSERT_ID() )); (Note the added ()).
    The other errors are all a result of this. First the query fails (syntax error), which results in an undef result.
    But when executing it (at my $article_id = ($dbh->selectcol_arrayref($sth_select_last_insert_id))->[0]; I immediately dereference it. But undef is not an arrayref, so that won't do (and perl complains about that).
    Then when trying to insert the undef (which is NULL when stored in a database) in the article_event_index table, an error occurs, which leaves $inserted_records containing undef. When comparing that to a value, perl warns (but proceeds anyway) about that.
        What does your event-table look like? It seems there is no column named event (even though your original post showed there should be).
        Once again, the insert query fails, $inserted_records becomes undef which doesn't quite compare to a number.