473,320 Members | 2,088 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

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?
Nov 21 '07 #1
21 3668
On Nov 21, 5:43 pm, bruno_guedesav <bruno_guede...@yahoo.com.br>
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
Nov 21 '07 #2
"bruno_guedesav" <br************@yahoo.com.brwrote in message
news:e3**********************************@i37g2000 hsd.googlegroups.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?

Nov 21 '07 #3
In our last episode,
<e3**********************************@i37g2000hsd. googlegroups.com>,
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 <http://larseighner.com/us****@larseighner.com
Countdown: 425 days to go.
Nov 21 '07 #4
On Nov 21, 8:06 pm, Lars Eighner <use...@larseighner.comwrote:
In our last episode,
<e3845f5f-57a0-4e47-b43d-403060cec...@i37g2000hsd.googlegroups.com>,
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!
Nov 22 '07 #5
bruno_guedesav wrote:
On Nov 21, 8:06 pm, Lars Eighner <use...@larseighner.comwrote:
>In our last episode,
<e3845f5f-57a0-4e47-b43d-403060cec...@i37g2000hsd.googlegroups.com>,
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
Nov 22 '07 #6
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
Nov 22 '07 #7
On 22 nov, 14:57, Knut Krueger <knut.krue...@usa.comwrote:
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.
Nov 22 '07 #8
..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
Nov 23 '07 #9
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
Nov 23 '07 #10
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.
js*******@attglobal.net
==================

Nov 23 '07 #11
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
>
Nov 24 '07 #12
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.
js*******@attglobal.net
==================

Nov 24 '07 #13
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
>
Nov 25 '07 #14
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*******@attglobal.net
==================

Nov 25 '07 #15
..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
Nov 25 '07 #16
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

Nov 27 '07 #17
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*******@attglobal.net
==================

Nov 27 '07 #18
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

Nov 28 '07 #19
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.
js*******@attglobal.net
==================

Nov 28 '07 #20
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
Nov 28 '07 #21
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.
js*******@attglobal.net
==================

Nov 28 '07 #22

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Reply via newsgroup | last post by:
Folks, When performing an update in mysql (using PHP), can I find out how many records were matched? mysql_affected_rows() won't work... and I have the following problem that I thought I...
0
by: Gordon | last post by:
I have 2 tables t and t1. In this case, t1 is a copy of t. I want to delete rows from t1 based on criteria on the t table and a relationship between t ad t1 (in this case the id column). In the...
0
by: Lenz Grimmer | last post by:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, MySQL 4.0.14, a new version of the popular Open Source/Free Software Database, has been released. It is now available in source and binary...
4
by: Ka | last post by:
I install a mysql server in default installation with latin charset, but I want to use GBK(a chinese charset), so that I can store and search chinese words directly. so, I download, unpack and...
0
by: I.P. | last post by:
Hi, it's my story. I have two 4.0.14 mysql server on one machine with win XP Professional polish version. First acts as master: on port 3300 Second acts as slave: on port 3301 below my...
0
by: I.P. | last post by:
No one has replied to my post. ----- Original Message ----- From: "I.P." <jancio_wodnik@wp.pl> To: <mysql@lists.mysql.com> Sent: Monday, August 18, 2003 1:01 PM Subject: mysql 4.0.14 +...
13
by: miker2 | last post by:
HI, I'm having trouble writing to a MySql db using python and the MySQLdb module. Here is the code: import MySQLdb base = MySQLdb.connect(host="localhost", user="blah", passwd="blah",...
1
by: Ike | last post by:
Recently, I began using a different MySQL verver (i.e. different machine as well as different version#, going from 4.12a to 4.1.9 max). The following query used to work: select firstname,...
1
by: PowerLifter1450 | last post by:
I've been having a very rough time installinig mySQL on Linux. I have been following the instructions form here: http://www.hostlibrary.com/installing_apache_mysql_php_on_linux Everytime I get to...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.