Unexpected number appears on webpage

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...

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:

PHP Code:

---

$query_les = "select did, artist, tittel, bilde from data 
             where kat='1' and status='1' 
            and leserkarakter>='5' 
            order by leserkarakter desc 
            limit 25"; 


---

PHP Code:

---

$query = "select did, artist, tittel, bilde from data 
            where kat='1' and status='1' 
            and karakter='7'"; 


---

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.

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.

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.

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*

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...

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:

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

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.

Quote:

---

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.

Nevermind, I found the bug.

An echo statement before an include.....

And once again he does it... this time must be the stupidest bloody error ever made...

Embarrassing! :o

we all make those mistaces. you seem to be working hard and thinking to hard about it, nice work with fixing it though.

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.