I’m preparing to write a script to extract data from the LCP data base for ingestion into Dspace.
While looking at the raw contents of the database using CocoaSQL, I noticed a bunch of records from the last few days, all with the same LS#: namely, LS00001
This is bad.
Go to Advanced search, search for LS0001, see what happens.
Looks like the maximum LS# is 10000, as in LS10000 . I’m guessing something in the old code goes whack at that magic number.
Finally found the offensive line of code in /:/perkins/landscape/WORKING_FOLDER/LS_PROCESS3.php
Former programmer had
$query="SELECT RECID,FILENAME FROM VTLANDSCAPEDB ORDER BY FILENAME";
$result=mysql_query($query) or die("Problem Here");
While ($line= mysql_fetch_array($result)){
$LFN=$line[FILENAME];
};
$NFN=substr($LFN,3,10)+1;
Well, first off, selecting 10,000 (or even 1000) records and looping through them all just to find the last used FILENAME is wicked inefficient — both for the PHP code and the mySQL server.
Then, once a filename name was found, say
LS10000_000.jpg
or
LS09000_001.jpg
substr($LFN,3,10) should then yield
0000_000.jp or even 9000_001.jp . How adding 1 to that ever worked, I dunno
New code:
$query="SELECT RECID,FILENAME FROM VTLANDSCAPEDB ORDER BY FILENAME desc limit 1";
$result=mysql_query($query) or die("Problem Here");
While ($line= mysql_fetch_array($result)){
$LFN=$line[FILENAME];
};
$NFN=substr($LFN,2,5)+1;
This fix should prevent further instances of FILENAME = LS00001_000.jpg records; however, fixing the damage done is another story.
