Michael Stassen wrote:
Amer Neely wrote:
Both scripts, which reside in the same directory on the server, are run through the web browser. And they do access the same database, and the same tables.
So, same web server, same mysql server, same connection settings. Good.
Does phpmyadmin connect to mysql as the same user as your admin script?
Here are the relevant snippets. Three tables have to be accessed in order for a record to be deleted.
$sth=$dbh->do("DELETE FROM $TITLES WHERE ArtistID = $ThisArtistID AND TitleID = $ThisTitleID");
$sth=$dbh->do("DELETE FROM $TRACKS WHERE TitleID = $ThisTitleID AND ArtistID = $ThisArtistID");
$sth=$dbh->do("DELETE FROM $ARTISTS WHERE ArtistID = $ThisArtistID");
Your table names are in variables?
Are you checking for errors? Also, $dh->do returns a result value, not a statement handle. So, I'd suggest something like (using the last one as an example):
$query = "DELETE FROM $ARTISTS WHERE ArtistID = $ThisArtistID"; eval {$rows = $dbh->do($query) }; if ($@) { # got an error print "$query failed with error:\n"; print "[EMAIL PROTECTED]"; } else { # query succeeded print "Deleted $rows rows from table $ARTISTS\n"; }
OK, I implemented your suggested error-trapping above, and now the script seems to be working fine. A deleted record really is deleted - confirmed with phpMyAdmin. In 2 different browsers. In all 3 tables. Which of course raises the question, why didn't the records get deleted when presented the other way?
Just so you have some context: The 'public' script: http://www.softouch.on.ca/cgi-bin/cd/mycd-07a.pl
Thank you for tearing this apart and putting it back together correctly. I don't know if we'll ever know what was going on with my original code.
A query in phpMyAdmin to 'select * from Artists where artistid=124' is the query I ran.
Before I used phpMyAdmin to delete the row, it was still there, after supposedly being deleted by my script. And yet, that same script acted as though the row (and in fact complete record) was deleted. A query for that particular artist, title, or any tracks came back empty.
Have you tried deleting the row in phpmyadmin? If you can, then we can be sure it's a script problem. If you cannot, then it may be a mysql problem.
Yes, I was able to delete the row with phpMyAdmin. And it finally stopped appearing in both scripts.
This proves you can delete rows from your table (via phpmyadmin), and it proves that your admin script failed to do so, despite *apparently* working. Of course, phpmyadmin is php, while your scripts are perl. I think that leaves a problem in your script or a problem with perl.
My bet is there's something in your admin script. I reason thusly:
1) Using phpmyadmin, you've verified mysql is working correctly, and that you can delete rows.
2) The admin script fails to delete rows. (Every other method shows they are still there.)
3) The admin script claims that rows that haven't been deleted are no longer there.
Point 3 is especially troubling. Presumably, you select a row in your admin script to delete and then you submit the form. The resulting page from the script says the row is gone. Calling up the script later says the row is still gone, yes? Even if you call it from a different browser? It is as if the data is gone from the perl variables in your script, and further runs of the script don't refresh the variables (by getting them from mysql). That is, variables would have to persist from one invocation to the next. So, is it mod_perl?
<snip>
If FLUSH TABLES fixed the problem, that would mean that your mysql server was improperly caching the row in question after it was deleted. In other words, that would mean mysql was broken. But we know that is not the case. If mysql were keeping the row in the cache even though it had been deleted, it would show up in all your clients, not all but one.
I can't run FLUSH TABLES, and the row was showing up in 1 of the 2 scripts, so I don't know how to respond to that. It seems to be a paradox.
I think not. If mysql were improperly caching a deleted row, FLUSH TABLES might be a workaround, but in that case the row would still show up in ALL clients prior to running FLUSH TABLES. It doesn't, so mysql caching is not the problem.
So, as I said, without seeing the relevant parts of your scripts, it is impossible to do more than guess. I'll go ahead and take a shot. There have been about 3 threads similar to this recently in which it turned out that one script connected to the production server while the other pointed to the development server. Have you double-checked your connection strings to make sure they are identical?
Yes, as mentioned in this response, both scripts reside in the same directory, and there is only 1 database they are accessing. I checked to make sure I didn't have 2 sets of tables (upper-case, lower-case) but that isn't the case either. I made a mistake earlier about the mysql version. It is running on a Linux box, so case is important.
The connection code for each is identical, because one script is a saved-as copy of the other. Only differences being in the action of some of the form submit buttons.
OK, so that's a dead-end. Can you show us more of your code?
Michael
-- /* All outgoing email scanned by AVG Antivirus */ Amer Neely, Softouch Information Services Home of Spam Catcher & North Bay Information Technology Networking Group W: www.softouch.on.ca E: [EMAIL PROTECTED] Perl | PHP | MySQL | CGI programming for all data entry forms. "We make web sites work!"
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
