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