Sorry about that, the error really means: the handle of the record in question is a duplicate of another handle, in this case, of the one that is used in a different file: bin/bpeajo/BPEA_2003_02_01.rdf. And that file does not have to be checked again (to see if that is a conflict), because it was ready relatively recently and hasn't changed since. Therefore RePEc::Index can safely draw the conclusion that the handle is still in conflict and, therefore, it is excluded from the processing. Sometimes the decision about the conflict is deferred until the second file is checked. -ivan On Sat, Feb 14, 2009 at 11:37 PM, Thomas Krichel <krichel@openlib.org> wrote:
Christian Zimmermann writes
I am getting really frustrated with some templates that just refuse to load into RAS.
This case is about Frank Westermann who cannot get RePEc:bin:bpeajo:v:34:y:2003:i:2003-2:p:1-112 into his profile. I applied updareq to bin/bpeajo and to bin/bpeajo/BPEA_2003_02_Tornell.rdf multiple times, to no effect. I am at a loss now, as this has been dragging for several weeks now.
From the log, when I try it
Sat Feb 14 16:06:29 2009 request: source: /home/aras/acis/bin/updareq [31834] collection: RePEc update: bin/bpeajo/BPEA_2003_02_Tornell.rdf () U DATAFILE_START: bin/bpeajo/BPEA_2003_02_Tornell.rdf file: bin/bpeajo/BPEA_2003_02_01.rdf no need to check it to draw conclusions the record is still there U DATAFILE_FINISH: bin/bpeajo/BPEA_2003_02_Tornell.rdf Sat Feb 14 16:06:29 2009 processed bin/bpeajo/BPEA_2003_02_Tornell.rdf in RePEc Sat Feb 14 16:06:29 2009 time: 0 wallclock secs ( 0.24 usr + 0.01 sys = 0.25 CPU)
I have never seen
no need to check it to draw conclusions the record is still there
before.
It does not appear that the record is in the database
aras@nebka:~$ mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 72470 Server version: 5.0.32-Debian_7etch8-log Debian etch distribution
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql> use rdb; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A
Database changed mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112"; Empty set (0.00 sec)
mysql> select id from resources where id = "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112"; Empty set (0.00 sec)
mysql> select id from resources where id like "repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112%"; Empty set (0.00 sec)
In phpmyadmin, running
SELECT * FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:v:34:y:2003:i:2003-2:p:1-112' USING latin1) COLLATE latin1_swedish_ci
gives an empby set, and so does
SELECT * FROM `resources` WHERE `id` LIKE CONVERT(_utf8 'repec:bin:bpeajol:%' USING latin1) COLLATE latin1_swedish_ci
In the code aras@nebka:~/acis/lib/RePEc/Index/History/Handle.pm
if ( $status ) { # will queue p "will check it"; push @current, $_; $files_to_check -> {$fn} = 1;
} else { p "no need to check it to draw conclusions";
# Is that file known to contain a record with the same id? # CONSISTENCY CHECK
my $frec = $UPDATE -> get_file_record( $fn ); if ( $frec ) { my $present_there; my $list = $frec -> templates_list; foreach ( @$list ) { if ( $_ eq $id ) { $present_there = 1; } } if ( $present_there ) { p "the record is still there"; push @current, $_;
} else { p "the record is no longer there"; push @lost_present_file, $fn; } else { p "the file is no longer there"; push @lost_present_file, $fn; } } }
It seems to think the record is there, but is not.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run