
Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
<?
$query = "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 .
".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 .
".najava, " . " DATE_FORMAT(" . $this->tabela3 . ".vrijeme_stavljanja,
'%e. %c. %Y. %k:%i') FROM " . $this->tabela3 . ", " . $this->tabela2 .
" AS xref WHERE " . $this->tabela3 . ".id=xref.spis_id AND
xref.vrsta_id=" . $this->DB->quote($vrsta) . " ORDER BY " .
$this->tabela3 . ".vrijeme_stavljanja DESC";
?>
php query doesn't return formated date and time, while this works
through console window:
SELECT spisi.id, spisi.naziv, spisi.spisatelj, spisi.najava, DATE_FORMAT
(spisi.vrijeme_stavljanja, '%e. %c. %Y. %k:%i') FROM spisi,
spis_vrsta_xref AS xref WHERE spisi.id=xref.spis_id AND
xref.vrsta_id="7" ORDER BY spisi.vrijeme_stavljanja DESC;
i guess that it has somethnig to do with '%e. %c. %Y. %k:%i' part of the
DATE_TIME parameters not escaped right, but the same parameters work
when querying only one table without conditional statement.
looking forward to see answers to this puzzle.
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> <?
> $query =3D "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 . =
> ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 . =
> ".najava, " . " DATE_FORMAT(" . $this->tabela3 . ".vrijeme_stavljanja,=
=
> '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 . ", " . $this->tabela2 =
.. =
> " AS xref WHERE " . $this->tabela3 . ".id=3Dxref.spis_id AND =
> xref.vrsta_id=3D" . $this->DB->quote($vrsta) . " ORDER BY " . =
> $this->tabela3 . ".vrijeme_stavljanja DESC";
> ?>
>
> php query doesn't return formated date and time, while this works
> through console window:
Echo your query, and see the problem. You're messing up quotes.
-- =
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Rik wrote:
> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>
>> <?
>> $query = "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 .
>> ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 .
>> ".najava, " . " DATE_FORMAT(" . $this->tabela3 .
>> ".vrijeme_stavljanja, '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 .
>> ", " . $this->tabela2 . " AS xref WHERE " . $this->tabela3 .
>> ".id=xref.spis_id AND xref.vrsta_id=" . $this->DB->quote($vrsta) . "
>> ORDER BY " . $this->tabela3 . ".vrijeme_stavljanja DESC";
>> ?>
>>
>> php query doesn't return formated date and time, while this works
>> through console window:
>
>
> Echo your query, and see the problem. You're messing up quotes.
>
thanks for trying, but i have put echoed query in mysql console
(the one i posted here) and it works, but from php i got NULL..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> <?
> $query =3D "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 . =
> ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 . =
> ".najava, " . " DATE_FORMAT(" . $this->tabela3 . ".vrijeme_stavljanja,=
=
> '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 . ", " . $this->tabela2 =
.. =
> " AS xref WHERE " . $this->tabela3 . ".id=3Dxref.spis_id AND =
> xref.vrsta_id=3D" . $this->DB->quote($vrsta) . " ORDER BY " . =
> $this->tabela3 . ".vrijeme_stavljanja DESC";
> ?>
>
> php query doesn't return formated date and time, while this works
> through console window:
Echo your query, and see the problem. You're messing up quotes.
-- =
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Rik wrote:
> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>
>> <?
>> $query = "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 .
>> ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 .
>> ".najava, " . " DATE_FORMAT(" . $this->tabela3 .
>> ".vrijeme_stavljanja, '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 .
>> ", " . $this->tabela2 . " AS xref WHERE " . $this->tabela3 .
>> ".id=xref.spis_id AND xref.vrsta_id=" . $this->DB->quote($vrsta) . "
>> ORDER BY " . $this->tabela3 . ".vrijeme_stavljanja DESC";
>> ?>
>>
>> php query doesn't return formated date and time, while this works
>> through console window:
>
>
> Echo your query, and see the problem. You're messing up quotes.
>
thanks for trying, but i have put echoed query in mysql console
(the one i posted here) and it works, but from php i got NULL..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir wrote:
> php query doesn't return formated date and time
You're not explicitly giving the formatted date column a name. Try
something like:
... DATE_FORMAT (spisi.vrijeme_stavljanja,
'%e. %c. %Y. %k:%i') AS blah FROM ...
--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux
* = I'm getting there!
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Toby A Inkster wrote:
> laverdir wrote:
>
>
>>php query doesn't return formated date and time
>
>
> You're not explicitly giving the formatted date column a name. Try
> something like:
>
> ... DATE_FORMAT (spisi.vrijeme_stavljanja,
> '%e. %c. %Y. %k:%i') AS blah FROM ...
>
thank you very much, i owe you one..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir wrote:
> php query doesn't return formated date and time
You're not explicitly giving the formatted date column a name. Try
something like:
... DATE_FORMAT (spisi.vrijeme_stavljanja,
'%e. %c. %Y. %k:%i') AS blah FROM ...
--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux
* = I'm getting there!
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Toby A Inkster wrote:
> laverdir wrote:
>
>
>>php query doesn't return formated date and time
>
>
> You're not explicitly giving the formatted date column a name. Try
> something like:
>
> ... DATE_FORMAT (spisi.vrijeme_stavljanja,
> '%e. %c. %Y. %k:%i') AS blah FROM ...
>
thank you very much, i owe you one..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote in message
news:et78o5$r8g$1 [at] ss408.t-com.hr...
| <?
| $query = "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 .
| ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 .
| ".najava, " . " DATE_FORMAT(" . $this->tabela3 . ".vrijeme_stavljanja,
| '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 . ", " . $this->tabela2 .
| " AS xref WHERE " . $this->tabela3 . ".id=xref.spis_id AND
| xref.vrsta_id=" . $this->DB->quote($vrsta) . " ORDER BY " .
| $this->tabela3 . ".vrijeme_stavljanja DESC";
| ?>
|
| php query doesn't return formated date and time, while this works
| through console window:
|
| SELECT spisi.id, spisi.naziv, spisi.spisatelj, spisi.najava, DATE_FORMAT
| (spisi.vrijeme_stavljanja, '%e. %c. %Y. %k:%i') FROM spisi,
| spis_vrsta_xref AS xref WHERE spisi.id=xref.spis_id AND
| xref.vrsta_id="7" ORDER BY spisi.vrijeme_stavljanja DESC;
surely $query doesn't look like this in your code. i assume it looks like
shit here b/c of the way your usenet client wrapped the text...right. i'd be
a fool to believe anyone would intentionally create unmanageble inline sql
statements. i mean, everyone knows that some employers would pass over
otherwise qualified applicants otherwise. i'm sure the statement you have in
real life looks something like this:
$sql = "
SELECT a.id ,
a.naziv ,
a.spisatelj ,
a.najava ,
DATE_FORMAT(a.vrijeme_stavljanja, '%e. %c. %Y %k:%i)
stamp ,
FROM " . $this->tabela3 . " a
JOIN " . $this->tabela2 . " b
ON a.id = b.spis_id
WHERE b.vrsta_id = '" . $this->DB->quote($vrsta) .
"'
ORDER BY a.vrijeme_stavljanja DESC
";
i knew that was what you meant. ;^)
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote in message
news:et78o5$r8g$1 [at] ss408.t-com.hr...
| <?
| $query = "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 .
| ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 .
| ".najava, " . " DATE_FORMAT(" . $this->tabela3 . ".vrijeme_stavljanja,
| '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 . ", " . $this->tabela2 .
| " AS xref WHERE " . $this->tabela3 . ".id=xref.spis_id AND
| xref.vrsta_id=" . $this->DB->quote($vrsta) . " ORDER BY " .
| $this->tabela3 . ".vrijeme_stavljanja DESC";
| ?>
|
| php query doesn't return formated date and time, while this works
| through console window:
|
| SELECT spisi.id, spisi.naziv, spisi.spisatelj, spisi.najava, DATE_FORMAT
| (spisi.vrijeme_stavljanja, '%e. %c. %Y. %k:%i') FROM spisi,
| spis_vrsta_xref AS xref WHERE spisi.id=xref.spis_id AND
| xref.vrsta_id="7" ORDER BY spisi.vrijeme_stavljanja DESC;
surely $query doesn't look like this in your code. i assume it looks like
shit here b/c of the way your usenet client wrapped the text...right. i'd be
a fool to believe anyone would intentionally create unmanageble inline sql
statements. i mean, everyone knows that some employers would pass over
otherwise qualified applicants otherwise. i'm sure the statement you have in
real life looks something like this:
$sql = "
SELECT a.id ,
a.naziv ,
a.spisatelj ,
a.najava ,
DATE_FORMAT(a.vrijeme_stavljanja, '%e. %c. %Y %k:%i)
stamp ,
FROM " . $this->tabela3 . " a
JOIN " . $this->tabela2 . " b
ON a.id = b.spis_id
WHERE b.vrsta_id = '" . $this->DB->quote($vrsta) .
"'
ORDER BY a.vrijeme_stavljanja DESC
";
i knew that was what you meant. ;^)
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Steve wrote:
> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote in message
> news:et78o5$r8g$1 [at] ss408.t-com.hr...
> | <?
> | $query = "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 .
> | ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 .
> | ".najava, " . " DATE_FORMAT(" . $this->tabela3 . ".vrijeme_stavljanja,
> | '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 . ", " . $this->tabela2 .
> | " AS xref WHERE " . $this->tabela3 . ".id=xref.spis_id AND
> | xref.vrsta_id=" . $this->DB->quote($vrsta) . " ORDER BY " .
> | $this->tabela3 . ".vrijeme_stavljanja DESC";
> | ?>
> |
> | php query doesn't return formated date and time, while this works
> | through console window:
> |
> | SELECT spisi.id, spisi.naziv, spisi.spisatelj, spisi.najava, DATE_FORMAT
> | (spisi.vrijeme_stavljanja, '%e. %c. %Y. %k:%i') FROM spisi,
> | spis_vrsta_xref AS xref WHERE spisi.id=xref.spis_id AND
> | xref.vrsta_id="7" ORDER BY spisi.vrijeme_stavljanja DESC;
>
> surely $query doesn't look like this in your code. i assume it looks like
> shit here b/c of the way your usenet client wrapped the text...right. i'd be
> a fool to believe anyone would intentionally create unmanageble inline sql
> statements. i mean, everyone knows that some employers would pass over
> otherwise qualified applicants otherwise. i'm sure the statement you have in
> real life looks something like this:
>
> $sql = "
> SELECT a.id ,
> a.naziv ,
> a.spisatelj ,
> a.najava ,
> DATE_FORMAT(a.vrijeme_stavljanja, '%e. %c. %Y %k:%i)
> stamp ,
> FROM " . $this->tabela3 . " a
> JOIN " . $this->tabela2 . " b
> ON a.id = b.spis_id
> WHERE b.vrsta_id = '" . $this->DB->quote($vrsta) .
> "'
> ORDER BY a.vrijeme_stavljanja DESC
> ";
>
> i knew that was what you meant. ;^)
>
>
it looked similar to this when the query was in
designing proces, but then squizeed to one line
for space saving..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> Steve wrote:
>> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>> | <SNIP hardy legible query>
>> surely $query doesn't look like this in your code. i assume it looks
>> like shit here b/c of the way your usenet client wrapped the
>> text...right. i'd be a fool to believe anyone would intentionally
>> create unmanageble inline sql statements. i mean, everyone knows that
>> some employers would pass over otherwise qualified applicants
>> otherwise. i'm sure the statement you have in real life looks something
>> like this:
>> <SNIP formatted query>
>>
> it looked similar to this when the query was in
> designing proces, but then squizeed to one line
> for space saving..
Do you pay for spaces? I'd hardly think so. Having newlines & spaces:
- has close to no impact on PHP and/or MySQL's speed of interpretation.
- has zero impact on the bandwidth used to clients.
- is really a help when having to work on the code later.
If the spaces are the difference between fitting in the hosting plan or
not you're going to need more room in future anyway. Removing this
formatting from the code is only usefull when it's send to clients, like
javascript. (Or when you have a grudge against fellow/future coders on the
project, including yourself).
Moral of the story: keep nice formatting.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Steve wrote:
> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote in message
> news:et78o5$r8g$1 [at] ss408.t-com.hr...
> | <?
> | $query = "SELECT " . $this->tabela3 . ".id, " . $this->tabela3 .
> | ".naziv, " . $this->tabela3 . ".spisatelj, " . $this->tabela3 .
> | ".najava, " . " DATE_FORMAT(" . $this->tabela3 . ".vrijeme_stavljanja,
> | '%e. %c. %Y. %k:%i') FROM " . $this->tabela3 . ", " . $this->tabela2 .
> | " AS xref WHERE " . $this->tabela3 . ".id=xref.spis_id AND
> | xref.vrsta_id=" . $this->DB->quote($vrsta) . " ORDER BY " .
> | $this->tabela3 . ".vrijeme_stavljanja DESC";
> | ?>
> |
> | php query doesn't return formated date and time, while this works
> | through console window:
> |
> | SELECT spisi.id, spisi.naziv, spisi.spisatelj, spisi.najava, DATE_FORMAT
> | (spisi.vrijeme_stavljanja, '%e. %c. %Y. %k:%i') FROM spisi,
> | spis_vrsta_xref AS xref WHERE spisi.id=xref.spis_id AND
> | xref.vrsta_id="7" ORDER BY spisi.vrijeme_stavljanja DESC;
>
> surely $query doesn't look like this in your code. i assume it looks like
> shit here b/c of the way your usenet client wrapped the text...right. i'd be
> a fool to believe anyone would intentionally create unmanageble inline sql
> statements. i mean, everyone knows that some employers would pass over
> otherwise qualified applicants otherwise. i'm sure the statement you have in
> real life looks something like this:
>
> $sql = "
> SELECT a.id ,
> a.naziv ,
> a.spisatelj ,
> a.najava ,
> DATE_FORMAT(a.vrijeme_stavljanja, '%e. %c. %Y %k:%i)
> stamp ,
> FROM " . $this->tabela3 . " a
> JOIN " . $this->tabela2 . " b
> ON a.id = b.spis_id
> WHERE b.vrsta_id = '" . $this->DB->quote($vrsta) .
> "'
> ORDER BY a.vrijeme_stavljanja DESC
> ";
>
> i knew that was what you meant. ;^)
>
>
it looked similar to this when the query was in
designing proces, but then squizeed to one line
for space saving..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> Steve wrote:
>> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>> | <SNIP hardy legible query>
>> surely $query doesn't look like this in your code. i assume it looks
>> like shit here b/c of the way your usenet client wrapped the
>> text...right. i'd be a fool to believe anyone would intentionally
>> create unmanageble inline sql statements. i mean, everyone knows that
>> some employers would pass over otherwise qualified applicants
>> otherwise. i'm sure the statement you have in real life looks something
>> like this:
>> <SNIP formatted query>
>>
> it looked similar to this when the query was in
> designing proces, but then squizeed to one line
> for space saving..
Do you pay for spaces? I'd hardly think so. Having newlines & spaces:
- has close to no impact on PHP and/or MySQL's speed of interpretation.
- has zero impact on the bandwidth used to clients.
- is really a help when having to work on the code later.
If the spaces are the difference between fitting in the hosting plan or
not you're going to need more room in future anyway. Removing this
formatting from the code is only usefull when it's send to clients, like
javascript. (Or when you have a grudge against fellow/future coders on the
project, including yourself).
Moral of the story: keep nice formatting.
--
Rik Wasmus
Posted on Usenet, not any forum you might see this in.
Ask Smart Questions: http://tinyurl.com/anel
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Rik wrote:
> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>
>> Steve wrote:
>>
>>> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>> | <SNIP hardy legible query>
>
>
>>> surely $query doesn't look like this in your code. i assume it
>>> looks like shit here b/c of the way your usenet client wrapped the
>>> text...right. i'd be a fool to believe anyone would intentionally
>>> create unmanageble inline sql statements. i mean, everyone knows
>>> that some employers would pass over otherwise qualified applicants
>>> otherwise. i'm sure the statement you have in real life looks
>>> something like this:
>>> <SNIP formatted query>
>>>
>> it looked similar to this when the query was in
>> designing proces, but then squizeed to one line
>> for space saving..
>
>
> Do you pay for spaces? I'd hardly think so. Having newlines & spaces:
> - has close to no impact on PHP and/or MySQL's speed of interpretation.
> - has zero impact on the bandwidth used to clients.
> - is really a help when having to work on the code later.
>
> If the spaces are the difference between fitting in the hosting plan or
> not you're going to need more room in future anyway. Removing this
> formatting from the code is only usefull when it's send to clients,
> like javascript. (Or when you have a grudge against fellow/future
> coders on the project, including yourself).
>
> Moral of the story: keep nice formatting.
screen space saving, to be precise.
for me, it's faster to read algorithm
workflow.
why do you care anyway?
are you some kind of coding martha stewart?
quoting beginners guides to writing 'readable'
code didn't help in this case.
im writing code for 22 years and don't care
how it's writen, i can read it equaly fast.
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> screen space saving, to be precise.
> for me, it's faster to read algorithm
> workflow.
>
> why do you care anyway?
Because I've had to deal with other peoples code enough to get really
irritated by their illegible practices. But if you can be a 100% sure you
are the only one dealing with it, be my guest and go ahead.
> are you some kind of coding martha stewart?
Who?
> quoting beginners guides to writing 'readable'
> code didn't help in this case.
Was it a quote yeah? I'd think native speaking writers would have at least
a better concept of grammar then I do .
> im writing code for 22 years and don't care
> how it's writen, i can read it equaly fast.
You can, it's the 'others' we're worried about here.
And if you can read it equally fast, why the hell would you format it
differently in development? Seems a waste of time to me. If you can read
it equally fast why notgive it the layout that most suits you to begin
with?
--
Rik Wasmus
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir wrote:
> Rik wrote:
>> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>
>>> Steve wrote:
>>>
>>>> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>>> | <SNIP hardy legible query>
>>
>>
>>>> surely $query doesn't look like this in your code. i assume it
>>>> looks like shit here b/c of the way your usenet client wrapped the
>>>> text...right. i'd be a fool to believe anyone would intentionally
>>>> create unmanageble inline sql statements. i mean, everyone knows
>>>> that some employers would pass over otherwise qualified applicants
>>>> otherwise. i'm sure the statement you have in real life looks
>>>> something like this:
>>>> <SNIP formatted query>
>>>>
>>> it looked similar to this when the query was in
>>> designing proces, but then squizeed to one line
>>> for space saving..
>>
>>
>> Do you pay for spaces? I'd hardly think so. Having newlines & spaces:
>> - has close to no impact on PHP and/or MySQL's speed of interpretation.
>> - has zero impact on the bandwidth used to clients.
>> - is really a help when having to work on the code later.
>>
>> If the spaces are the difference between fitting in the hosting plan
>> or not you're going to need more room in future anyway. Removing
>> this formatting from the code is only usefull when it's send to
>> clients, like javascript. (Or when you have a grudge against
>> fellow/future coders on the project, including yourself).
>>
>> Moral of the story: keep nice formatting.
>
> screen space saving, to be precise.
> for me, it's faster to read algorithm
> workflow.
>
> why do you care anyway?
> are you some kind of coding martha stewart?
>
> quoting beginners guides to writing 'readable'
> code didn't help in this case.
>
> im writing code for 22 years and don't care
> how it's writen, i can read it equaly fast.
Rik brought up valid points. Your code formatting sucks.
As for why do I care? When you post this crappy junk in the forum, you
expect everyone else to decode it for you?
I personally don't care what you do with code only you will see. But in
my 40 years of programming, I've never been able to say "No one else
will see this code".
Your formatting is that of a lazy bum - and your attitude is even worse.
When I find someone like you on one of my projects he's gone before he
can hit "Enter".
You want help here? I suggest you change your attitude and start
formatting code so it's readable.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
news:op.to945ds6qnv3q9 [at] metallium...
| laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
| > screen space saving, to be precise.
| > for me, it's faster to read algorithm
| > workflow.
| >
| > why do you care anyway?
|
| Because I've had to deal with other peoples code enough to get really
| irritated by their illegible practices. But if you can be a 100% sure you
| are the only one dealing with it, be my guest and go ahead.
AMEN !!!
| > are you some kind of coding martha stewart?
|
| Who?
i think it was meant to be a witty remark of sorts...that doesn't really
carry the desired impact.
| > quoting beginners guides to writing 'readable'
| > code didn't help in this case.
|
| Was it a quote yeah? I'd think native speaking writers would have at least
| a better concept of grammar then I do .
or thAn i do. ;^)
| > im writing code for 22 years and don't care
| > how it's writen, i can read it equaly fast.
i doubt to any degree of success - measured by salary, project size/scope,
business niche filled...much less to say 'team' developed projects (which
are a hallmark of all three).
| You can, it's the 'others' we're worried about here.
| And if you can read it equally fast, why the hell would you format it
| differently in development? Seems a waste of time to me. If you can read
| it equally fast why notgive it the layout that most suits you to begin
| with?
plus, how fucking much time does it take to structure your code as you write
it? to me, as an employer, such neglect is a sign that the overall approach
may have equally hap-hazzard attention paid to it as well.
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Steve <no.one [at] example.com> wrote:
> "Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
> news:op.to945ds6qnv3q9 [at] metallium...
> | > quoting beginners guides to writing 'readable'
> | > code didn't help in this case.
> |
> | Was it a quote yeah? I'd think native speaking writers would have at
> least
> | a better concept of grammar then I do .
>
> or thAn i do. ;^)
Ha! Not intended, but my point exactly :P
--
Rik Wasmus
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
news:op.tpaavq18qnv3q9 [at] metallium...
| Steve <no.one [at] example.com> wrote:
| > "Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
| > news:op.to945ds6qnv3q9 [at] metallium...
| > | > quoting beginners guides to writing 'readable'
| > | > code didn't help in this case.
| > |
| > | Was it a quote yeah? I'd think native speaking writers would have at
| > least
| > | a better concept of grammar then I do .
| >
| > or thAn i do. ;^)
|
| Ha! Not intended, but my point exactly :P
i thought you may get more of a laugh with that than the matha stewart
comment. ;^)
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Rik wrote:
> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>
>> screen space saving, to be precise.
>> for me, it's faster to read algorithm
>> workflow.
>>
>> why do you care anyway?
>
>
> Because I've had to deal with other peoples code enough to get really
> irritated by their illegible practices. But if you can be a 100% sure
> you are the only one dealing with it, be my guest and go ahead.
i'may be iritated with scrolling two pages of query to read an
algorithm..
>
>> are you some kind of coding martha stewart?
>
>
> Who?
queen of folding and housekeeping.. like you are trying
to be with code writing..
>
>> quoting beginners guides to writing 'readable'
>> code didn't help in this case.
>
>
> Was it a quote yeah? I'd think native speaking writers would have at
> least a better concept of grammar then I do .
well, i'm not english native speaker, but at least i can express my self
on half a dozen world accepted languages..
>
>> im writing code for 22 years and don't care
>> how it's writen, i can read it equaly fast.
>
>
> You can, it's the 'others' we're worried about here.
> And if you can read it equally fast, why the hell would you format it
> differently in development? Seems a waste of time to me. If you can
> read it equally fast why notgive it the layout that most suits you to
> begin with?
copy paste works faster..
have a nice weekend..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> Rik wrote:
>> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>
>>> screen space saving, to be precise.
>>> for me, it's faster to read algorithm
>>> workflow.
>>>
>>> why do you care anyway?
>> Because I've had to deal with other peoples code enough to get
>> really irritated by their illegible practices. But if you can be a
>> 100% sure you are the only one dealing with it, be my guest and go
>> ahead.
>
> i'may be iritated with scrolling two pages of query to read an
> algorithm..
This query takes up 2 pages?
And the beauty of formatting would mean that if I have no interest in the
query I can clearly see where it begins & ends, so easily skipped over.
>>> are you some kind of coding martha stewart?
>> Who?
>
> queen of folding and housekeeping.. like you are trying
> to be with code writing..
Well, code should be nicely folded indeed.
>>> quoting beginners guides to writing 'readable'
>>> code didn't help in this case.
>> Was it a quote yeah? I'd think native speaking writers would have at
>> least a better concept of grammar then I do .
>
> well, i'm not english native speaker, but at least i can express my self
> on half a dozen world accepted languages..
Neither am I, and so can I. Your point being? Myt point was that my
statement wasn't a quote (allthough, if it's in "beginners guides to
writing 'readable' code", don't you think it's there for a reason?)
>>> im writing code for 22 years and don't care
>>> how it's writen, i can read it equaly fast.
>> You can, it's the 'others' we're worried about here.
>> And if you can read it equally fast, why the hell would you format it
>> differently in development? Seems a waste of time to me. If you can
>> read it equally fast why notgive it the layout that most suits you to
>> begin with?
>
> copy paste works faster..
Euhm? What copy/paste? You stated:
- "it looked similar to this when the query was in designing proces"
And:
- "i can read it equaly fast"
So I still have no idea why if:
- You are the only coder.
- You can read you 'squizeed' code equally fast.
- You are going to use your own 'squizeed' layout anyway.
....you would bother with your 'design process' formatting. I think it's
because it's actually better readable, allthough you don't want to admit
it.
> have a nice weekend..
I still have a few hours to go, but the same to you.
--
Rik Wasmus
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote in message
news:ete88e$7c5$1 [at] ss408.t-com.hr...
| Rik wrote:
| > laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
| >
| >> screen space saving, to be precise.
| >> for me, it's faster to read algorithm
| >> workflow.
| >>
| >> why do you care anyway?
| >
| >
| > Because I've had to deal with other peoples code enough to get really
| > irritated by their illegible practices. But if you can be a 100% sure
| > you are the only one dealing with it, be my guest and go ahead.
|
| i'may be iritated with scrolling two pages of query to read an
| algorithm..
funny, your terminology. it shows your true lack of experience. while there
may be algorythms in queries, refering to a query as an algorythm (esp. the
one you posted) is NOT equivalent.
as for the number of pages to a query...write a complex query that DOES
contain an alogrythm or an intriquet join. then modify it later. have a bug
in it. now, try and debug it.
from that perspective, it doesn't even matter if you work alone or with
others. you simply cannot guarantee your modifications will be perfect every
time. i CAN guarantee however, that it saves time debugging AND in
implimenting changes in the query.
i'm afraid your inexperience and lack of pragmatism is showing. what's worse
is your refusal to acknowlege that we may be giving you the most sound
advice you've had in a while!
| >> are you some kind of coding martha stewart?
| >
| >
| > Who?
|
| queen of folding and housekeeping.. like you are trying
| to be with code writing..
neatness counts. in a cluttered space, i'm afraid you are left a servant to
your memory (and others simply see a mess). even so, you probably still ask
yourself, 'now where did i put that screwdriver?'
| >> quoting beginners guides to writing 'readable'
| >> code didn't help in this case.
| >
| >
| > Was it a quote yeah? I'd think native speaking writers would have at
| > least a better concept of grammar then I do .
|
| well, i'm not english native speaker, but at least i can express my self
| on half a dozen world accepted languages..
too bad one of those languages is NOT programming. do your tounge-spoken
languages fall from your lips with the same distain for technique and
application?
| >> im writing code for 22 years and don't care
| >> how it's writen, i can read it equaly fast.
| >
| >
| > You can, it's the 'others' we're worried about here.
| > And if you can read it equally fast, why the hell would you format it
| > differently in development? Seems a waste of time to me. If you can
| > read it equally fast why notgive it the layout that most suits you to
| > begin with?
|
| copy paste works faster..
oh, so you're using a query builder because you yourself don't speak ansi
sql? ROFLMFAO !!!
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Rik wrote:
> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>
>> Steve wrote:
>>
>>> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>> | <SNIP hardy legible query>
>
>
>>> surely $query doesn't look like this in your code. i assume it
>>> looks like shit here b/c of the way your usenet client wrapped the
>>> text...right. i'd be a fool to believe anyone would intentionally
>>> create unmanageble inline sql statements. i mean, everyone knows
>>> that some employers would pass over otherwise qualified applicants
>>> otherwise. i'm sure the statement you have in real life looks
>>> something like this:
>>> <SNIP formatted query>
>>>
>> it looked similar to this when the query was in
>> designing proces, but then squizeed to one line
>> for space saving..
>
>
> Do you pay for spaces? I'd hardly think so. Having newlines & spaces:
> - has close to no impact on PHP and/or MySQL's speed of interpretation.
> - has zero impact on the bandwidth used to clients.
> - is really a help when having to work on the code later.
>
> If the spaces are the difference between fitting in the hosting plan or
> not you're going to need more room in future anyway. Removing this
> formatting from the code is only usefull when it's send to clients,
> like javascript. (Or when you have a grudge against fellow/future
> coders on the project, including yourself).
>
> Moral of the story: keep nice formatting.
screen space saving, to be precise.
for me, it's faster to read algorithm
workflow.
why do you care anyway?
are you some kind of coding martha stewart?
quoting beginners guides to writing 'readable'
code didn't help in this case.
im writing code for 22 years and don't care
how it's writen, i can read it equaly fast.
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> screen space saving, to be precise.
> for me, it's faster to read algorithm
> workflow.
>
> why do you care anyway?
Because I've had to deal with other peoples code enough to get really
irritated by their illegible practices. But if you can be a 100% sure you
are the only one dealing with it, be my guest and go ahead.
> are you some kind of coding martha stewart?
Who?
> quoting beginners guides to writing 'readable'
> code didn't help in this case.
Was it a quote yeah? I'd think native speaking writers would have at least
a better concept of grammar then I do .
> im writing code for 22 years and don't care
> how it's writen, i can read it equaly fast.
You can, it's the 'others' we're worried about here.
And if you can read it equally fast, why the hell would you format it
differently in development? Seems a waste of time to me. If you can read
it equally fast why notgive it the layout that most suits you to begin
with?
--
Rik Wasmus
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir wrote:
> Rik wrote:
>> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>
>>> Steve wrote:
>>>
>>>> "laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>>> | <SNIP hardy legible query>
>>
>>
>>>> surely $query doesn't look like this in your code. i assume it
>>>> looks like shit here b/c of the way your usenet client wrapped the
>>>> text...right. i'd be a fool to believe anyone would intentionally
>>>> create unmanageble inline sql statements. i mean, everyone knows
>>>> that some employers would pass over otherwise qualified applicants
>>>> otherwise. i'm sure the statement you have in real life looks
>>>> something like this:
>>>> <SNIP formatted query>
>>>>
>>> it looked similar to this when the query was in
>>> designing proces, but then squizeed to one line
>>> for space saving..
>>
>>
>> Do you pay for spaces? I'd hardly think so. Having newlines & spaces:
>> - has close to no impact on PHP and/or MySQL's speed of interpretation.
>> - has zero impact on the bandwidth used to clients.
>> - is really a help when having to work on the code later.
>>
>> If the spaces are the difference between fitting in the hosting plan
>> or not you're going to need more room in future anyway. Removing
>> this formatting from the code is only usefull when it's send to
>> clients, like javascript. (Or when you have a grudge against
>> fellow/future coders on the project, including yourself).
>>
>> Moral of the story: keep nice formatting.
>
> screen space saving, to be precise.
> for me, it's faster to read algorithm
> workflow.
>
> why do you care anyway?
> are you some kind of coding martha stewart?
>
> quoting beginners guides to writing 'readable'
> code didn't help in this case.
>
> im writing code for 22 years and don't care
> how it's writen, i can read it equaly fast.
Rik brought up valid points. Your code formatting sucks.
As for why do I care? When you post this crappy junk in the forum, you
expect everyone else to decode it for you?
I personally don't care what you do with code only you will see. But in
my 40 years of programming, I've never been able to say "No one else
will see this code".
Your formatting is that of a lazy bum - and your attitude is even worse.
When I find someone like you on one of my projects he's gone before he
can hit "Enter".
You want help here? I suggest you change your attitude and start
formatting code so it's readable.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex [at] attglobal.net
==================
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
news:op.to945ds6qnv3q9 [at] metallium...
| laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
| > screen space saving, to be precise.
| > for me, it's faster to read algorithm
| > workflow.
| >
| > why do you care anyway?
|
| Because I've had to deal with other peoples code enough to get really
| irritated by their illegible practices. But if you can be a 100% sure you
| are the only one dealing with it, be my guest and go ahead.
AMEN !!!
| > are you some kind of coding martha stewart?
|
| Who?
i think it was meant to be a witty remark of sorts...that doesn't really
carry the desired impact.
| > quoting beginners guides to writing 'readable'
| > code didn't help in this case.
|
| Was it a quote yeah? I'd think native speaking writers would have at least
| a better concept of grammar then I do .
or thAn i do. ;^)
| > im writing code for 22 years and don't care
| > how it's writen, i can read it equaly fast.
i doubt to any degree of success - measured by salary, project size/scope,
business niche filled...much less to say 'team' developed projects (which
are a hallmark of all three).
| You can, it's the 'others' we're worried about here.
| And if you can read it equally fast, why the hell would you format it
| differently in development? Seems a waste of time to me. If you can read
| it equally fast why notgive it the layout that most suits you to begin
| with?
plus, how fucking much time does it take to structure your code as you write
it? to me, as an employer, such neglect is a sign that the overall approach
may have equally hap-hazzard attention paid to it as well.
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Steve <no.one [at] example.com> wrote:
> "Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
> news:op.to945ds6qnv3q9 [at] metallium...
> | > quoting beginners guides to writing 'readable'
> | > code didn't help in this case.
> |
> | Was it a quote yeah? I'd think native speaking writers would have at
> least
> | a better concept of grammar then I do .
>
> or thAn i do. ;^)
Ha! Not intended, but my point exactly :P
--
Rik Wasmus
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
news:op.tpaavq18qnv3q9 [at] metallium...
| Steve <no.one [at] example.com> wrote:
| > "Rik" <luiheidsgoeroe [at] hotmail.com> wrote in message
| > news:op.to945ds6qnv3q9 [at] metallium...
| > | > quoting beginners guides to writing 'readable'
| > | > code didn't help in this case.
| > |
| > | Was it a quote yeah? I'd think native speaking writers would have at
| > least
| > | a better concept of grammar then I do .
| >
| > or thAn i do. ;^)
|
| Ha! Not intended, but my point exactly :P
i thought you may get more of a laugh with that than the matha stewart
comment. ;^)
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
Rik wrote:
> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>
>> screen space saving, to be precise.
>> for me, it's faster to read algorithm
>> workflow.
>>
>> why do you care anyway?
>
>
> Because I've had to deal with other peoples code enough to get really
> irritated by their illegible practices. But if you can be a 100% sure
> you are the only one dealing with it, be my guest and go ahead.
i'may be iritated with scrolling two pages of query to read an
algorithm..
>
>> are you some kind of coding martha stewart?
>
>
> Who?
queen of folding and housekeeping.. like you are trying
to be with code writing..
>
>> quoting beginners guides to writing 'readable'
>> code didn't help in this case.
>
>
> Was it a quote yeah? I'd think native speaking writers would have at
> least a better concept of grammar then I do .
well, i'm not english native speaker, but at least i can express my self
on half a dozen world accepted languages..
>
>> im writing code for 22 years and don't care
>> how it's writen, i can read it equaly fast.
>
>
> You can, it's the 'others' we're worried about here.
> And if you can read it equally fast, why the hell would you format it
> differently in development? Seems a waste of time to me. If you can
> read it equally fast why notgive it the layout that most suits you to
> begin with?
copy paste works faster..
have a nice weekend..
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
> Rik wrote:
>> laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
>>
>>> screen space saving, to be precise.
>>> for me, it's faster to read algorithm
>>> workflow.
>>>
>>> why do you care anyway?
>> Because I've had to deal with other peoples code enough to get
>> really irritated by their illegible practices. But if you can be a
>> 100% sure you are the only one dealing with it, be my guest and go
>> ahead.
>
> i'may be iritated with scrolling two pages of query to read an
> algorithm..
This query takes up 2 pages?
And the beauty of formatting would mean that if I have no interest in the
query I can clearly see where it begins & ends, so easily skipped over.
>>> are you some kind of coding martha stewart?
>> Who?
>
> queen of folding and housekeeping.. like you are trying
> to be with code writing..
Well, code should be nicely folded indeed.
>>> quoting beginners guides to writing 'readable'
>>> code didn't help in this case.
>> Was it a quote yeah? I'd think native speaking writers would have at
>> least a better concept of grammar then I do .
>
> well, i'm not english native speaker, but at least i can express my self
> on half a dozen world accepted languages..
Neither am I, and so can I. Your point being? Myt point was that my
statement wasn't a quote (allthough, if it's in "beginners guides to
writing 'readable' code", don't you think it's there for a reason?)
>>> im writing code for 22 years and don't care
>>> how it's writen, i can read it equaly fast.
>> You can, it's the 'others' we're worried about here.
>> And if you can read it equally fast, why the hell would you format it
>> differently in development? Seems a waste of time to me. If you can
>> read it equally fast why notgive it the layout that most suits you to
>> begin with?
>
> copy paste works faster..
Euhm? What copy/paste? You stated:
- "it looked similar to this when the query was in designing proces"
And:
- "i can read it equaly fast"
So I still have no idea why if:
- You are the only coder.
- You can read you 'squizeed' code equally fast.
- You are going to use your own 'squizeed' layout anyway.
....you would bother with your 'design process' formatting. I think it's
because it's actually better readable, allthough you don't want to admit
it.
> have a nice weekend..
I still have a few hours to go, but the same to you.
--
Rik Wasmus
Re: Query inconsistency (MySQL vs PHP) -> DATE_FORMAT
"laverdir" <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote in message
news:ete88e$7c5$1 [at] ss408.t-com.hr...
| Rik wrote:
| > laverdir <MOVE-RE_ME_laverdir [at] post.t-com.hr> wrote:
| >
| >> screen space saving, to be precise.
| >> for me, it's faster to read algorithm
| >> workflow.
| >>
| >> why do you care anyway?
| >
| >
| > Because I've had to deal with other peoples code enough to get really
| > irritated by their illegible practices. But if you can be a 100% sure
| > you are the only one dealing with it, be my guest and go ahead.
|
| i'may be iritated with scrolling two pages of query to read an
| algorithm..
funny, your terminology. it shows your true lack of experience. while there
may be algorythms in queries, refering to a query as an algorythm (esp. the
one you posted) is NOT equivalent.
as for the number of pages to a query...write a complex query that DOES
contain an alogrythm or an intriquet join. then modify it later. have a bug
in it. now, try and debug it.
from that perspective, it doesn't even matter if you work alone or with
others. you simply cannot guarantee your modifications will be perfect every
time. i CAN guarantee however, that it saves time debugging AND in
implimenting changes in the query.
i'm afraid your inexperience and lack of pragmatism is showing. what's worse
is your refusal to acknowlege that we may be giving you the most sound
advice you've had in a while!
| >> are you some kind of coding martha stewart?
| >
| >
| > Who?
|
| queen of folding and housekeeping.. like you are trying
| to be with code writing..
neatness counts. in a cluttered space, i'm afraid you are left a servant to
your memory (and others simply see a mess). even so, you probably still ask
yourself, 'now where did i put that screwdriver?'
| >> quoting beginners guides to writing 'readable'
| >> code didn't help in this case.
| >
| >
| > Was it a quote yeah? I'd think native speaking writers would have at
| > least a better concept of grammar then I do .
|
| well, i'm not english native speaker, but at least i can express my self
| on half a dozen world accepted languages..
too bad one of those languages is NOT programming. do your tounge-spoken
languages fall from your lips with the same distain for technique and
application?
| >> im writing code for 22 years and don't care
| >> how it's writen, i can read it equaly fast.
| >
| >
| > You can, it's the 'others' we're worried about here.
| > And if you can read it equally fast, why the hell would you format it
| > differently in development? Seems a waste of time to me. If you can
| > read it equally fast why notgive it the layout that most suits you to
| > begin with?
|
| copy paste works faster..
oh, so you're using a query builder because you yourself don't speak ansi
sql? ROFLMFAO !!!
PHP » alt.php » Query inconsistency (MySQL vs PHP) -> DATE_FORMAT