Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #10837 > unrolled thread

part 2 - file exists not working

Back to article view | Back to comp.lang.php

Contents

  part 2 - file exists not working richard <noreply@example.com> - 2013-09-23 10:04 -0400
    Re: part 2 - file exists not working Tim Streater <timstreater@greenbee.net> - 2013-09-23 15:17 +0100
      Re: part 2 - file exists not working richard <noreply@example.com> - 2013-09-23 10:35 -0400
    Re: part 2 - file exists not working Paul Herber <paul@pherber.com> - 2013-09-23 15:33 +0100
    Re: part 2 - file exists not working David Robley <me@home.invalid> - 2013-09-24 10:16 +0930
      Re: part 2 - file exists not working Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-09-23 22:07 -0400
        Re: part 2 - file exists not working richard <noreply@example.com> - 2013-09-24 01:57 -0400
          Re: part 2 - file exists not working David Robley <me@home.invalid> - 2013-09-24 17:19 +0930
            Re: part 2 - file exists not working richard <noreply@example.com> - 2013-09-24 04:10 -0400
            Re: part 2 - file exists not working richard <noreply@example.com> - 2013-09-24 04:32 -0400
            Re: part 2 - file exists not working Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-09-24 23:23 +0000
              Re: part 2 - file exists not working David Robley <me@home.invalid> - 2013-09-25 09:48 +0930
          Re: part 2 - file exists not working Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-09-24 09:45 -0400
            Re: part 2 - file exists not working Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-09-24 16:34 +0200
              Re: part 2 - file exists not working Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2013-09-24 10:41 -0400
                Re: part 2 - file exists not working richard <noreply@example.com> - 2013-09-24 12:17 -0400
                  Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-24 09:29 -0700
                    Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-24 18:51 -0400
                  Re: part 2 - file exists not working Denis McMahon <denismfmcmahon@gmail.com> - 2013-09-24 19:10 +0000
                    Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-24 19:08 -0400
                      Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-24 18:39 -0700
                        Re: part 2 - file exists not working "Peter H. Coffin" <hellsop@ninehells.com> - 2013-09-24 22:17 -0500
                        Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-26 17:20 -0400
                          Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-26 15:43 -0700
                            Re: part 2 - file exists not working Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-26 19:43 -0400
                      Re: part 2 - file exists not working Scott Johnson <noonehome@chalupasworld.com> - 2013-09-24 18:54 -0700
                        Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-26 17:39 -0400
                          Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-26 15:47 -0700
                            Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-28 13:58 -0400
                              Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-28 11:45 -0700
                      Re: part 2 - file exists not working Tim Streater <timstreater@greenbee.net> - 2013-09-25 09:01 +0100
                Re: part 2 - file exists not working Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-09-24 18:54 +0200
                  Re: part 2 - file exists not working Tim Streater <timstreater@greenbee.net> - 2013-09-24 18:30 +0100
                Re: part 2 - file exists not working Scott Johnson <noonehome@chalupasworld.com> - 2013-09-24 15:40 -0700
                  Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-24 19:14 -0400
                    Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-24 18:43 -0700
                      Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-26 17:42 -0400
                Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-24 18:50 -0400
                  Re: part 2 - file exists not working Scott Johnson <noonehome@chalupasworld.com> - 2013-09-24 18:56 -0700
                  Re: part 2 - file exists not working Curtis Dyer <dyer85@gmail.com> - 2013-09-26 06:01 +0000
                    Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-26 18:04 -0400
                      Re: part 2 - file exists not working Curtis Dyer <dyer85@gmail.com> - 2013-09-27 01:47 +0000
                        Re: part 2 - file exists not working Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-26 22:56 -0400
                          Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-26 20:11 -0700
                            Re: part 2 - file exists not working Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-26 23:41 -0400
                          Re: part 2 - file exists not working Curtis Dyer <dyer85@gmail.com> - 2013-09-27 06:04 +0000
                        OT Re: part 2 - file exists not working Twayne <nobody@spamcop.net> - 2013-09-28 14:33 -0400
                          Re: OT Re: part 2 - file exists not working Fiver <numeralfive@gmail.com> - 2013-09-28 23:12 +0200
                            Re: OT Re: part 2 - file exists not working The Natural Philosopher <tnp@invalid.invalid> - 2013-09-29 06:50 +0100
                              Re: OT Re: part 2 - file exists not working "Peter H. Coffin" <hellsop@ninehells.com> - 2013-09-29 10:39 -0500
                                Re: OT Re: part 2 - file exists not working Jerry Stuckle <jstucklex@attglobal.net> - 2013-09-29 14:49 -0400
    Re: part 2 - file exists not working Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-09-24 23:20 +0000
      Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-24 18:46 -0700
      Re: part 2 - file exists not working richard <noreply@example.com> - 2013-09-24 22:27 -0400
        Re: part 2 - file exists not working The Natural Philosopher <tnp@invalid.invalid> - 2013-09-25 06:21 +0100
        Re: part 2 - file exists not working David Robley <me@home.invalid> - 2013-09-25 15:20 +0930
          Re: part 2 - file exists not working Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-09-26 20:30 +0000
      Re: part 2 - file exists not working Denis McMahon <denismfmcmahon@gmail.com> - 2013-09-25 07:42 +0000
        Re: part 2 - file exists not working The Natural Philosopher <tnp@invalid.invalid> - 2013-09-25 09:07 +0100
          Re: part 2 - file exists not working Richard Yates <richard@yatesguitar.com> - 2013-09-25 06:29 -0700
            Re: part 2 - file exists not working The Natural Philosopher <tnp@invalid.invalid> - 2013-09-25 15:09 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#10870

On Tue, 24 Sep 2013 19:08:22 -0400, Twayne <nobody@spamcop.net> wrote:

>> If you check now and discover that yes, your server does in fact also
>> support mysqli_* functions already, then you can start migrating your
>> code from mysql_* functions to mysqli_* functions now so that you won't
>> get caught out in a future upgrade it
>
>Unless it's of no benefit; you already said they may both exist and if 
>that's the case and one gains no benefit from changing, well, ... .

At some point there definitely will be a benefit - that all his pages
continue to work at all. mysql will be discontinued although no one
knows just when. If he waits too long he will be stuck and it may take
weeks for him to make the changes. 

I converted all my mysql to mysqli this year - a couple hundred pages.
It was not a trivial chore. Some changes could be automated and some
could not. Some functions are a simple search-and-replace, some are
only similar, and some are a lot different. 

[toc] | [prev] | [next] | [standalone]

#10877

On Tue, 24 Sep 2013 18:39:49 -0700, Richard Yates wrote:
> At some point there definitely will be a benefit - that all his pages
> continue to work at all. mysql will be discontinued although no one
> knows just when. If he waits too long he will be stuck and it may take
> weeks for him to make the changes. 

(This presumes his project ever gets to the state of "working" in the
first place.)

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -Justice Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#10909

On 2013-09-24 9:39 PM, Richard Yates wrote:
> On Tue, 24 Sep 2013 19:08:22 -0400, Twayne <nobody@spamcop.net> wrote:
>
>>> If you check now and discover that yes, your server does in fact also
>>> support mysqli_* functions already, then you can start migrating your
>>> code from mysql_* functions to mysqli_* functions now so that you won't
>>> get caught out in a future upgrade it
>>
>> Unless it's of no benefit; you already said they may both exist and if
>> that's the case and one gains no benefit from changing, well, ... .
>
> At some point there definitely will be a benefit - that all his pages
> continue to work at all. mysql will be discontinued although no one
> knows just when. If he waits too long he will be stuck and it may take
> weeks for him to make the changes.
>
> I converted all my mysql to mysqli this year - a couple hundred pages.
> It was not a trivial chore. Some changes could be automated and some
> could not. Some functions are a simple search-and-replace, some are
> only similar, and some are a lot different.
>

It's irrelevant what YOU did/do. You need to do a little more research 
before continuing your vagueries, really.

[toc] | [prev] | [next] | [standalone]

#10915

On Thu, 26 Sep 2013 17:20:00 -0400, Twayne <nobody@spamcop.net> wrote:

>On 2013-09-24 9:39 PM, Richard Yates wrote:
>> On Tue, 24 Sep 2013 19:08:22 -0400, Twayne <nobody@spamcop.net> wrote:
>>
>>>> If you check now and discover that yes, your server does in fact also
>>>> support mysqli_* functions already, then you can start migrating your
>>>> code from mysql_* functions to mysqli_* functions now so that you won't
>>>> get caught out in a future upgrade it
>>>
>>> Unless it's of no benefit; you already said they may both exist and if
>>> that's the case and one gains no benefit from changing, well, ... .
>>
>> At some point there definitely will be a benefit - that all his pages
>> continue to work at all. mysql will be discontinued although no one
>> knows just when. If he waits too long he will be stuck and it may take
>> weeks for him to make the changes.
>>
>> I converted all my mysql to mysqli this year - a couple hundred pages.
>> It was not a trivial chore. Some changes could be automated and some
>> could not. Some functions are a simple search-and-replace, some are
>> only similar, and some are a lot different.
>>
>It's irrelevant what YOU did/do. You need to do a little more research 
>before continuing your vagueries, really.


You really are getting way off base on this one, Twayne. I offered my
experience as it may be useful in your deciding when to convert
(because you really will have to at some point). I do not need to do
more research about how I did it because it was recent and I kept some
notes. If it was too vague to help you, please ask some specdific
questions. 

[toc] | [prev] | [next] | [standalone]

#10918

On 9/26/2013 6:43 PM, Richard Yates wrote:
> On Thu, 26 Sep 2013 17:20:00 -0400, Twayne <nobody@spamcop.net> wrote:
\
>> It's irrelevant what YOU did/do. You need to do a little more research
>> before continuing your vagueries, really.
>
>
> You really are getting way off base on this one, Twayne. I offered my
> experience as it may be useful in your deciding when to convert
> (because you really will have to at some point). I do not need to do
> more research about how I did it because it was recent and I kept some
> notes. If it was too vague to help you, please ask some specdific
> questions.
>

Don't feed the troll.

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

[toc] | [prev] | [next] | [standalone]

#10873

On 9/24/2013 4:08 PM, Twayne wrote:
> Finally, a voice of some reason instead of scare tactics even if still a
> little light in areas.
>
> On 2013-09-24 3:10 PM, Denis McMahon wrote:
>> On Tue, 24 Sep 2013 12:17:23 -0400, richard wrote:
>>
>>> I will change when my host changes.
>>> As the host is responsible for maintaining the server side, I can't do a
>>> damn thing until they do.
>
> And that's true.

Probably not in the context of using mysqli over mysql.
The host gives you both options (unless you have some budget host in 
which case the jokes on him) UNTIL they switch to the version in which 
the mysql_ is deprecated and your site breaks.

>
>>
>> Have you tested to see if mysqli is available on your host?
>
> I have, yes. I did it by contacting Support and they responded in the
> same day.
> And at least with MY host they have a "What's New" page to look for
> things like that, too. All version updates/upgrades/deletions are
> mentioned there.

I am pretty sure he was talking to Richard.


>>
>> If it is, why are you not using it? mysqli is not something that your
>> hosting server will expect to announce the roll out of, indeed it's quite
>> possible that it's been on the server for several years already.
>
> The poster already mentioned why he wasn't using it.
> Not necessarily in most cases IME at least. Although, if it's avaliable,
> it's a good move to be checking into what it takes to make the revision
> IFF it will benefit you.

The benefit would be your site does not break once the php version 
deprecates the currently used functions.

There is a solid reason that the manual says you should NOT be using it 
since it will not exist in the future.

> ...
>> It is quite possible for both these sets of interface functions to be
>> installed in the same php build. Certainly this is the case in eg PHP
>> Version 5.3.10-1ubuntu3.8 on my server.
>
> Exactly.

It exists not so you can build a new site upon it.  It does so to allow 
those who in the past had only that function and gives them reasonable 
amount of time to switch to the new one.

>
> ...
>> If you check now and discover that yes, your server does in fact also
>> support mysqli_* functions already, then you can start migrating your
>> code from mysql_* functions to mysqli_* functions now so that you won't
>> get caught out in a future upgrade it
>
> Unless it's of no benefit; you already said they may both exist and if
> that's the case and one gains no benefit from changing, well, ... .

Again we are not talking about the benefit of memory or speed or ease of 
programming, the benefit is that you site keeps working.  A pretty solid 
benefit if you ask me or you just end up having a hard drive full of 
useless files.

>>
>> Note that checking doesn't mean you look to see if the database has
>> changed from mysql to mysqli, because that's not what happens. Checking
>> means creating a page called something like sysinfo.php that contains the
>> following code:
>>
>> <?php
>> phpinfo();
>>
>> and then putting that page in your website, and then going to the url:
>>
>> http://your_website_name_here/sysinfo.php
>>
>> Then scroll down the output until you come to the mysqli section. The
>> presence of this section means that the mysqli interface modules are
>> installed in the servers php code.
>
> Good advice. But if someone is so new that phpinfo.php & 'sysinfo'  is
> news to them, well, they've a lot more than mysql to get up to date on.

This is the one statement that I agree on with a but.  We have pointed 
out the function that is going bye bye and gave links on how to use the 
new one which does not differ all too much from the former in the 
context of the OPs question.  If that is too difficult then I do think 
we (he) is going to and has had a long frustrating journey.

>>
>> Hostgator support PHP 5, so their PHP build includes mysqli_* functions.
>> The only thing stopping you using mysqli_* functions instead of mysql_*
>> functions is *YOU*!
>
> And a learning curve, and time (which is money), and ... etc. etc..
> Nothing is ever gained from advice like that.

In all professions you have to stay current with new way of doing things 
and toss the old.

You have to learn how to keep up to date with the server needs, it is 
part of the job.  And by keeping up to date, your site is less likely to 
break and cause even more money when you have a down site and still have 
to find where it broke and also to learn the new functions anyhow.

Why not do it while the site is still functioning and no one public is 
the wiser.

[toc] | [prev] | [next] | [standalone]

#10910

On 2013-09-24 9:54 PM, Scott Johnson wrote:
...

>
> There is a solid reason that the manual says you should NOT be using it
> since it will not exist in the future.

"Should" being the operative word here. Yes, it should be done but at 
one's leisure so far, not in anticipation of anything disappearing 
TOMORROW as the egomaniacs are intimating. It's a logical, meaningful 
progression of technology; what gets my goats are the egoes running 
around intimating the end of the world if you don't make the change 
yesterday; they aren't just trying to educate ... far from it.
    Too many people are put off by the "must do" attitude which contains 
no useful information; only that it's going to be the end of the world 
for everyone which is clearly not the case. Yes, in time it's 99.9% 
likely to occur as expected but ordering people to stop using something 
has absolutely no benefit to it. Nor does it ingratiate a single person.

> ...

...
>
> It exists not so you can build a new site upon it.  It does so to allow
> those who in the past had only that function and gives them reasonable
> amount of time to switch to the new one.

And a logical, reasonable bit of pro-activity from the PTB.

>
>>
>> ...

...

>>
>> Good advice. But if someone is so new that phpinfo.php & 'sysinfo'  is
>> news to them, well, they've a lot more than mysql to get up to date on.
>
> This is the one statement that I agree on with a but.  We have pointed
> out the function that is going bye bye and gave links on how to use the
> new one which does not differ all too much from the former in the
> context of the OPs question.  If that is too difficult then I do think
> we (he) is going to and has had a long frustrating journey.

I'll buy that. Out of all the posters in this thread, you're the one 
making the most sense and keeping logic and "people" in mind. That's 
something too many people miss out on these days.
>
...

> In all professions you have to stay current with new way of doing things
> and toss the old.
>
> You have to learn how to keep up to date with the server needs, it is
> part of the job.  And by keeping up to date, your site is less likely to
> break and cause even more money when you have a down site and still have
> to find where it broke and also to learn the new functions anyhow.
>
> Why not do it while the site is still functioning and no one public is
> the wiser.

Well said!

I'm not going to say much more if anything at all on this thread; my 
only intent was to bring some sanity to it and negate the armegeddoners 
wasting so much time on the way they think they can order people around. 
That sort of leadership NEVER works for long.

Cheers,

Twayne`



>
>

[toc] | [prev] | [next] | [standalone]

#10916

On Thu, 26 Sep 2013 17:39:34 -0400, Twayne <nobody@spamcop.net> wrote:

>On 2013-09-24 9:54 PM, Scott Johnson wrote:
>...
>
>>
>> There is a solid reason that the manual says you should NOT be using it
>> since it will not exist in the future.
>
>"Should" being the operative word here. Yes, it should be done but at 
>one's leisure so far, not in anticipation of anything disappearing 
>TOMORROW as the egomaniacs are intimating. It's a logical, meaningful 
>progression of technology; what gets my goats are the egoes running 
>around intimating the end of the world if you don't make the change 
>yesterday; they aren't just trying to educate ... far from it.

Chill, Twayne. No one has come anywhere near the caricature you
describe. They have simply quoted the php manual. And to think that
anyone would recommend converting out of ego just does not make any
sense at all. No one here has any investment in your web pages or any
financial interest in php. How in the world do you see ego involved?

[toc] | [prev] | [next] | [standalone]

#10925

On 2013-09-26 6:47 PM, Richard Yates wrote:
> On Thu, 26 Sep 2013 17:39:34 -0400, Twayne <nobody@spamcop.net> wrote:
>
>> On 2013-09-24 9:54 PM, Scott Johnson wrote:
>> ...
>>
>>>
>>> There is a solid reason that the manual says you should NOT be using it
>>> since it will not exist in the future.
>>
>> "Should" being the operative word here. Yes, it should be done but at
>> one's leisure so far, not in anticipation of anything disappearing
>> TOMORROW as the egomaniacs are intimating. It's a logical, meaningful
>> progression of technology; what gets my goats are the egoes running
>> around intimating the end of the world if you don't make the change
>> yesterday; they aren't just trying to educate ... far from it.
>
> Chill, Twayne. No one has come anywhere near the caricature you
> describe. They have simply quoted the php manual. And to think that
> anyone would recommend converting out of ego just does not make any
> sense at all. No one here has any investment in your web pages or any
> financial interest in php. How in the world do you see ego involved?
>
The "ego" I see is that of the person who thinks the world should follow 
them blindly. They are more interested in being "seen" as touting the 
line they've used and simpy turning a blind eye to reason; because 
"they" said it, vague and devoid of detail as the mantras they espouse, 
and no one should bring reason or timing or cost or the reality of such 
updating. It's enough they made one vague statement, according to them.
    What started out as a decent discussion of some of the issues 
quickly degenerated to single-sentence warnings and sigs about MYSQL and 
it extensions by a predictable few here.

Such is clearly not the case and these "chosen few" are doing themselves 
and anyone a great disservice by intimating it must be done not only 
now, but quickly. That comes very close to a disservice to anyone 
reading their tripe who suddenly stops development of their site and 
might let everythng go and rather than their site progressing they 
simply wast time better spent on waiting for an opportunity to get 
serious about the changes so "direly needed" when it just isn't so.
    It gets worse too when you come across things like one's server 
magically changing their PHP version when one is signed up to use a 
different version available on their server sites. Those people either 
need to go to better server sites or, more likely, face the truth about 
the whole scenario.
      My own would never do that to me: what they might do is notify me 
a new version is imminent so I can think about what I want to do, and 
what they DO do would be to notify me not only of the update, which I'd 
love to havem but also of what older versions are still going to be 
available. Even back in the "old" days when I was starting out with a 
freebie Tripod site, they did that sort of thing.
    If a server admins doesn't communicate with their clients, then 
there will at least be a page available that keeps their customers up to 
date on what's happening on their servers; sort of a what's new page.
    And if their support is worth anything, they'll briefly but 
factually discuss anything about the servers that you'd like to know and 
at least mine tells me if they don't know the answer.
    A server that only offers one version of PHP say, and changes it 
without notice or schedule, well, should be left for a better server.

Lest this turn into a troll-fest I'm probably not going to say a lot 
more about the subject unless it's a reasonably worded post, such as 
yours was.

Aside: It's been years now but I always recall the post that seemed to 
make se nse  to me, but not entirely. When I asked this mvp for his 
impression of why we should do what he was pushing, his response was 
"Because I said so and I know more than you." It always makes me laugh, 
albeit softly.

Regards,

Twayne`

[toc] | [prev] | [next] | [standalone]

#10927

On Sat, 28 Sep 2013 13:58:10 -0400, Twayne <nobody@spamcop.net> wrote:

>The "ego" I see is that of the person who thinks the world should follow 
>them blindly. 

But no one has said to do what they recommend just because they say
so. Everyone cited reasons for their recommendations. 

>Such is clearly not the case and these "chosen few" are doing themselves 
>and anyone a great disservice by intimating it must be done not only 
>now, but quickly.

No one said now or quickly. All said that it will happen some time and
gave reasons why converting sooner might be better than later. One
factor in my decision was realizing that, as I accumulated more
mysql_() code, it meant that the inevitable conversion would be bigger
chore than if I did it sooner. 

>serious about the changes so "direly needed" when it just isn't so.

No one said direly needed.

>      My own would never do that to me: what they might do is notify me 
>a new version is imminent so I can think about what I want to do,

No one said that the server admins would not give you warning. What
you do NOT know is how much warning you will get COMPARED to how long
it will take you to convert. That's why I wrote that it is a
non-trivial task. It took many steps, and I found little guidance. The
project ultimately worked out okay, but I can easily imagine having
gotten desperately stuck. If I had waited until there was an actual
deadline, that could have been a nightmare. 

>Lest this turn into a troll-fest I'm probably not going to say a lot 
>more about the subject unless it's a reasonably worded post, such as 
>yours was.

Thanks.

[toc] | [prev] | [next] | [standalone]

#10884

In article <l1t61d$562$1@speranza.aioe.org>,
 Twayne <nobody@spamcop.net> wrote:

> Finally, a voice of some reason instead of scare tactics even if still a 
> little light in areas.
> 
> On 2013-09-24 3:10 PM, Denis McMahon wrote:

> > If you check now and discover that yes, your server does in fact also
> > support mysqli_* functions already, then you can start migrating your
> > code from mysql_* functions to mysqli_* functions now so that you won't
> > get caught out in a future upgrade it
> 
> Unless it's of no benefit; you already said they may both exist and if 
> that's the case and one gains no benefit from changing, well, ... .

The benefit is that it's one more issue you can then forget about. It's 
one more thing that is not going to suddenly and without warning trip 
you up when you don't expect it. You won't then find yourself having to 
recode a load of stuff under pressure with perhaps the phone ringing off 
the hook asking WTF is going on and when will it be fixed.

Unless you enjoy such situations, of course. But I think any manager 
would look sideways at someone who allowed such a situation to develop 
when they could have easily avoided it. That someone might then find 
themselves with a shiny new P45.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#10858

Lew Pitcher wrote:

> [Thomas 'PointedEars' Lahn] wrote:
>> Lew Pitcher wrote:
>>> noreply@example.com wrote:
>>>> Output reseulted in one table row showing with no data.
>>>> 
>>>> www.mroldies.met/filetest.php
>>> 
>>> If $result is not FALSE, you loop through it using mysql_fetch_array()
>>> or one of it's child functions (mysql_fetch_row or mysql_fetch_assoc())
>>> to retrieve individual rows
>>> 
>>> Something like
>>> 
>>>   while ($row = mysql_fetch_array($result) )
>>>   {
>>>     printf("atitle: %s\n",$row['atitle']);
>>>     printf("btitle: %s\n",$row['btitle']);
>>>     /* and so on */
>>>   }
>> 
>> JFTR: The mysql extension is *deprecated* and will be *removed*:
>> 
>> <http://php.net/mysql_fetch_array>
> 
> A very valid point that we've repeatedly made to richard.
                                                   ^^^^^^^
Unfortunately, *that* explains a lot.  I have the OP killfiled for address 
munging and was not aware of that.

(This was also due to your rather uncommon practice of not including the 
name in the attribution line at all, which I would advise against.  Postings 
are written by *people*, not e-mail addresses.  An e-mail address signifies 
almost nothing; in the From header field value, it may even specify a 
mailbox that is heavy spam-filtered and seldom read, not suitable for 
contacting the author.  And please skip the attribution novel while you are 
at it; it does not make sense, and it makes discussions a lot harder to 
read, to duplicate non-essential header information there. 

<http://www.netmeister.org/news/learn2quote.html/>)

> And that he has considered and rejected.

Still, IMHO all examples should be written according to what one considers 
best common practice.  At least they can serve as a recommendation to 
others.  Bad examples to fix original code are almost as bad as bad original 
code.  A Usenet posting is written once, but then is distributed, and 
archived; thus it is still found much later, and read many times in total, 
not only by the OP.
  
>> Use mysqli or pdo_mysql instead.
> 
> Agreed.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#10859

In article <13286076.b1rK9CuggJ@PointedEars.de>,
 Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

> Lew Pitcher wrote:

[snipped]

> And please skip the attribution novel while you are 
> at it; it does not make sense, and it makes discussions a lot harder to 
> read, to duplicate non-essential header information there. 

You may safely ignore PointyHead's complaints about attribution lines. 
It's one of his little mental glitches that he will no doubt do 
something about one day.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#10862

On 9/24/2013 7:41 AM, Lew Pitcher wrote:
> On Tuesday 24 September 2013 10:34, in comp.lang.php, PointedEars@web.de
> wrote:
>
>> Lew Pitcher wrote:
>>
>>> noreply@example.com wrote:
>>>> Output reseulted in one table row showing with no data.
>>>>
>>>> www.mroldies.met/filetest.php
>>>
>>> If $result is not FALSE, you loop through it using mysql_fetch_array() or
>>> one of it's child functions (mysql_fetch_row or mysql_fetch_assoc()) to
>>> retrieve individual rows
>>>
>>> Something like
>>>
>>>    while ($row = mysql_fetch_array($result) )
>>>    {
>>>      printf("atitle: %s\n",$row['atitle']);
>>>      printf("btitle: %s\n",$row['btitle']);
>>>      /* and so on */
>>>    }
>>
>> JFTR: The mysql extension is *deprecated* and will be *removed*:
>>
>> <http://php.net/mysql_fetch_array>
>
> A very valid point that we've repeatedly made to richard. And that he has
> considered and rejected.
>
>> Use mysqli or pdo_mysql instead.
>
> Agreed.
>

Yeah I made that mistake of banging my head against that wall a month or 
so ago.

I also believe it was at the same time trying to explain how to step 
thru a mysql result set.

Here we are again.

[toc] | [prev] | [next] | [standalone]

#10866

On 2013-09-24 6:40 PM, Scott Johnson wrote:
...
>>>
>>> JFTR: The mysql extension is *deprecated* and will be *removed*:

Simple scare tactics from over-sized egos. It's silly.

>>>
...
> Yeah I made that mistake of banging my head against that wall a month or
> so ago.
>
> I also believe it was at the same time trying to explain how to step
> thru a mysql result set.
>
> Here we are again.

[toc] | [prev] | [next] | [standalone]

#10871

On Tue, 24 Sep 2013 19:14:09 -0400, Twayne <nobody@spamcop.net> wrote:

>On 2013-09-24 6:40 PM, Scott Johnson wrote:
>...
>>>>
>>>> JFTR: The mysql extension is *deprecated* and will be *removed*:
>
>Simple scare tactics from over-sized egos. It's silly.

Huh? Can you explain that? The warnings from the folks that decide
seem clear enough: http://www.php.net/mysql_query 

How is that a scare tactic or about over-sized egos?

[toc] | [prev] | [next] | [standalone]

#10911

On 2013-09-24 9:43 PM, Richard Yates wrote:
> On Tue, 24 Sep 2013 19:14:09 -0400, Twayne <nobody@spamcop.net> wrote:
>
>> On 2013-09-24 6:40 PM, Scott Johnson wrote:
>> ...
>>>>>
>>>>> JFTR: The mysql extension is *deprecated* and will be *removed*:
>>
>> Simple scare tactics from over-sized egos. It's silly.
>
> Huh? Can you explain that? The warnings from the folks that decide
> seem clear enough: http://www.php.net/mysql_query
>
> How is that a scare tactic or about over-sized egos?
>
>

But that little tidbit of information has not been included in any of 
the foregoing posts. Why? Control attempts of the few.

[toc] | [prev] | [next] | [standalone]

#10863

On 2013-09-24 10:41 AM, Lew Pitcher wrote:
> On Tuesday 24 September 2013 10:34, in comp.lang.php, PointedEars@web.de
> wrote:
>
>> Lew Pitcher wrote:
>>
>>> noreply@example.com wrote:
>>>> Output reseulted in one table row showing with no data.
>>>>
>>>> www.mroldies.met/filetest.php
>>>
>>> If $result is not FALSE, you loop through it using mysql_fetch_array() or
>>> one of it's child functions (mysql_fetch_row or mysql_fetch_assoc()) to
>>> retrieve individual rows
>>>
>>> Something like
>>>
>>>    while ($row = mysql_fetch_array($result) )
>>>    {
>>>      printf("atitle: %s\n",$row['atitle']);
>>>      printf("btitle: %s\n",$row['btitle']);
>>>      /* and so on */
>>>    }
>>
>> JFTR: The mysql extension is *deprecated* and will be *removed*:
>>
>> <http://php.net/mysql_fetch_array>
>
> A very valid point that we've repeatedly made to richard. And that he has
> considered and rejected.
>
>> Use mysqli or pdo_mysql instead.
>
> Agreed.
>

Mmm, not so valid; it's going to be a good long time before it's 
deprecated on most servers. What's always  neglected with that little 
bit of wisdom is IN WHAT is it being deprecated and when is it expected 
to be all that's available? Hell, many sites are still offering a choice 
of versions, usually 2, sometimes 3.

The scare tactics are silly and that's why people don't worry about it.

[toc] | [prev] | [next] | [standalone]

#10874

On 9/24/2013 3:50 PM, Twayne wrote:
> On 2013-09-24 10:41 AM, Lew Pitcher wrote:
>> On Tuesday 24 September 2013 10:34, in comp.lang.php, PointedEars@web.de
>> wrote:
>>
>>> Lew Pitcher wrote:
>>>
>>>> noreply@example.com wrote:
>>>>> Output reseulted in one table row showing with no data.
>>>>>
>>>>> www.mroldies.met/filetest.php
>>>>
>>>> If $result is not FALSE, you loop through it using
>>>> mysql_fetch_array() or
>>>> one of it's child functions (mysql_fetch_row or mysql_fetch_assoc()) to
>>>> retrieve individual rows
>>>>
>>>> Something like
>>>>
>>>>    while ($row = mysql_fetch_array($result) )
>>>>    {
>>>>      printf("atitle: %s\n",$row['atitle']);
>>>>      printf("btitle: %s\n",$row['btitle']);
>>>>      /* and so on */
>>>>    }
>>>
>>> JFTR: The mysql extension is *deprecated* and will be *removed*:
>>>
>>> <http://php.net/mysql_fetch_array>
>>
>> A very valid point that we've repeatedly made to richard. And that he has
>> considered and rejected.
>>
>>> Use mysqli or pdo_mysql instead.
>>
>> Agreed.
>>
>
> Mmm, not so valid; it's going to be a good long time before it's
> deprecated on most servers. What's always  neglected with that little
> bit of wisdom is IN WHAT is it being deprecated and when is it expected
> to be all that's available? Hell, many sites are still offering a choice
> of versions, usually 2, sometimes 3.
>
> The scare tactics are silly and that's why people don't worry about it.
>
>

Which programmers (people) would that be?

[toc] | [prev] | [next] | [standalone]

#10904

Twayne wrote:

> On 2013-09-24 10:41 AM, Lew Pitcher wrote:
>> On Tuesday 24 September 2013 10:34, in comp.lang.php,
>> PointedEars@web.de wrote:
>>
>>> Lew Pitcher wrote:
>>>
>>>> noreply@example.com wrote:

<snip>

>>>> If $result is not FALSE, you loop through it using
>>>> mysql_fetch_array() or one of it's child functions
>>>> (mysql_fetch_row or mysql_fetch_assoc()) to retrieve
>>>> individual rows 

<snip code>

>>> JFTR: The mysql extension is *deprecated* and will be
>>> *removed*: 
>>>
>>> <http://php.net/mysql_fetch_array>
>>
>> A very valid point that we've repeatedly made to richard. And
>> that he has considered and rejected.
>>
>>> Use mysqli or pdo_mysql instead.
>>
>> Agreed.
>>
> 
> Mmm, not so valid; it's going to be a good long time before it's
> deprecated on most servers.

Arbitrary server admins don't determine when features of PHP 
become deprecated, the PHP development team does.

> What's always  neglected with that
> little bit of wisdom is IN WHAT is it being deprecated and when
> is it expected to be all that's available? Hell, many sites are
> still offering a choice of versions, usually 2, sometimes 3.

When giving people advice about writing code, it's helpful to 
encourage the best possible practices. The mysql extension is 
indeed deprecated, and people learning PHP ought to be made well 
aware of this.

While your code may continue to work on your system, the same 
cannot be said of everyone who takes advice from posts such as 
those in this thread.

If you would like your code to be as correct and portable as 
possible--if you care at all about writing good code--why would 
you dismiss completely that an extension is deprecated?

> The scare tactics are silly and that's why people don't worry
> about it. 

People are trying to provide helpful information. No one here is 
employing scare tactics.

-- 
Curtis Dyer
<?$x='<?$x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web