Click to See Complete Forum and Search --> : Unexpected number appears on webpage
kid A
09-01-2003, 09:56 PM
This is probably one of the sillier things to ask for help on, but I just could not find the answer by searching the net..
There are two almost identical scripts, the only thing that separates them is the sql query and the variable names. They get run on the same page, one beneath the other...
What they do is grab a bunch of data from the database, store them in an array, then after shuffling the rows in the array it outputs one random row. Now this works perfectly on both scripts, but out of nowhere this number (1) appears at the end of one of the scripts...
Why?
http://www.panorama.xio.no/grafikk/backend/number.gif
It usually helps to type out the problem, because it gives a new perspective, so I might figure it out right after posting this, but right now I'm at a loss :o
Yes, I have checked all the regular newb problems that I know of...
kid A
09-01-2003, 10:08 PM
Seems related to the query since that is the only thing that differs from one script to the other, but I can't see anything wrong here:
$query_les = "select did, artist, tittel, bilde from data
where kat='1' and status='1'
and leserkarakter>='5'
order by leserkarakter desc
limit 25";
$query = "select did, artist, tittel, bilde from data
where kat='1' and status='1'
and karakter='7'";
Muk108
09-01-2003, 11:21 PM
have you figured it out? if you havnt which one is the one that has the 1 appearing or do they both? also you could check the database i know thats probly not it but i mean hey it could be.
kid A
09-02-2003, 09:21 AM
The first query above gives the number. Nowt wrong with the database I'm afraid. They read from the same one. Still haven't worked it out.
Grizzly
09-02-2003, 02:06 PM
I don't think you're going to find much help from anyone that can't take a look at the code itself. Showing the symptom of a problem in the computer world rarely gives anyone a clue as to what's causing it. For any given "bug" there are thousands of possible reasons why it could happen. The process of debugging is mostly eliminating as many reasons as possible. Without being able to see the code/process itself, it's not likely that anyone is going to be able to give you solid help here.
The only advice I can give you is that this problem smells like a problem of context. By that I mean, it's the context in which this script is called that is probably responsible for the problem you're experiencing. I'll bet money that the code "differences" aren't responsible for it, so I'd stop wasting time with that query. You should spend some time analyzing exactly what changes the script makes on it's surrounding environment. What variables are defined/set that weren't set before? What pre-existing variables have had their values changed? Print out every var/array/object/recordset possible, see how their values change.
In short - you need to watch the script "breath", see it's every move and I'm sure the source of the problem will soon become all too obvious.
Good luck with it.
kid A
09-02-2003, 02:14 PM
That's probably the way to do it, however I'm now busy repairing 538 rows in my artist database, as I've just experieced the joy of forgetting the where clause in an update statement... :( :( :( :( :( :o
Lesson to everybody: take backups of your table dato before running any new scripts on it! Or you will be pulling you hair out of your head like I am now.... *sigh*
krack_it_up
09-02-2003, 08:51 PM
What happens if you swap the order they are called on the page? Does the 1 stick with the same db call or does it stay at the bottom?
Oh, and DBAs favorite call...
BEGIN TRANSACTION...
kid A
09-02-2003, 10:23 PM
It stays with the same call..
I'm gonna have to look around the included scripts to see if there is a similar variable there somewhere.
BEGIN TRANSACTION? Didn't get that :confused:
Grizzly
09-02-2003, 10:30 PM
He's talking about database transactions - which enable you to "rollback" changes you've made if/when an error is encountered. As of MySQL v4.0, InnoDB table types should support transactions. Could be smoething for you to look into.
The better solution of course, would be not to run new, untested scripts on a production database. There's a darn good reason why people set up development environments :p
kid A
09-02-2003, 10:43 PM
Of course, but you know how it is when launching a site about 2 weeks prematurely and things have to be done by yesterday. All those good routines are great, but I suspect you need to learn the hard way why they are useful :p
I came across InnoDB when searching for a solution earlier. Problem is I'm on someone else's server. My budget is not yet prepared for my own server. I'd rather have the best backbone and limited customising options instead of my own buggy server on crap lines... for now.
Muk108
09-02-2003, 11:33 PM
Originally posted by kid A
It stays with the same call..
I'm gonna have to look around the included scripts to see if there is a similar variable there somewhere.
BEGIN TRANSACTION? Didn't get that :confused:
if it stays in the same cell wouldnt that tell you it has something to do with what is in the cell? :cool: i mean unless that database call is the only thing, i think your over looking something very basic.
kid A
09-02-2003, 11:40 PM
Nevermind, I found the bug.
An echo statement before an include.....
kid A
09-02-2003, 11:43 PM
And once again he does it... this time must be the stupidest bloody error ever made...
Embarrassing! :o
Muk108
09-02-2003, 11:58 PM
we all make those mistaces. you seem to be working hard and thinking to hard about it, nice work with fixing it though.
krack_it_up
09-04-2003, 06:59 PM
Mistakes are what make you a better developer... now the hard part is never making that same mistake again.
Oh, and transactions are very handy things. If you run a
begin transaction
statement before you do any updates, inserts or delets, it waits till you commit the transaction before it actually writes it to the DB... so at the end, if there is a mistake you can use the command..
Rollback Transaction
which automatically undoes anything you did since the begin transaction, or use
Commit transaction
which wil make everything be written to the db.
Like Grizz said though, MySQL doesnt support it yet, or maybe in the very latest version it does. Most database management systems, however, do use transactions.
kid A
09-05-2003, 07:27 AM
I'm fairly certain that I won't forget the where clause in any of my next update statements!
But what you say is true, it's working and making mistakes that really makes you a better programmer. It's incredible how much I've learnt the last few months from working on more demanding projects.
Great fun when you realise your own progress too :D