PHP/MySQL warnings about results

[bruno_guedesav]

I've made a function to fetch all results as an array of result-
arrays. Getting the result arrays is easy, via mysql_fetch_arr ay, and
function itself is quite simple, as follows:

function db_query($db, $query)
{
$result = mysql_query($qu ery, $db);
$res_array = array();

if ($result) //it is a search
{
while($data = mysql_fetch_arr ay($result,MYSQ L_ASSOC))
array_push($res _array,$data);
}

return $res_array;
}

But there's a slight problem: when the query in question is an INSERT,
UPDATE or DELETE query, PHP will show me a warning saying:

Warning: mysql_fetch_arr ay(): supplied argument is not a valid MySQL
result resource in /home/grad/ccomp/06/guedesav/public_html/PbBlog/inc/
db.php on line 28
(line 28 is "while($dat a = mysql_fetch_arr ay($result,MYSQ L_ASSOC))")

and havingthis warning on the HTML output leads to be impossible to
use header() to, for instance, go back to the post removal page. Is
there any way to know prior to fetching if my result is of and INSERT/
UPDATE/DELETE instead of a SELECT query?

[Jerry Stuckle]

Knut Krueger wrote:

Michael Fesser schrieb:

>.oO(Knut Krueger)

>>withour talking abut the SQL problem - see the other guys it should
be possible to prvent the error message with
$data = @mysql_fetch_ar ray($result,MYS QL_ASSOC))

I do not know whether it is working with
mysql_fetch_a rray($result,MY SQL_ASSOC))
but it is working with @mysql_query and @mysql_num_rows

Using '@' is really bad style in most cases. It suppresses the error
message instead of fixing it.

Micha

but it is better to supress one error instead of setting error_reporting
off, isn`t it?
Regards Knut

It's better to not cause the error in the first place.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Knut Krueger]

Jerry Stuckle schrieb:

Knut Krueger wrote:

>Michael Fesser schrieb:

>>.oO(Knut Krueger)

withour talking abut the SQL problem - see the other guys it should
be possible to prvent the error message with
$data = @mysql_fetch_ar ray($result,MYS QL_ASSOC))

I do not know whether it is working with
mysql_fetch_ array($result,M YSQL_ASSOC))
but it is working with @mysql_query and @mysql_num_rows

Using '@' is really bad style in most cases. It suppresses the error
message instead of fixing it.

Micha

but it is better to supress one error instead of setting
error_reportin g off, isn`t it?
Regards Knut

It's better to not cause the error in the first place.

Just one question to the sql problem.
where is technical the difference (count of SQL branches cpu cycles
etc.) to look for an entry suppress the error if, it is not there and
branch to the "error routine" instead using an other PHP-SQL call to
look for the record without error, and branch to the same "error
routine"? Both ways seems to be equal in the result.

Regards Knut

>

[Jerry Stuckle]

Knut Krueger wrote:

Jerry Stuckle schrieb:

>Knut Krueger wrote:

>>Michael Fesser schrieb:
.oO(Knut Krueger)

withour talking abut the SQL problem - see the other guys it should
be possible to prvent the error message with
>
>
$data = @mysql_fetch_ar ray($result,MYS QL_ASSOC))
>
I do not know whether it is working with
mysql_fetch _array($result, MYSQL_ASSOC))
but it is working with @mysql_query and @mysql_num_rows

Using '@' is really bad style in most cases. It suppresses the error
message instead of fixing it.

Micha
but it is better to supress one error instead of setting
error_reporti ng off, isn`t it?
Regards Knut

It's better to not cause the error in the first place.

Just one question to the sql problem.
where is technical the difference (count of SQL branches cpu cycles
etc.) to look for an entry suppress the error if, it is not there and
branch to the "error routine" instead using an other PHP-SQL call to
look for the record without error, and branch to the same "error
routine"? Both ways seems to be equal in the result.

Regards Knut

>>

CPU cycles have nothing to do with it. This is all about good
programming techniques.

It is much better to not make the call you know is going to cause an
error in the first place. The way you're doing it is just sloppy
programming. Such techniques are problems just waiting to happen.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Knut Krueger]

CPU cycles have nothing to do with it. This is all about good

programming techniques.

sure are CPU cycles and therefore SQL queries a question especially at
an internetserver.

It is much better to not make the call you know is going to cause an
error in the first place. The way you're doing it is just sloppy
programming. Such techniques are problems just waiting to happen.

If the record is more than 50% available, then there are less sql
queries with the suppress error method otherwise with the other method
is better.
I started programming with assembler and 8068 processors and in this
time everybody must take care about CPU and memory usage.

And if the CPU usage (means CPU instructions) was less with suppress
error it was a must to use this. That's why it is possible to suppress
errors.
In both cases the error handling was important but it was in different ways.
and using the @ including an error handling should not a bad programming
style if the usage of the server is more less.

Therefore I my mind there is still the question which way is with less
cpu usage. That's not the question for one user, but for 1000 users
simultaneously

Regards Knut

>

[Jerry Stuckle]

Knut Krueger wrote:

>CPU cycles have nothing to do with it. This is all about good
programming techniques.

sure are CPU cycles and therefore SQL queries a question especially at
an internetserver.

Nope, the reason for doing it correctly has nothing to do with CPU cycles.

>It is much better to not make the call you know is going to cause an
error in the first place. The way you're doing it is just sloppy
programming. Such techniques are problems just waiting to happen.

If the record is more than 50% available, then there are less sql
queries with the suppress error method otherwise with the other method
is better.

No it is not. It is stupid and sloppy. And anyone on one of my
projects who insisted on writing such crappy code would be looking for
another job.

You've been told the correct way to do it - have two functions, one for
SELECT statements and one for others.

I started programming with assembler and 8068 processors and in this
time everybody must take care about CPU and memory usage.

Damn youngster. I was programming a good 15 years before that. Try a
mainframe with 4,000 bytes (not 4K) of core memory and clock rates in
the 100's of kHz range. That describes the first system I was on.

But those days are long gone.

And if the CPU usage (means CPU instructions) was less with suppress
error it was a must to use this. That's why it is possible to suppress
errors.

Do you see a performance problem? I don't think so. But your way takes
up more time than necessary.

In both cases the error handling was important but it was in different
ways.
and using the @ including an error handling should not a bad programming
style if the usage of the server is more less.

No, error handling is not the important thing here. Writing good code
is. Which means not doing what causes the error in the first place.

Therefore I my mind there is still the question which way is with less
cpu usage. That's not the question for one user, but for 1000 users
simultaneously

Regards Knut

>>

Doing it the right way and not causing the error in the first place.
Anything else is just plain sloppy or lazy.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Michael Fesser]

..oO(Knut Krueger)

>CPU cycles have nothing to do with it. This is all about good
programming techniques.

sure are CPU cycles and therefore SQL queries a question especially at
an internetserver.

An if-branch or a function call really mean nothing to the CPU. But as
said elsewhere in this thread, it would be better to use two separate
functions, one for SELECT, another for INSERT/UPDATE/DELETE. This avoids
the problem right from the beginning. Couldn't be more efficient.

>It is much better to not make the call you know is going to cause an
error in the first place. The way you're doing it is just sloppy
programming. Such techniques are problems just waiting to happen.

If the record is more than 50% available, then there are less sql
queries with the suppress error method otherwise with the other method
is better.

Huh? The DB queries are the same. The difference is how the results (or
better the non-results) are handled.

>I started programming with assembler and 8068 processors and in this
time everybody must take care about CPU and memory usage.

PHP is not assembler, it's a much more abstract language. Optimization
in PHP starts on the algorithms, not on single CPU instructions or
language constructs. Google "premature optimization" if you want.

>In both cases the error handling was important but it was in different ways.
and using the @ including an error handling should not a bad programming
style if the usage of the server is more less.

Therefore I my mind there is still the question which way is with less
cpu usage. That's not the question for one user, but for 1000 users
simultaneous ly

If you run into performance problems, use a profiler to find the real
bottlenecks. It will definitely not be the error handling.

Micha

[Knut Krueger]

Jerry Stuckle schrieb:

>
Damn youngster. I was programming a good 15 years before that. Try a
mainframe with 4,000 bytes (not 4K) of core memory and clock rates in
the 100's of kHz range. That describes the first system I was on.

But those days are long gone.

>And if the CPU usage (means CPU instructions) was less with suppress
error it was a must to use this. That's why it is possible to suppress
errors.

Hi Grandpa ;-)
maybe you did some programming of VGA interfaces with more than on 64 Kb
segment in the past. It was a common and good style do disable the
integer overflow error during direct writing into the memory. (means for
1 line of code)

Why? The program needs *after* writing in the memory, therefore after
the integer overflow the branch to switch the memory page.
Preventing the error before would cause double and useless if -else
branches and would slow down the system.

That's my biggest part of knowledge and I am still programming those old
machines, because they are still in use and partially non exchangeable.

Back to SQL (and that's not my filed of expertise): I have one sql query
where normally (means nearly 100%) is an result after the sql query. I
have to branch depending on the results.

Why should I branch to the same code with an additional SQL query before
instead of suppressing the error and using one big switch case selection
and one of them is the error branch. In both cases there is an used and
working error procedure.

It is the individual responsibility to use the @ in very minor cases and
thinking about the consequences, but back to the OP in this case I
would agree to determinate whether there is better to determinate before
whether it is INSERT, UPDATE or DELETE. This would use the right
resources for that branch

Do you see a performance problem?

I was told form owner of an internet server farm that there are
performance problems on shared internet server, and on standalone with
hundreds of parallel accesses, especially in the MySQL part.
In his mind they could be minimized with better coding, means using the
queries in the very important branch, without losing of security.

Regards Knut

[Jerry Stuckle]

Knut Krueger wrote:

Jerry Stuckle schrieb:

>>
Damn youngster. I was programming a good 15 years before that. Try a
mainframe with 4,000 bytes (not 4K) of core memory and clock rates in
the 100's of kHz range. That describes the first system I was on.

But those days are long gone.

>>And if the CPU usage (means CPU instructions) was less with suppress
error it was a must to use this. That's why it is possible to
suppress errors.

Hi Grandpa ;-)
maybe you did some programming of VGA interfaces with more than on 64 Kb
segment in the past. It was a common and good style do disable the
integer overflow error during direct writing into the memory. (means for
1 line of code)

Why? The program needs *after* writing in the memory, therefore after
the integer overflow the branch to switch the memory page.
Preventing the error before would cause double and useless if -else
branches and would slow down the system.

That's my biggest part of knowledge and I am still programming those old
machines, because they are still in use and partially non exchangeable.

Back to SQL (and that's not my filed of expertise): I have one sql query
where normally (means nearly 100%) is an result after the sql query. I
have to branch depending on the results.

Why should I branch to the same code with an additional SQL query before
instead of suppressing the error and using one big switch case selection
and one of them is the error branch. In both cases there is an used and
working error procedure.

As others here have tried to tell you - you should have two functions.
One you use for SELECT statements, where you need the results returned.
The other for queries other than SELECT. The program calls the
appropriate function.

It is the individual responsibility to use the @ in very minor cases and
thinking about the consequences, but back to the OP in this case I
would agree to determinate whether there is better to determinate before
whether it is INSERT, UPDATE or DELETE. This would use the right
resources for that branch

This has nothing to do with using @ to block the error. It has
EVERYTHING to do with not creating the error in the first place.

Everyone here has told you the same thing. But you're being stubborn
and insisting on writing crappy code anyway.

Do you see a performance problem?

I was told form owner of an internet server farm that there are
performance problems on shared internet server, and on standalone with
hundreds of parallel accesses, especially in the MySQL part.
In his mind they could be minimized with better coding, means using the
queries in the very important branch, without losing of security.

Regards Knut

So? Why are you intentionally writing crappy code and knowingly causing
errors?

And you're just shooting in the dark as to what the problem is. Find
the real problem and fix it. It is most probably not in the processing
of the mysql_query() calls. Much more likely it's bad database design
and/or tuning.

And are you sure you always need all the results? What happens if a
query returns 10K rows? Retrieving all the rows and putting them in an
array itself takes time. Unless you have a need to cache the results
locally, you're causing delays in your code.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Knut Krueger]

Jerry Stuckle schrieb:

>Why should I branch to the same code with an additional SQL query
before instead of suppressing the error and using one big switch case
selection and one of them is the error branch. In both cases there is
an used and working error procedure.

As others here have tried to tell you - you should have two functions.
One you use for SELECT statements, where you need the results returned.
The other for queries other than SELECT. The program calls the
appropriate function.

Jerry, you snipped the wrong part:

but back to the OP in this case I would agree to determinate whether there is better to determinate before whether it is INSERT, UPDATE or DELETE. This would use the right resources for that branch

you see full acknowledge

I answered to Michael:

>Using '@' is really bad style in most cases. It suppresses the error
message instead of fixing it.

but it is better to supress one error instead of setting error_reporting off, isn`t it?

Normally I set error_reporting (E_ALL);
so I would like to see all errors
and you answered:

>
It's better to not cause the error in the first place.

And after that the tread goes the wrong way
I am using the @ f.e in one way.
There are tables which are proved after the registration process
f.e are there values in a couple of fields, is the additional table
inserted and filled etc.
So I tried to fix any error "in the first place"
If the table with id XY is not present it is an really unrealistic error
caused by manual deleting the table with phpmyadmin.

But this error is included in the proof function from those selected
data before updating the data.

So could you give me an good explanation why I should test whether the
table is existent and update the data after a positive answer, except
that I realize the error two lines earlier one times in 10 years?

and at least I did not say anything else than Michael

Knut

[Jerry Stuckle]

Knut Krueger wrote:

Jerry Stuckle schrieb:

>>Why should I branch to the same code with an additional SQL query
before instead of suppressing the error and using one big switch case
selection and one of them is the error branch. In both cases there is
an used and working error procedure.

As others here have tried to tell you - you should have two functions.
One you use for SELECT statements, where you need the results
returned. The other for queries other than SELECT. The program calls
the appropriate function.

Jerry, you snipped the wrong part:

>but back to the OP in this case I would agree to determinate whether
there is better to determinate before whether it is INSERT, UPDATE or
DELETE. This would use the right resources for that branch

you see full acknowledge

I answered to Michael:

>>Using '@' is really bad style in most cases. It suppresses the error
message instead of fixing it.

but it is better to supress one error instead of setting
error_reportin g off, isn`t it?

Normally I set error_reporting (E_ALL);
so I would like to see all errors
and you answered:

>>
It's better to not cause the error in the first place.

And after that the tread goes the wrong way

In general, it's also a bad idea to have error_display enabled in a
production system. It can show other things about your system when
there are problems - things you don't necessarily want known (i.e.
contents of SQL statements). But it's necessary for development.

>
I am using the @ f.e in one way.
There are tables which are proved after the registration process
f.e are there values in a couple of fields, is the additional table
inserted and filled etc.
So I tried to fix any error "in the first place"
If the table with id XY is not present it is an really unrealistic error
caused by manual deleting the table with phpmyadmin.

People shouldn't be deleting needed tables in a system. Or, if it's an
optional table, see if it exists before accessing it (SHOW TABLES).

But this error is included in the proof function from those selected
data before updating the data.

??? I don't understand this part.

So could you give me an good explanation why I should test whether the
table is existent and update the data after a positive answer, except
that I realize the error two lines earlier one times in 10 years?

But this has nothing to do with the original question. And if something
occurs 1 time in 10 years due to operator error, I wouldn't consider it
a problem.

and at least I did not say anything else than Michael

Knut

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===