PHP/MySQL warnings about results

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

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

if ($result) //it is a search
{
while($data = mysql_fetch_array($result,MYSQL_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_array(): 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($data = mysql_fetch_array($result,MYSQL_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?

Re: PHP/MySQL warnings about results

On Nov 21, 5:43 pm, bruno_guedesav
wrote:
> I've made a function to fetch all results as an array of result-
> arrays. Getting the result arrays is easy, via mysql_fetch_array, and
> function itself is quite simple, as follows:
>
> function db_query($db, $query)
> {
> $result = mysql_query($query, $db);
> $res_array = array();
>
> if ($result) //it is a search
> {
> while($data = mysql_fetch_array($result,MYSQL_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_array(): 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($data = mysql_fetch_array($result,MYSQL_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?

Hello, Bruno.

I don't think it is a good idea to include a fetch_array into a
db_query() type
of function, first of all. If you really want to do that, however,
then make a
db_select_query() function that will do that, and do the rest with a
db_query function.

If you really want to stick with the idea, or if you have already done
a lot of code
with this function, then try this - mysql_fetch_array() will return
FALSE if no rows
are available in the result. Put an 'at' sign in front of the name of
the function (like
@mysql_fetch_array(...)). This will prevent it from echoing any
warnings, and the function
should still return FALSE if 1. no rows are available in the result 2.
(probably) if the
resource argument isn't compatible with the fetch function.

I don't find it a good idea, though. For instance, I do it like this
(for different
db compatibility): I have a function db_query, which executes a query,
and have a function
db_fetch() which fetches a row from a result returned by db_query. Of
course, I don't use
exact function names db_fetch and db_query, but you got the point. So,
I don't use db_fetch
unless I know exactly that I gave a SELECT statement to db_query.

Generally, when writing functions, try to stick with their exact
purposes - if it's executing
a statement, then it should do only that. If it's fetching a result,
it should do only that. When
including one into another, sooner or later you'll have to write
another function that doesn't
include others and the code will get messy. A -function- should have
its -function- not -functions-.
This way the code is cleaner and more easily understood.

Cheers,
Darko

Re: PHP/MySQL warnings about results

Post removed (X-No-Archive: yes)

Re: PHP/MySQL warnings about results

"bruno_guedesav" wrote in message
news:e3845f5f-57a0-4e47-b43d-403060cec833@i37g2000hsd.google groups.com...
> I've made a function to fetch all results as an array of result-
> arrays. Getting the result arrays is easy, via mysql_fetch_array, and
> function itself is quite simple, as follows:
>
> function db_query($db, $query)
> {
> $result = mysql_query($query, $db);
> $res_array = array();
>
> if ($result) //it is a search
> {
> while($data = mysql_fetch_array($result,MYSQL_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_array(): 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($data = mysql_fetch_array($result,MYSQL_ASSOC))")

When I've had this problem, I've implemented error-trapping - which I
probably should have done to start with.
The way I do it is to code something that says "if result is not an array,
don't try to perform array functions on it".
Or in your case "if connection is false, don't try to query it".






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

Re: PHP/MySQL warnings about results

In our last episode,
,
the lovely and talented bruno_guedesav
broadcast on comp.lang.php:

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

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

> if ($result) //it is a search
> {
> while($data = mysql_fetch_array($result,MYSQL_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:

These queries do not return a result resource. See the manual. You have to
test $result before attempt to fetch, or you have to use you function only
for queries that do return result resources. (See the manual.)

> Warning: mysql_fetch_array(): 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($data = mysql_fetch_array($result,MYSQL_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?

Yes. Sort of. You can read the manual to determine which mysql queries
return results. Of course in some cases even those that do have result
returns will have an empty result. You need to test it.

--
Lars Eighner usenet@larseighner.com
Countdown: 425 days to go.

Re: PHP/MySQL warnings about results

On Nov 21, 8:06 pm, Lars Eighner wrote:
> In our last episode,
> ,
> the lovely and talented bruno_guedesav
> broadcast on comp.lang.php:
>
>
>
> > I've made a function to fetch all results as an array of result-
> > arrays. Getting the result arrays is easy, via mysql_fetch_array, and
> > function itself is quite simple, as follows:
> > function db_query($db, $query)
> > {
> > $result = mysql_query($query, $db);
> > $res_array = array();
> > if ($result) //it is a search
> > {
> > while($data = mysql_fetch_array($result,MYSQL_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:
>
> These queries do not return a result resource. See the manual. You have to
> test $result before attempt to fetch, or you have to use you function only
> for queries that do return result resources. (See the manual.)
>
> > Warning: mysql_fetch_array(): 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($data = mysql_fetch_array($result,MYSQL_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?
>
> Yes. Sort of. You can read the manual to determine which mysql queries
> return results. Of course in some cases even those that do have result
> returns will have an empty result. You need to test it.
>

I've tried it, I read the manual, but anyway it will go into the loop,
so it's just useles...

I guess I'll try the "@" to supress error messages(that's what I was
looking for, by the way); if it doesn't go well, there's always time
to spli the function in two.

Anyways, thank you all for the help!

Re: PHP/MySQL warnings about results

bruno_guedesav wrote:
> On Nov 21, 8:06 pm, Lars Eighner wrote:
>> In our last episode,
>> ,
>> the lovely and talented bruno_guedesav
>> broadcast on comp.lang.php:
>>
>>
>>
>>> I've made a function to fetch all results as an array of result-
>>> arrays. Getting the result arrays is easy, via mysql_fetch_array, and
>>> function itself is quite simple, as follows:
>>> function db_query($db, $query)
>>> {
>>> $result = mysql_query($query, $db);
>>> $res_array = array();
>>> if ($result) //it is a search
>>> {
>>> while($data = mysql_fetch_array($result,MYSQL_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:
>> These queries do not return a result resource. See the manual. You have to
>> test $result before attempt to fetch, or you have to use you function only
>> for queries that do return result resources. (See the manual.)
>>
>>> Warning: mysql_fetch_array(): 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($data = mysql_fetch_array($result,MYSQL_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?
>> Yes. Sort of. You can read the manual to determine which mysql queries
>> return results. Of course in some cases even those that do have result
>> returns will have an empty result. You need to test it.
>>
>
> I've tried it, I read the manual, but anyway it will go into the loop,
> so it's just useles...
>
> I guess I'll try the "@" to supress error messages(that's what I was
> looking for, by the way); if it doesn't go well, there's always time
> to spli the function in two.
>
> Anyways, thank you all for the help!

You need to split this function... for UPDATE, DELETE, etc.
mysql_query returns TRUE on success and FALSE on error. You get your
loop because your query was performed successfully. Re-read the page at:
http://us.php.net/manual/en/function.mysql-query.php
under 'RETURNED VALUES'

Norm

Re: PHP/MySQL warnings about results

> Warning: mysql_fetch_array(): 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($data = mysql_fetch_array($result,MYSQL_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?

withour talking abut the SQL problem - see the other guys it should be
possible to prvent the error message with


$data = @mysql_fetch_array($result,MYSQL_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

Regards Knut

Re: PHP/MySQL warnings about results

On 22 nov, 14:57, Knut Krueger wrote:
> > Warning: mysql_fetch_array(): 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($data = mysql_fetch_array($result,MYSQL_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?
>
> withour talking abut the SQL problem - see the other guys it should be
> possible to prvent the error message with
>
> $data = @mysql_fetch_array($result,MYSQL_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

Oh, yes, it worked, indeed. There's no problem for me to have a single
entrance on the loop because of the first obligatory fetch as long as
it goes away cleanly so I can use headers afterwards, so this thread
is ended for me.

Re: PHP/MySQL warnings about results

..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_array($result,MYSQL_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

Re: PHP/MySQL warnings about results

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_array($result,MYSQL_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_reporting
off, isn`t it?
Regards Knut

Re: PHP/MySQL warnings about results

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_array($result,MYSQL_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_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.
jstucklex@attglobal.net
==================

Re: PHP/MySQL warnings about results

bruno_guedesav wrote:
> On 22 nov, 14:57, Knut Krueger wrote:
>>> Warning: mysql_fetch_array(): 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($data = mysql_fetch_array($result,MYSQL_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?

Yes, you are the programmer, you should know what function you are
calling and what you expect back. Split this into two functions. One
that performs INSERTS, UPDATES, DELETES, and returns affected rows and
one that performs SELECTS and returns arrays of data. You'll be on the
road to better programming practices.

>> withour talking abut the SQL problem - see the other guys it should be
>> possible to prvent the error message with
>>
>> $data = @mysql_fetch_array($result,MYSQL_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
>
> Oh, yes, it worked, indeed. There's no problem for me to have a single
> entrance on the loop because of the first obligatory fetch as long as
> it goes away cleanly so I can use headers afterwards, so this thread
> is ended for me.

This is not the answer to your problem. There is no result set to
return on an INSERT, UPDATE, etc. But if a query of that type is
completed successfully the mysql_query will return TRUE allowing your
code to enter the loop -if ($result)- is checking for a TRUE condition.
Once in the loop mysql_fetch_array finds that $result is not a result
set resource and throws an error. You are compounding the problem also
by not checking for errors on INSERT, UPDATE, etc.

Do yourself a favor and re-read the link in my previous reply. There
are multitudes of info on www.php.net.

Norm

Re: PHP/MySQL warnings about results

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_array($result,MYSQL_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_reporting 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

>

Re: PHP/MySQL warnings about results

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_array($result,MYSQL_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_reporting 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.
jstucklex@attglobal.net
==================

Re: PHP/MySQL warnings about results

> 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

>

Re: PHP/MySQL warnings about results

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.
jstucklex@attglobal.net
==================

Re: PHP/MySQL warnings about results

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

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

Micha

Re: PHP/MySQL warnings about results

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

Re: PHP/MySQL warnings about results

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.
jstucklex@attglobal.net
==================

Re: PHP/MySQL warnings about results

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

Re: PHP/MySQL warnings about results

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

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.
jstucklex@attglobal.net
==================

Re: PHP/MySQL warnings about results

Jerry Stuckle schrieb:
> 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.
yes it depends in my files on then content of $testmode TRUE/FALSE in a
config file and will be submitted with session variable or post forms
otherwise I am using the PHP default (think it is set to #40)


>> But this error is included in the proof function from those selected
>> data before updating the data.
>>
>
> ??? I don't understand this part.
>

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

select -> update


Knut

Re: PHP/MySQL warnings about results

Knut Krueger wrote:
> Jerry Stuckle schrieb:
>> 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.
> yes it depends in my files on then content of $testmode TRUE/FALSE in a
> config file and will be submitted with session variable or post forms
> otherwise I am using the PHP default (think it is set to #40)
>
>
>>> But this error is included in the proof function from those selected
>>> data before updating the data.
>>>
>>
>> ??? I don't understand this part.
>>
>
> But this error *handling* is included in the proof function from those
> selected data before updating the data.
>
> select -> update
>
>
> Knut
>

But if the error occurs once every 10 years because a user incorrectly
deleted a required table with PhPMyAdmin, that's their problem. I'd let
the message go ahead and be displayed.

I don't try to protect against user stupidity like that.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================