| Re: From city to lati and long [message #175043 is a reply to message #175039] |
Fri, 05 August 2011 10:20   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 8/5/2011 12:49 AM, Denis McMahon wrote:
> On Thu, 04 Aug 2011 19:58:51 -0400, Jerry Stuckle wrote:
>
> You don't read anything do you.
>
> I'm not suggesting it's a php problem. I'm not suggesting she
> troubleshoot it as a php problem.
>
> I am suggesting that:
>
> a) There may be better ways in php to do what she is doing in php; and
> b) there may be things she can do in php that will help her identify and
> resolve the problem; and
> c) some of a might even also help with b.
>
> As she doesn't have access to the server, and as it's reasonable to
> assume that the server either works for everyone or is broken for
> everyone, there's a good chance that the problem is either:
>
> a) she isn't sending the right request to the server; or
> b) she isn't getting what she expects from the server.
>
> Now both of these are probably issues between her code and the server
> specs for what it expects / responds with.
>
> The first place she should look, obviously, is the specs for the server,
> what it expects, and what it replies with. Yes, I don't dispute that at
> all.
>
> However, it might also help if, for example, she dumps a failed request,
> looks at the response data and discovers an error message or error code
> in it that relates to the server documentation.
>
> She can then determine what she might be doing in forming the request
> that she sends which causes that error. However, to do this, first of all
> she needs to find the error code, which is why I still maintain that,
> when she gets a failed request, she should try and preserve the original
> request url and the response text and study them to try and see what's
> happening.
>
> Obviously this doesn't match your response to fault finding complex
> systems. Well I'm very sorry, but 20+ years of troubleshooting
> interconnected systems have taught me that if you have any sort of
> communication problem between two such systems, capturing and
> understanding the data that is being transferred in both directions is a
> very important part of understanding and fixing the problem, whether
> you're talking about telephone billing data being transferred from an
> exchange in germany to a billing processor in the uk, signals between
> processors inside a telephone exchange, data being transferred from a
> software module written in fortran to a software module written in pascal
> through interfaces written in ada, or the launch commands that a plane
> sends to a heat seeking missile.
>
> Rgds
>
> Denis McMahon
Oh, I read everything you wrote. And rather than troubleshooting the
problem, you want to just blindly hack some code until it works.
20 years of troubleshooting interconnected systems - if you really had
that (probably more like 20 minutes), then you didn't learn much.
But then you've repeatedly shown here that you have no idea how to find
a problem - you just hack away until you find something that works.
Good programmers find the problem and fix it. They don't just keep
trying things until they find something that works - like you have been
suggesting.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]