Michael Stassen wrote:
Amer Neely wrote:
<snip>
OK, obviously a bit more background seems to be in order.
My site is hosted but I am not the administrator. I have 2 perl scripts, behaving as already described. I also have phpMyAdmin access to my databases. I don't have command line access to the server.
Well, that's a start. Do you run the perl scripts from the command line or via a web interface? If the latter, is your script running through mod_perl with persistent connections?
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.
I don't use InnoDB or transactions.
OK.
What is happening is that I delete a record with one script, but it still shows up when the db is queried by the other script. It DOESN'T show up in the one I used to delete the record.
Right, I got that. But you still haven't showed us the relevant parts of the scripts. How are we to help diagnose the problem without seeing the connect line and the query for each script?
Here are the relevant snippets. Three tables have to 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");
phpMyAdmin shows me that the record still exists in the db. My scripts are not the problem.
What does this mean? A phpMyAdmin query against the db retrieves the entire, supposedly-deleted row? You can see the id of the row as a link to the row? You can see that the row count is still 103?
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.
When I tried to execute a FLUSH TABLES command with phpMyAdmin, that's when I get the error about not having RELOAD privilege. Sounds pretty clear to me.
Right. It is clear that you need the RELOAD privilege to FLUSH TABLES. But that's a red herring. You do not need FLUSH TABLES to delete a row. In fact, FLUSH TABLES has nothing to do with deleting rows. FLUSH TABLES closes all tables and wipes out the cache.
OK, I see what your saying now.
So tell me, is this a 'properly functioning mysql server'?
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.
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.
-- /* 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]
