|
|
Posted by Jerry Stuckle on 11/28/07 13:55
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
==================
Navigation:
[Reply to this message]
|