http://www.perlmonks.org?node_id=648428


in reply to DBI on windows problem

Please show us a small portion of the code that illustrates the problem. While it's conceivable there is a bug in the software, it's much more likely that there's a bug in your code. The situation you describe sounds like it would be a fertile place for race conditions to grow.

Replies are listed 'Best First'.
Re^2: DBI on windows problem
by txtoolman (Initiate) on Nov 01, 2007 at 16:20 UTC
    ------------------------------------------------------
    11-1-2007 -- The DELETE line is where the problem lies. Here is the code:

    use DBI;

    $dbh = DBI->connect('dbi:ODBC:Tradchem2005');
    #--select * from xcontacts
    $sql1 =
    "UPDATE xcontacts
    SET NEWCOLUMN8 = 'X'
    where sysparentid in (select sysrowid from clients where loaddate >= (GETDATE()-7)) and contactname <> '' ";

    #--XCONTACT TO CONTACTS
    $sql2 = "delete from contacts where sysrowid in (select sysrowid from Xcontacts where newcolumn8 = 'X') ";

    $sql2a = "
    Insert Contacts Select Address4, AddInterests, Child1Birthday, Child1info, Child1Name, Child2Birthday, Child2Info, Child2Name,
    SysRowID, SysRoute, SysParentID, SysDateAdded, SysDateUpdated, Address1, Address2, Address3, CallWhen, City, ColComment,
    CustomerName, ContactName, Country, county, Division, EmailAddress, Ext1, Ext2, GoalofCall, HotButton, LastCalled, Leadstatus,
    Birthday, PersonalData, PersonalIntr, ZipCode, ReportsTo, Salutation, Specialty, State, Phone1, Phone2, FAXnumber, Title, TypeUpdate,
    cellPhone, Pager, SysParentTable, ReportsToID, Child3Birthday, Child3Info, Child3Name, Department, Hobbies, MoveDate, MoveTo,
    NewColumn1, NewColumn2, NewColumn3, NewColumn4, NewColumn5, NewColumn6, NewColumn7, NewColumn8, OrphanContact,
    Spouse, Spousebd, SpouseInfo, WedAnniv, QBType, PhoneType, ContactIDnumber, ContactNumber, ContactPurpose, CountryPhoneCode,
    FirstName, LastName, YearStarted, CorpID, ContactNameOldSys

    from Xcontacts where newcolumn8 = 'X'";

    $sql3 = "
    UPDATE Xcontacts
    SET NEWCOLUMN8 = NULL
    WHERE NEWCOLUMN8 = 'X' ";

    $sql4 = "
    UPDATE contacts
    SET NEWCOLUMN8 = NULL
    WHERE NEWCOLUMN8 = 'X' ";

    $getinfo = $dbh->prepare($sql1);
    $getinfo->execute();
    $rcount1 = $getinfo->rows;
    print OUTFILE ("SQL1 execute finished -- $rcount1 \n");

    $getinfo = $dbh->prepare($sql2);
    $getinfo->execute();
    $rcount2 = $getinfo->rows;
    print OUTFILE ("SQL2 execute finished -- $rcount2\n");

    $getinfo = $dbh->prepare($sql2a);
    $getinfo->execute();
    $rcount2a = $getinfo->rows;
    print OUTFILE ("SQL2a execute finished -- $rcount2a\n");

    $getinfo = $dbh->prepare($sql3);
    $getinfo->execute();
    $rcount3 = $getinfo->rows;
    print OUTFILE ("SQL3 execute finished -- $rcount3\n");

    $getinfo = $dbh->prepare($sql4);
    $getinfo->execute();
    $rcount4 = $getinfo->rows;
    print OUTFILE ("SQL4 execute finished -- $rcount4\n");

    $dbh->disconnect;
    close (OUTFILE);
      Nothing in that jumps out at me as wrong (on the Perl side) except that you don't set RaiseError, warnings, or strict. Perhaps adding those will give you some more information.

      On the off-chance that there's a bug in your version of DBD::ODBC's rows(), you could see if the results are any different with just $rcount2 = $getinfo->execute() which should also return the rows affected for non-SELECT statements.

        I used the code you suggested - no change. Then I defined a second $dbh (identical to the first one), and used the new $dbh with the delete statement. I got the numbers I was suppose to get. I'm very curious why this is needed for the delete line, but for the updates and insert lines, there are no problems. One other thing I was thinking: would using the Win32::ODBC module be more reliable?