| problem saving date fields [message #174052] |
Fri, 20 May 2011 18:38  |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
Hi All,
I have two date fields.
When I change of them the other one gets set back to default:
00-00-0000
I have to save both to make it work. Is there a solution for this?
The arrival_date and departure_date are build up like this:
<select name="arrival_day" class="formFields" id="arrival_day">
<option value="<?php print "$arrival_day"; ?>"><?php print
"$arrival_day"; ?></option>
<option value="01">1</option>
<option value="02">2</option>
<option value="03">3</option>
<option value="04">4</option> etc......
<select name="arrival_month" class="formFields" id="arrival_month">
<option value="<?php print "$arrival_month"; ?>"><?php print
"$arrival_month"; ?></option>
<option value="01">January</option>
<option value="02">February</option>
<option value="03">March</option>
<option value="04">April</option> etc......
<select name="arrival_year" class="formFields" id="arrival_year">
<option value="<?php print "$arrival_year"; ?>"><?php print
"$arrival_year"; ?></option>
<option value="2011">2013</option>
<option value="2011">2012</option>
<option value="2011">2011</option>
<option value="2010">2010</option> etc......
The table is updated like this:
$arrival_month = preg_replace('#[^0-9]#i', '',
$_POST['arrival_month']);
$arrival_day = preg_replace('#[^0-9]#i', '',
$_POST['arrival_day']); // filter everything but numbers
$arrival_year = preg_replace('#[^0-9]#i', '',
$_POST['arrival_year']); // filter everything but numbers
$arrival_date = "$arrival_year-$arrival_month-$arrival_day";
$departure_month = preg_replace('#[^0-9]#i', '',
$_POST['departure_month']);
$departure_day = preg_replace('#[^0-9]#i', '',
$_POST['departure_day']); // filter everything but numbers
$departure_year = preg_replace('#[^0-9]#i', '',
$_POST['departure_year']); //
$departure_date = "$departure_year-$departure_month-$departure_day";
$sqlUpdate = mysql_query("UPDATE myMembers SET
firstname='$firstname', lastname='$lastname', gender='$gender',
partner='$partner', country='$country', rank='$rank',
service='$service', position='$position',
arrival_date='$arrival_date',departure_date='$departure_date' WHERE
id='$id' LIMIT 1");
Is there a reason why this happens? I do create the right format to
put the data back in the table.
Regards
Marco
|
|
|
|
| Re: problem saving date fields [message #174054 is a reply to message #174052] |
Fri, 20 May 2011 18:50  |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 20-05-2011 20:38, Co wrote:
> $sqlUpdate = mysql_query("UPDATE myMembers SET
> firstname='$firstname', lastname='$lastname', gender='$gender',
> partner='$partner', country='$country', rank='$rank',
> service='$service', position='$position',
> arrival_date='$arrival_date',departure_date='$departure_date' WHERE
> id='$id' LIMIT 1");
>
try:
$sql = "UPDATE myMembers SET
firstname='$firstname', lastname='$lastname', gender='$gender',
partner='$partner', country='$country', rank='$rank',
service='$service', position='$position',
arrival_date='$arrival_date',departure_date='$departure_date' WHERE
id='$id' LIMIT 1";
print $sql;
;)
--
Luuk
|
|
|
|
| Re: problem saving date fields [message #174059 is a reply to message #174054] |
Fri, 20 May 2011 21:00 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
I get a "1" as result.
Don't know what you mean with this.
Problem is that the date is set to 00-00-0000.
Is that because there is a default set in the field (00-00-0000)?
Marco
|
|
|
|
| Re: problem saving date fields [message #174062 is a reply to message #174059] |
Fri, 20 May 2011 22:24 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/20/2011 5:00 PM, Co wrote:
> I get a "1" as result.
> Don't know what you mean with this.
> Problem is that the date is set to 00-00-0000.
> Is that because there is a default set in the field (00-00-0000)?
>
> Marco
As a result for what? There's no thread here.
Please use REPLY to a message, not start a new thread. And quote the
appropriate parts of the message, to maintain continuity.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174069 is a reply to message #174062] |
Fri, 20 May 2011 22:52 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 21 mei, 00:24, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> On 5/20/2011 5:00 PM, Co wrote:
>
>> I get a "1" as result.
>> Don't know what you mean with this.
>> Problem is that the date is set to 00-00-0000.
>> Is that because there is a default set in the field (00-00-0000)?
>
>> Marco
>
> As a result for what? There's no thread here.
>
> Please use REPLY to a message, not start a new thread. And quote the
> appropriate parts of the message, to maintain continuity.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================
Luuks thought:
print $sql;
it returns 1, dont know what I should do with it.
Problem is that if I only change one of the dates:
arrival_date='$arrival_date',departure_date='$departure_date'
the other one gets to be the default value 00-00-0000.
Marco
|
|
|
|
| Re: problem saving date fields [message #174071 is a reply to message #174052] |
Fri, 20 May 2011 22:58 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Fri, 20 May 2011 11:38:06 -0700 (PDT), in comp.lang.php Co
<vonclausowitz(at)gmail(dot)com>
<2407eb47-b406-432c-9aed-b76abc94aae9(at)z37g2000vbl(dot)googlegroups(dot)com>
wrote:
> | Hi All,
> |
> | I have two date fields.
> | When I change of them the other one gets set back to default:
> | 00-00-0000
> | I have to save both to make it work. Is there a solution for this?
> |
> | The arrival_date and departure_date are build up like this:
> |
> | <select name="arrival_day" class="formFields" id="arrival_day">
> | <option value="<?php print "$arrival_day"; ?>"><?php print
> | "$arrival_day"; ?></option>
> | <option value="01">1</option>
> | <option value="02">2</option>
> | <option value="03">3</option>
> | <option value="04">4</option> etc......
> |
> | <select name="arrival_month" class="formFields" id="arrival_month">
> | <option value="<?php print "$arrival_month"; ?>"><?php print
> | "$arrival_month"; ?></option>
> | <option value="01">January</option>
> | <option value="02">February</option>
> | <option value="03">March</option>
> | <option value="04">April</option> etc......
> |
> | <select name="arrival_year" class="formFields" id="arrival_year">
> | <option value="<?php print "$arrival_year"; ?>"><?php print
> | "$arrival_year"; ?></option>
> | <option value="2011">2013</option>
> | <option value="2011">2012</option>
> | <option value="2011">2011</option>
> | <option value="2010">2010</option> etc......
How are you setting the $arrival_* and $depature_* values?
If this is a new entry then all of the $arrival_* and $depature_* will
be null or zero - therefore the select options will not be
automatically selected (View Source of the page to see if there are
any error messages within these lists).
You might want to initialise the values by:
$arrival_day = $depature_day = date('j');
$arrival_month = $depature_month = date('n');
$arrival_year = $depature_year = date('Y');
If you read a record from the database then you would over write the
above values. This will ensure that correct values within the select
lists are automatically selected.
> | The table is updated like this:
> |
> | $arrival_month = preg_replace('#[^0-9]#i', '',
> | $_POST['arrival_month']);
> | $arrival_day = preg_replace('#[^0-9]#i', '',
> | $_POST['arrival_day']); // filter everything but numbers
> | $arrival_year = preg_replace('#[^0-9]#i', '',
> | $_POST['arrival_year']); // filter everything but numbers
> | $arrival_date = "$arrival_year-$arrival_month-$arrival_day";
> |
> | $departure_month = preg_replace('#[^0-9]#i', '',
> | $_POST['departure_month']);
> | $departure_day = preg_replace('#[^0-9]#i', '',
> | $_POST['departure_day']); // filter everything but numbers
> | $departure_year = preg_replace('#[^0-9]#i', '',
> | $_POST['departure_year']); //
> | $departure_date = "$departure_year-$departure_month-$departure_day";
You are assuming that items within the listboxs have been selected
(normally this the case only if the initial setup is correct).
You should use
$arrival_day = ( isset( $_POST['arrival_day'] ) ?
intval($_POST['arrival_day']) : 0;
if( $arrival_day == 0 ) { $pageError = "Invalid arrival day number";}
I also assume that you are checking that you can't arrive before you
depart :-)
> | $sqlUpdate = mysql_query("UPDATE myMembers SET
> | firstname='$firstname', lastname='$lastname', gender='$gender',
> | partner='$partner', country='$country', rank='$rank',
> | service='$service', position='$position',
> | arrival_date='$arrival_date',departure_date='$departure_date' WHERE
> | id='$id' LIMIT 1");
> |
> | Is there a reason why this happens? I do create the right format to
> | put the data back in the table.
But are the values your setting the ones you expect?
-- --------------------------------------------------------------
Anything But Marriage, perversely, turns one of the country's
more culturally visible minorities into an advertisement for just
how cool and successful life outside of wedlock can be.
http://www.theatlantic.com/issues/2002/05/rauch.htm
-- --------------------------------------------------------------
|
|
|
|
| Re: problem saving date fields [message #174074 is a reply to message #174069] |
Sat, 21 May 2011 02:30 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/20/2011 6:52 PM, Co wrote:
> On 21 mei, 00:24, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>> On 5/20/2011 5:00 PM, Co wrote:
>>
>>> I get a "1" as result.
>>> Don't know what you mean with this.
>>> Problem is that the date is set to 00-00-0000.
>>> Is that because there is a default set in the field (00-00-0000)?
>>
>>> Marco
>>
>> As a result for what? There's no thread here.
>>
>> Please use REPLY to a message, not start a new thread. And quote the
>> appropriate parts of the message, to maintain continuity.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================
>
> Luuks thought:
> print $sql;
>
> it returns 1, dont know what I should do with it.
> Problem is that if I only change one of the dates:
> arrival_date='$arrival_date',departure_date='$departure_date'
>
> the other one gets to be the default value 00-00-0000.
>
> Marco
But what do you get on your window when you display the sql statement
like he suggested?
Generally, when you're having troubles with SQL statements, it's best to
print (or echo) the statement to the display to see if you actually have
what you think you have.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174076 is a reply to message #174071] |
Sat, 21 May 2011 02:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/20/2011 6:58 PM, Jeff North wrote:
> On Fri, 20 May 2011 11:38:06 -0700 (PDT), in comp.lang.php Co
> <vonclausowitz(at)gmail(dot)com>
> <2407eb47-b406-432c-9aed-b76abc94aae9(at)z37g2000vbl(dot)googlegroups(dot)com>
> wrote:
>
>> | Hi All,
>> |
>> | I have two date fields.
>> | When I change of them the other one gets set back to default:
>> | 00-00-0000
>> | I have to save both to make it work. Is there a solution for this?
>> |
>> | The arrival_date and departure_date are build up like this:
>> |
>> |<select name="arrival_day" class="formFields" id="arrival_day">
>> |<option value="<?php print "$arrival_day"; ?>"><?php print
>> | "$arrival_day"; ?></option>
>> |<option value="01">1</option>
>> |<option value="02">2</option>
>> |<option value="03">3</option>
>> |<option value="04">4</option> etc......
>> |
>> |<select name="arrival_month" class="formFields" id="arrival_month">
>> |<option value="<?php print "$arrival_month"; ?>"><?php print
>> | "$arrival_month"; ?></option>
>> |<option value="01">January</option>
>> |<option value="02">February</option>
>> |<option value="03">March</option>
>> |<option value="04">April</option> etc......
>> |
>> |<select name="arrival_year" class="formFields" id="arrival_year">
>> |<option value="<?php print "$arrival_year"; ?>"><?php print
>> | "$arrival_year"; ?></option>
>> |<option value="2011">2013</option>
>> |<option value="2011">2012</option>
>> |<option value="2011">2011</option>
>> |<option value="2010">2010</option> etc......
>
> How are you setting the $arrival_* and $depature_* values?
>
From the input - after is is sent from his form.
> If this is a new entry then all of the $arrival_* and $depature_* will
> be null or zero - therefore the select options will not be
> automatically selected (View Source of the page to see if there are
> any error messages within these lists).
>
No, because he isn't setting them until after the form has been
displayed and the user has made his selection.
> You might want to initialise the values by:
> $arrival_day = $depature_day = date('j');
> $arrival_month = $depature_month = date('n');
> $arrival_year = $depature_year = date('Y');
>
> If you read a record from the database then you would over write the
> above values. This will ensure that correct values within the select
> lists are automatically selected.
>
No, it is NOT a good idea to add a row every time the page is displayed.
Wait for the user to respond to the request, then add it to the
database, as he is already doing.
>> | The table is updated like this:
>> |
>> | $arrival_month = preg_replace('#[^0-9]#i', '',
>> | $_POST['arrival_month']);
>> | $arrival_day = preg_replace('#[^0-9]#i', '',
>> | $_POST['arrival_day']); // filter everything but numbers
>> | $arrival_year = preg_replace('#[^0-9]#i', '',
>> | $_POST['arrival_year']); // filter everything but numbers
>> | $arrival_date = "$arrival_year-$arrival_month-$arrival_day";
>> |
>> | $departure_month = preg_replace('#[^0-9]#i', '',
>> | $_POST['departure_month']);
>> | $departure_day = preg_replace('#[^0-9]#i', '',
>> | $_POST['departure_day']); // filter everything but numbers
>> | $departure_year = preg_replace('#[^0-9]#i', '',
>> | $_POST['departure_year']); //
>> | $departure_date = "$departure_year-$departure_month-$departure_day";
>
> You are assuming that items within the listboxs have been selected
> (normally this the case only if the initial setup is correct).
> You should use
> $arrival_day = ( isset( $_POST['arrival_day'] ) ?
> intval($_POST['arrival_day']) : 0;
> if( $arrival_day == 0 ) { $pageError = "Invalid arrival day number";}
>
> I also assume that you are checking that you can't arrive before you
> depart :-)
>
He needs to do other validation on the data also, but first he needs to
get this part working.
>> | $sqlUpdate = mysql_query("UPDATE myMembers SET
>> | firstname='$firstname', lastname='$lastname', gender='$gender',
>> | partner='$partner', country='$country', rank='$rank',
>> | service='$service', position='$position',
>> | arrival_date='$arrival_date',departure_date='$departure_date' WHERE
>> | id='$id' LIMIT 1");
>> |
>> | Is there a reason why this happens? I do create the right format to
>> | put the data back in the table.
>
> But are the values your setting the ones you expect?
>
That's why the suggestion to print the SQL statement he generated.
BTW - your sig separator is broken. It needs to be exactly
hyphen-hyphen-space-newline.
>
> -- --------------------------------------------------------------
> Anything But Marriage, perversely, turns one of the country's
> more culturally visible minorities into an advertisement for just
> how cool and successful life outside of wedlock can be.
>
> http://www.theatlantic.com/issues/2002/05/rauch.htm
> -- --------------------------------------------------------------
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174079 is a reply to message #174076] |
Sat, 21 May 2011 03:13 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
<jstucklex(at)attglobal(dot)net>
<ir78cp$53s$1(at)dont-email(dot)me> wrote:
> | On 5/20/2011 6:58 PM, Jeff North wrote:
> | > On Fri, 20 May 2011 11:38:06 -0700 (PDT), in comp.lang.php Co
> | > <vonclausowitz(at)gmail(dot)com>
> | > <2407eb47-b406-432c-9aed-b76abc94aae9(at)z37g2000vbl(dot)googlegroups(dot)com>
> | > wrote:
> | >
> | >> | Hi All,
> | >> |
> | >> | I have two date fields.
> | >> | When I change of them the other one gets set back to default:
> | >> | 00-00-0000
> | >> | I have to save both to make it work. Is there a solution for this?
> | >> |
> | >> | The arrival_date and departure_date are build up like this:
[snip]
> | >> |<select name="arrival_year" class="formFields" id="arrival_year">
> | >> |<option value="<?php print "$arrival_year"; ?>"><?php print
> | >> | "$arrival_year"; ?></option>
> | >> |<option value="2011">2013</option>
> | >> |<option value="2011">2012</option>
> | >> |<option value="2011">2011</option>
> | >> |<option value="2010">2010</option> etc......
> | >
> | > How are you setting the $arrival_* and $depature_* values?
> |
> | From the input - after is is sent from his form.
Therefore the variables aren't initialised and would cause php errors
- right?
> | > If this is a new entry then all of the $arrival_* and $depature_* will
> | > be null or zero - therefore the select options will not be
> | > automatically selected (View Source of the page to see if there are
> | > any error messages within these lists).
> |
> | No, because he isn't setting them until after the form has been
> | displayed and the user has made his selection.
Methinks you are making too many assumptions - have you seen the full
source code of the page?
> | > You might want to initialise the values by:
> | > $arrival_day = $depature_day = date('j');
> | > $arrival_month = $depature_month = date('n');
> | > $arrival_year = $depature_year = date('Y');
> | >
> | > If you read a record from the database then you would over write the
> | > above values. This will ensure that correct values within the select
> | > lists are automatically selected.
> |
> | No, it is NOT a good idea to add a row every time the page is displayed.
> | Wait for the user to respond to the request, then add it to the
> | database, as he is already doing.
Who said anything about "add a row every time the page is displayed".
According to your criteria there would never be any edit pages - only
add pages.
If editing an existing item wouldn't you want to read the already
stored data from the database?
i.e.
// initialise variables to meaningful values
// if editing an existing entry
// read record
// overwrite initialised variables
// display the page
> | >> | The table is updated like this:
[snip]
> | >> | $departure_month = preg_replace('#[^0-9]#i', '',
> | >> | $_POST['departure_month']);
> | >> | $departure_day = preg_replace('#[^0-9]#i', '',
> | >> | $_POST['departure_day']); // filter everything but numbers
> | >> | $departure_year = preg_replace('#[^0-9]#i', '',
> | >> | $_POST['departure_year']); //
> | >> | $departure_date = "$departure_year-$departure_month-$departure_day";
> | >
> | > You are assuming that items within the listboxs have been selected
> | > (normally this the case only if the initial setup is correct).
> | > You should use
> | > $arrival_day = ( isset( $_POST['arrival_day'] ) ?
> | > intval($_POST['arrival_day']) : 0;
> | > if( $arrival_day == 0 ) { $pageError = "Invalid arrival day number";}
> | >
> | > I also assume that you are checking that you can't arrive before you
> | > depart :-)
> |
> | He needs to do other validation on the data also, but first he needs to
> | get this part working.
....and how do you know this, hmmmm?
> | >> | $sqlUpdate = mysql_query("UPDATE myMembers SET
> | >> | firstname='$firstname', lastname='$lastname', gender='$gender',
> | >> | partner='$partner', country='$country', rank='$rank',
> | >> | service='$service', position='$position',
> | >> | arrival_date='$arrival_date',departure_date='$departure_date' WHERE
> | >> | id='$id' LIMIT 1");
> | >> |
> | >> | Is there a reason why this happens? I do create the right format to
> | >> | put the data back in the table.
> | >
> | > But are the values your setting the ones you expect?
> |
> | That's why the suggestion to print the SQL statement he generated.
The SQL statement should be ok - it's the "When I change of them the
other one gets set back to default: 00-00-0000" I'm considering.
> | BTW - your sig separator is broken. It needs to be exactly
> | hyphen-hyphen-space-newline.
Oh Jerry is now the sig line cop :-P
Complain to the writers of Thunderbird as I couldn't care less about
whether or not my sig appears 'correctly' in your news reader.
-- -------------------------------------------------
The supplied code is for guideline purposes only.
|
|
|
|
| Re: problem saving date fields [message #174080 is a reply to message #174079] |
Sat, 21 May 2011 06:47 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 21 mei, 05:13, Jeff North <jnort...@yahoo.com.au> wrote:
> On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
> <jstuck...@attglobal.net>
>
> <ir78cp$53...@dont-email.me> wrote:
>> | On 5/20/2011 6:58 PM, Jeff North wrote:
>> | > On Fri, 20 May 2011 11:38:06 -0700 (PDT), in comp.lang.php Co
>> | > <vonclausow...@gmail.com>
>> | > <2407eb47-b406-432c-9aed-b76abc94a...@z37g2000vbl.googlegroups.com>
>> | > wrote:
>> | >
>> | >> | Hi All,
>> | >> |
>> | >> | I have two date fields.
>> | >> | When I change of them the other one gets set back to default:
>> | >> | 00-00-0000
>> | >> | I have to save both to make it work. Is there a solution for this?
>> | >> |
>> | >> | The arrival_date and departure_date are build up like this:
>
> [snip]
>
>> | >> |<select name="arrival_year" class="formFields" id="arrival_year">
>> | >> |<option value="<?php print "$arrival_year"; ?>"><?php print
>> | >> | "$arrival_year"; ?></option>
>> | >> |<option value="2011">2013</option>
>> | >> |<option value="2011">2012</option>
>> | >> |<option value="2011">2011</option>
>> | >> |<option value="2010">2010</option> etc......
>> | >
>> | > How are you setting the $arrival_* and $depature_* values?
>> |
>> | From the input - after is is sent from his form.
>
> Therefore the variables aren't initialised and would cause php errors
> - right?
>
>> | > If this is a new entry then all of the $arrival_* and $depature_* will
>> | > be null or zero - therefore the select options will not be
>> | > automatically selected (View Source of the page to see if there are
>> | > any error messages within these lists).
>> |
>> | No, because he isn't setting them until after the form has been
>> | displayed and the user has made his selection.
>
> Methinks you are making too many assumptions - have you seen the full
> source code of the page?
>
>> | > You might want to initialise the values by:
>> | > $arrival_day = $depature_day = date('j');
>> | > $arrival_month = $depature_month = date('n');
>> | > $arrival_year = $depature_year = date('Y');
>> | >
>> | > If you read a record from the database then you would over write the
>> | > above values. This will ensure that correct values within the select
>> | > lists are automatically selected.
>> |
>> | No, it is NOT a good idea to add a row every time the page is displayed.
>> | Wait for the user to respond to the request, then add it to the
>> | database, as he is already doing.
>
> Who said anything about "add a row every time the page is displayed".
> According to your criteria there would never be any edit pages - only
> add pages.
>
> If editing an existing item wouldn't you want to read the already
> stored data from the database?
>
> i.e.
> // initialise variables to meaningful values
> // if editing an existing entry
> // read record
> // overwrite initialised variables
> // display the page
>
>> | >> | The table is updated like this:
>
> [snip]
>
>
>
>
>
>
>
>
>
>> | >> | $departure_month = preg_replace('#[^0-9]#i', '',
>> | >> | $_POST['departure_month']);
>> | >> | $departure_day = preg_replace('#[^0-9]#i', '',
>> | >> | $_POST['departure_day']); // filter everything but numbers
>> | >> | $departure_year = preg_replace('#[^0-9]#i', '',
>> | >> | $_POST['departure_year']); //
>> | >> | $departure_date = "$departure_year-$departure_month-$departure_day";
>> | >
>> | > You are assuming that items within the listboxs have been selected
>> | > (normally this the case only if the initial setup is correct).
>> | > You should use
>> | > $arrival_day = ( isset( $_POST['arrival_day'] ) ?
>> | > intval($_POST['arrival_day']) : 0;
>> | > if( $arrival_day == 0 ) { $pageError = "Invalid arrival day number";}
>> | >
>> | > I also assume that you are checking that you can't arrive before you
>> | > depart :-)
>> |
>> | He needs to do other validation on the data also, but first he needs to
>> | get this part working.
>
> ...and how do you know this, hmmmm?
>
>> | >> | $sqlUpdate = mysql_query("UPDATE myMembers SET
>> | >> | firstname='$firstname', lastname='$lastname', gender='$gender',
>> | >> | partner='$partner', country='$country', rank='$rank',
>> | >> | service='$service', position='$position',
>> | >> | arrival_date='$arrival_date',departure_date='$departure_date' WHERE
>> | >> | id='$id' LIMIT 1");
>> | >> |
>> | >> | Is there a reason why this happens? I do create the right format to
>> | >> | put the data back in the table.
>> | >
>> | > But are the values your setting the ones you expect?
>> |
>> | That's why the suggestion to print the SQL statement he generated.
>
> The SQL statement should be ok - it's the "When I change of them the
> other one gets set back to default: 00-00-0000" I'm considering.
>
>> | BTW - your sig separator is broken. It needs to be exactly
>> | hyphen-hyphen-space-newline.
>
> Oh Jerry is now the sig line cop :-P
> Complain to the writers of Thunderbird as I couldn't care less about
> whether or not my sig appears 'correctly' in your news reader.
> -- -------------------------------------------------
> The supplied code is for guideline purposes only.
Did some testing with the print command.
When I update the dates these are the results.
when I change departure:
arrival 2009-0120 departure 11-07-01
when I change arrival:
arrival 2009-07-01 departure 2011-01
it doesn't make any sense to me.
Marco
|
|
|
|
| Re: problem saving date fields [message #174081 is a reply to message #174080] |
Sat, 21 May 2011 07:18 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 21 mei, 08:47, Co <vonclausow...@gmail.com> wrote:
> On 21 mei, 05:13, Jeff North <jnort...@yahoo.com.au> wrote:
>
>
>
>
>
>
>
>
>
>> On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
>> <jstuck...@attglobal.net>
>
>> <ir78cp$53...@dont-email.me> wrote:
>>> | On 5/20/2011 6:58 PM, Jeff North wrote:
>>> | > On Fri, 20 May 2011 11:38:06 -0700 (PDT), in comp.lang.php Co
>>> | > <vonclausow...@gmail.com>
>>> | > <2407eb47-b406-432c-9aed-b76abc94a...@z37g2000vbl.googlegroups.com>
>>> | > wrote:
>>> | >
>>> | >> | Hi All,
>>> | >> |
>>> | >> | I have two date fields.
>>> | >> | When I change of them the other one gets set back to default:
>>> | >> | 00-00-0000
>>> | >> | I have to save both to make it work. Is there a solution for this?
>>> | >> |
>>> | >> | The arrival_date and departure_date are build up like this:
>
>> [snip]
>
>>> | >> |<select name="arrival_year" class="formFields" id="arrival_year">
>>> | >> |<option value="<?php print "$arrival_year"; ?>"><?php print
>>> | >> | "$arrival_year"; ?></option>
>>> | >> |<option value="2011">2013</option>
>>> | >> |<option value="2011">2012</option>
>>> | >> |<option value="2011">2011</option>
>>> | >> |<option value="2010">2010</option> etc......
>>> | >
>>> | > How are you setting the $arrival_* and $depature_* values?
>>> |
>>> | From the input - after is is sent from his form.
>
>> Therefore the variables aren't initialised and would cause php errors
>> - right?
>
>>> | > If this is a new entry then all of the $arrival_* and $depature_* will
>>> | > be null or zero - therefore the select options will not be
>>> | > automatically selected (View Source of the page to see if there are
>>> | > any error messages within these lists).
>>> |
>>> | No, because he isn't setting them until after the form has been
>>> | displayed and the user has made his selection.
>
>> Methinks you are making too many assumptions - have you seen the full
>> source code of the page?
>
>>> | > You might want to initialise the values by:
>>> | > $arrival_day = $depature_day = date('j');
>>> | > $arrival_month = $depature_month = date('n');
>>> | > $arrival_year = $depature_year = date('Y');
>>> | >
>>> | > If you read a record from the database then you would over write the
>>> | > above values. This will ensure that correct values within the select
>>> | > lists are automatically selected.
>>> |
>>> | No, it is NOT a good idea to add a row every time the page is displayed.
>>> | Wait for the user to respond to the request, then add it to the
>>> | database, as he is already doing.
>
>> Who said anything about "add a row every time the page is displayed".
>> According to your criteria there would never be any edit pages - only
>> add pages.
>
>> If editing an existing item wouldn't you want to read the already
>> stored data from the database?
>
>> i.e.
>> // initialise variables to meaningful values
>> // if editing an existing entry
>> // read record
>> // overwrite initialised variables
>> // display the page
>
>>> | >> | The table is updated like this:
>
>> [snip]
>
>>> | >> | $departure_month = preg_replace('#[^0-9]#i', '',
>>> | >> | $_POST['departure_month']);
>>> | >> | $departure_day = preg_replace('#[^0-9]#i', '',
>>> | >> | $_POST['departure_day']); // filter everything but numbers
>>> | >> | $departure_year = preg_replace('#[^0-9]#i', '',
>>> | >> | $_POST['departure_year']); //
>>> | >> | $departure_date = "$departure_year-$departure_month-$departure_day";
>>> | >
>>> | > You are assuming that items within the listboxs have been selected
>>> | > (normally this the case only if the initial setup is correct).
>>> | > You should use
>>> | > $arrival_day = ( isset( $_POST['arrival_day'] ) ?
>>> | > intval($_POST['arrival_day']) : 0;
>>> | > if( $arrival_day == 0 ) { $pageError = "Invalid arrival day number";}
>>> | >
>>> | > I also assume that you are checking that you can't arrive before you
>>> | > depart :-)
>>> |
>>> | He needs to do other validation on the data also, but first he needs to
>>> | get this part working.
>
>> ...and how do you know this, hmmmm?
>
>>> | >> | $sqlUpdate = mysql_query("UPDATE myMembers SET
>>> | >> | firstname='$firstname', lastname='$lastname', gender='$gender',
>>> | >> | partner='$partner', country='$country', rank='$rank',
>>> | >> | service='$service', position='$position',
>>> | >> | arrival_date='$arrival_date',departure_date='$departure_date' WHERE
>>> | >> | id='$id' LIMIT 1");
>>> | >> |
>>> | >> | Is there a reason why this happens? I do create the right format to
>>> | >> | put the data back in the table.
>>> | >
>>> | > But are the values your setting the ones you expect?
>>> |
>>> | That's why the suggestion to print the SQL statement he generated.
>
>> The SQL statement should be ok - it's the "When I change of them the
>> other one gets set back to default: 00-00-0000" I'm considering.
>
>>> | BTW - your sig separator is broken. It needs to be exactly
>>> | hyphen-hyphen-space-newline.
>
>> Oh Jerry is now the sig line cop :-P
>> Complain to the writers of Thunderbird as I couldn't care less about
>> whether or not my sig appears 'correctly' in your news reader.
>> -- -------------------------------------------------
>> The supplied code is for guideline purposes only.
>
> Did some testing with the print command.
> When I update the dates these are the results.
>
> when I change departure:
> arrival 2009-0120 departure 11-07-01
>
> when I change arrival:
> arrival 2009-07-01 departure 2011-01
>
> it doesn't make any sense to me.
>
> Marco
After some more testing I figured out that the month value of the date
which is not
updated makes the date go corrupt (set to default). So someone the
month value doesn't get read
well from the $_POST['departure_month'].
Any thoughts.
MArco
|
|
|
|
| Re: problem saving date fields [message #174084 is a reply to message #174081] |
Sat, 21 May 2011 07:54 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21-05-2011 09:18, Co wrote:
> On 21 mei, 08:47, Co <vonclausow...@gmail.com> wrote:
>> On 21 mei, 05:13, Jeff North <jnort...@yahoo.com.au> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
>>> <jstuck...@attglobal.net>
>>
>>> <ir78cp$53...@dont-email.me> wrote:
>>>> | On 5/20/2011 6:58 PM, Jeff North wrote:
>>>> | > On Fri, 20 May 2011 11:38:06 -0700 (PDT), in comp.lang.php Co
>>>> | > <vonclausow...@gmail.com>
>>>> | > <2407eb47-b406-432c-9aed-b76abc94a...@z37g2000vbl.googlegroups.com>
>>>> | > wrote:
>>>> | >
>>>> | >> | Hi All,
>>>> | >> |
>>>> | >> | I have two date fields.
>>>> | >> | When I change of them the other one gets set back to default:
>>>> | >> | 00-00-0000
>>>> | >> | I have to save both to make it work. Is there a solution for this?
>>>> | >> |
>>>> | >> | The arrival_date and departure_date are build up like this:
>>
>>> [snip]
>>
>>>> | >> |<select name="arrival_year" class="formFields" id="arrival_year">
>>>> | >> |<option value="<?php print "$arrival_year"; ?>"><?php print
>>>> | >> | "$arrival_year"; ?></option>
>>>> | >> |<option value="2011">2013</option>
>>>> | >> |<option value="2011">2012</option>
>>>> | >> |<option value="2011">2011</option>
>>>> | >> |<option value="2010">2010</option> etc......
>>>> | >
>>>> | > How are you setting the $arrival_* and $depature_* values?
>>>> |
>>>> | From the input - after is is sent from his form.
>>
>>> Therefore the variables aren't initialised and would cause php errors
>>> - right?
>>
>>>> | > If this is a new entry then all of the $arrival_* and $depature_* will
>>>> | > be null or zero - therefore the select options will not be
>>>> | > automatically selected (View Source of the page to see if there are
>>>> | > any error messages within these lists).
>>>> |
>>>> | No, because he isn't setting them until after the form has been
>>>> | displayed and the user has made his selection.
>>
>>> Methinks you are making too many assumptions - have you seen the full
>>> source code of the page?
>>
>>>> | > You might want to initialise the values by:
>>>> | > $arrival_day = $depature_day = date('j');
>>>> | > $arrival_month = $depature_month = date('n');
>>>> | > $arrival_year = $depature_year = date('Y');
>>>> | >
>>>> | > If you read a record from the database then you would over write the
>>>> | > above values. This will ensure that correct values within the select
>>>> | > lists are automatically selected.
>>>> |
>>>> | No, it is NOT a good idea to add a row every time the page is displayed.
>>>> | Wait for the user to respond to the request, then add it to the
>>>> | database, as he is already doing.
>>
>>> Who said anything about "add a row every time the page is displayed".
>>> According to your criteria there would never be any edit pages - only
>>> add pages.
>>
>>> If editing an existing item wouldn't you want to read the already
>>> stored data from the database?
>>
>>> i.e.
>>> // initialise variables to meaningful values
>>> // if editing an existing entry
>>> // read record
>>> // overwrite initialised variables
>>> // display the page
>>
>>>> | >> | The table is updated like this:
>>
>>> [snip]
>>
>>>> | >> | $departure_month = preg_replace('#[^0-9]#i', '',
>>>> | >> | $_POST['departure_month']);
>>>> | >> | $departure_day = preg_replace('#[^0-9]#i', '',
>>>> | >> | $_POST['departure_day']); // filter everything but numbers
>>>> | >> | $departure_year = preg_replace('#[^0-9]#i', '',
>>>> | >> | $_POST['departure_year']); //
>>>> | >> | $departure_date = "$departure_year-$departure_month-$departure_day";
>>>> | >
>>>> | > You are assuming that items within the listboxs have been selected
>>>> | > (normally this the case only if the initial setup is correct).
>>>> | > You should use
>>>> | > $arrival_day = ( isset( $_POST['arrival_day'] ) ?
>>>> | > intval($_POST['arrival_day']) : 0;
>>>> | > if( $arrival_day == 0 ) { $pageError = "Invalid arrival day number";}
>>>> | >
>>>> | > I also assume that you are checking that you can't arrive before you
>>>> | > depart :-)
>>>> |
>>>> | He needs to do other validation on the data also, but first he needs to
>>>> | get this part working.
>>
>>> ...and how do you know this, hmmmm?
>>
>>>> | >> | $sqlUpdate = mysql_query("UPDATE myMembers SET
>>>> | >> | firstname='$firstname', lastname='$lastname', gender='$gender',
>>>> | >> | partner='$partner', country='$country', rank='$rank',
>>>> | >> | service='$service', position='$position',
>>>> | >> | arrival_date='$arrival_date',departure_date='$departure_date' WHERE
>>>> | >> | id='$id' LIMIT 1");
>>>> | >> |
>>>> | >> | Is there a reason why this happens? I do create the right format to
>>>> | >> | put the data back in the table.
>>>> | >
>>>> | > But are the values your setting the ones you expect?
>>>> |
>>>> | That's why the suggestion to print the SQL statement he generated.
>>
>>> The SQL statement should be ok - it's the "When I change of them the
>>> other one gets set back to default: 00-00-0000" I'm considering.
>>
>>>> | BTW - your sig separator is broken. It needs to be exactly
>>>> | hyphen-hyphen-space-newline.
>>
>>> Oh Jerry is now the sig line cop :-P
>>> Complain to the writers of Thunderbird as I couldn't care less about
>>> whether or not my sig appears 'correctly' in your news reader.
>>> -- -------------------------------------------------
>>> The supplied code is for guideline purposes only.
>>
>> Did some testing with the print command.
>> When I update the dates these are the results.
>>
>> when I change departure:
>> arrival 2009-0120 departure 11-07-01
>>
>> when I change arrival:
>> arrival 2009-07-01 departure 2011-01
>>
>> it doesn't make any sense to me.
>>
>> Marco
>
> After some more testing I figured out that the month value of the date
> which is not
> updated makes the date go corrupt (set to default). So someone the
> month value doesn't get read
> well from the $_POST['departure_month'].
>
> Any thoughts.
>
> MArco
I Think you need quotes around the dates
09:52:40 root@test[8]mysql> desc testDate;
+---------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------+------+------+-----+---------+-------+
| SepDate | date | YES | | NULL | |
+---------+------+------+-----+---------+-------+
1 row in set (0.00 sec)
09:52:44 root@test[9]mysql> select * from testDate;
Empty set (0.00 sec)
09:52:51 root@test[10]mysql> insert into testDate values (2011-05-21);
Query OK, 1 row affected, 1 warning (0.00 sec)
09:53:09 root@test[11]mysql> select * from testDate;
+------------+
| SepDate |
+------------+
| 0000-00-00 |
+------------+
1 row in set (0.00 sec)
09:53:10 root@test[12]mysql> insert into testDate values ('2011-05-21');
Query OK, 1 row affected (0.00 sec)
09:53:27 root@test[13]mysql> select * from testDate;
+------------+
| SepDate |
+------------+
| 0000-00-00 |
| 2011-05-21 |
+------------+
2 rows in set (0.00 sec)
--
Luuk
|
|
|
|
| Re: problem saving date fields [message #174085 is a reply to message #174069] |
Sat, 21 May 2011 07:57 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21-05-2011 00:52, Co wrote:
> On 21 mei, 00:24, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> On 5/20/2011 5:00 PM, Co wrote:
>>
>>> I get a "1" as result.
>>> Don't know what you mean with this.
>>> Problem is that the date is set to 00-00-0000.
>>> Is that because there is a default set in the field (00-00-0000)?
>>
>>> Marco
>>
>> As a result for what? There's no thread here.
>>
>> Please use REPLY to a message, not start a new thread. And quote the
>> appropriate parts of the message, to maintain continuity.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================
>
> Luuks thought:
> print $sql;
>
> it returns 1, dont know what I should do with it.
> Problem is that if I only change one of the dates:
> arrival_date='$arrival_date',departure_date='$departure_date'
>
> the other one gets to be the default value 00-00-0000.
>
> Marco
Ok, i responded in the other thread, but wanted to 'add' this:
09:53:29 root@test[14]mysql> insert into testDate values ('21-05-2011');
Query OK, 1 row affected, 1 warning (0.00 sec)
09:55:46 root@test[15]mysql> select * from testDate;
+------------+
| SepDate |
+------------+
| 0000-00-00 |
| 2011-05-21 |
| 0000-00-00 |
+------------+
3 rows in set (0.00 sec)
--
Luuk
|
|
|
|
| Re: problem saving date fields [message #174086 is a reply to message #174085] |
Sat, 21 May 2011 08:34 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 21 mei, 09:57, Luuk <L...@invalid.lan> wrote:
> On 21-05-2011 00:52, Co wrote:
>
>
>
>
>
>
>
>
>
>> On 21 mei, 00:24, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>> On 5/20/2011 5:00 PM, Co wrote:
>
>>>> I get a "1" as result.
>>>> Don't know what you mean with this.
>>>> Problem is that the date is set to 00-00-0000.
>>>> Is that because there is a default set in the field (00-00-0000)?
>
>>>> Marco
>
>>> As a result for what? There's no thread here.
>
>>> Please use REPLY to a message, not start a new thread. And quote the
>>> appropriate parts of the message, to maintain continuity.
>
>>> --
>>> ==================
>>> Remove the "x" from my email address
>>> Jerry Stuckle
>>> JDS Computer Training Corp.
>>> jstuck...@attglobal.net
>>> ==================
>
>> Luuks thought:
>> print $sql;
>
>> it returns 1, dont know what I should do with it.
>> Problem is that if I only change one of the dates:
>> arrival_date='$arrival_date',departure_date='$departure_date'
>
>> the other one gets to be the default value 00-00-0000.
>
>> Marco
>
> Ok, i responded in the other thread, but wanted to 'add' this:
>
> 09:53:29 root@test[14]mysql> insert into testDate values ('21-05-2011');
> Query OK, 1 row affected, 1 warning (0.00 sec)
>
> 09:55:46 root@test[15]mysql> select * from testDate;
> +------------+
> | SepDate |
> +------------+
> | 0000-00-00 |
> | 2011-05-21 |
> | 0000-00-00 |
> +------------+
> 3 rows in set (0.00 sec)
>
> --
> Luuk
Luuk,
forgive me but an I a newbie.
Where do I need to add quotes?
And what does your tests say?
Marco
|
|
|
|
| Re: problem saving date fields [message #174087 is a reply to message #174086] |
Sat, 21 May 2011 09:29 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21-05-2011 10:34, Co wrote:
> On 21 mei, 09:57, Luuk <L...@invalid.lan> wrote:
>> On 21-05-2011 00:52, Co wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 21 mei, 00:24, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> On 5/20/2011 5:00 PM, Co wrote:
>>
>>>> > I get a "1" as result.
>>>> > Don't know what you mean with this.
>>>> > Problem is that the date is set to 00-00-0000.
>>>> > Is that because there is a default set in the field (00-00-0000)?
>>
>>>> > Marco
>>
>>>> As a result for what? There's no thread here.
>>
>>>> Please use REPLY to a message, not start a new thread. And quote the
>>>> appropriate parts of the message, to maintain continuity.
>>
>>>> --
>>>> ==================
>>>> Remove the "x" from my email address
>>>> Jerry Stuckle
>>>> JDS Computer Training Corp.
>>>> jstuck...@attglobal.net
>>>> ==================
>>
>>> Luuks thought:
>>> print $sql;
>>
>>> it returns 1, dont know what I should do with it.
>>> Problem is that if I only change one of the dates:
>>> arrival_date='$arrival_date',departure_date='$departure_date'
>>
>>> the other one gets to be the default value 00-00-0000.
>>
>>> Marco
>>
>> Ok, i responded in the other thread, but wanted to 'add' this:
>>
>> 09:53:29 root@test[14]mysql> insert into testDate values ('21-05-2011');
>> Query OK, 1 row affected, 1 warning (0.00 sec)
>>
>> 09:55:46 root@test[15]mysql> select * from testDate;
>> +------------+
>> | SepDate |
>> +------------+
>> | 0000-00-00 |
>> | 2011-05-21 |
>> | 0000-00-00 |
>> +------------+
>> 3 rows in set (0.00 sec)
>>
>> --
>> Luuk
>
> Luuk,
>
> forgive me but an I a newbie.
> Where do I need to add quotes?
> And what does your tests say?
>
> Marco
Sorry, two seconds after my post i did see you gave quotes around the
dates.
Only help i can give if you copy paste the output of print $sql here.
If that gives "0000-00-00" (or another wrong date) than something is
wrong in a piece of code you did not show here.....
--
Luuk
|
|
|
|
| Re: problem saving date fields [message #174092 is a reply to message #174087] |
Sat, 21 May 2011 12:12 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 21 mei, 11:29, Luuk <L...@invalid.lan> wrote:
> On 21-05-2011 10:34, Co wrote:
>
>
>
>
>
>
>
>
>
>> On 21 mei, 09:57, Luuk <L...@invalid.lan> wrote:
>>> On 21-05-2011 00:52, Co wrote:
>
>>>> On 21 mei, 00:24, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> > On 5/20/2011 5:00 PM, Co wrote:
>
>>>> >> I get a "1" as result.
>>>> >> Don't know what you mean with this.
>>>> >> Problem is that the date is set to 00-00-0000.
>>>> >> Is that because there is a default set in the field (00-00-0000)?
>
>>>> >> Marco
>
>>>> > As a result for what? There's no thread here.
>
>>>> > Please use REPLY to a message, not start a new thread. And quote the
>>>> > appropriate parts of the message, to maintain continuity.
>
>>>> > --
>>>> > ==================
>>>> > Remove the "x" from my email address
>>>> > Jerry Stuckle
>>>> > JDS Computer Training Corp.
>>>> > jstuck...@attglobal.net
>>>> > ==================
>
>>>> Luuks thought:
>>>> print $sql;
>
>>>> it returns 1, dont know what I should do with it.
>>>> Problem is that if I only change one of the dates:
>>>> arrival_date='$arrival_date',departure_date='$departure_date'
>
>>>> the other one gets to be the default value 00-00-0000.
>
>>>> Marco
>
>>> Ok, i responded in the other thread, but wanted to 'add' this:
>
>>> 09:53:29 root@test[14]mysql> insert into testDate values ('21-05-2011');
>>> Query OK, 1 row affected, 1 warning (0.00 sec)
>
>>> 09:55:46 root@test[15]mysql> select * from testDate;
>>> +------------+
>>> | SepDate |
>>> +------------+
>>> | 0000-00-00 |
>>> | 2011-05-21 |
>>> | 0000-00-00 |
>>> +------------+
>>> 3 rows in set (0.00 sec)
>
>>> --
>>> Luuk
>
>> Luuk,
>
>> forgive me but an I a newbie.
>> Where do I need to add quotes?
>> And what does your tests say?
>
>> Marco
>
> Sorry, two seconds after my post i did see you gave quotes around the
> dates.
>
> Only help i can give if you copy paste the output of print $sql here.
> If that gives "0000-00-00" (or another wrong date) than something is
> wrong in a piece of code you did not show here.....
>
> --
> Luuk
Luuk,
Here is all the relevant code:
$birthday_day = "";
$birthday_month = "";
$birthday_year = "";
$arrival_day = "";
$arrival_month = "";
$arrival_year = "";
$departure_day = "";
$departure_month = "";
$departure_year = "";
if ($_POST['parse_var'] == "location"){
$firstname = preg_replace('#[^A-Za-z]#i', '',
$_POST['firstname']); // filter everything but desired characters
$lastname = preg_replace('#[^A-Za-z]#i', '', $_POST['lastname']); //
filter everything but desired characters
$gender = $_POST['gender'];
$country = strip_tags($_POST['country']);
$country = str_replace("'", "'", $country);
$country = str_replace("`", "'", $country);
$country = mysql_real_escape_string($country);
$partner = $_POST['partner'];
$rank = $_POST['rank'];
$service = $_POST['service'];
$position = $_POST['position'];
$arrival_month = preg_replace('#[^0-9]#i', '',
$_POST['arrival_month']);
print $arrival_month;
$arrival_day = preg_replace('#[^0-9]#i', '',
$_POST['arrival_day']); // filter everything but numbers
$arrival_year = preg_replace('#[^0-9]#i', '',
$_POST['arrival_year']); // filter everything but numbers
$arrival_date = "$arrival_year-$arrival_month-$arrival_day";
$departure_month = preg_replace('#[^0-9]#i', '',
$_POST['departure_month']);
print $departure_month;
$departure_day = preg_replace('#[^0-9]#i', '',
$_POST['departure_day']); // filter everything but numbers
$departure_year = preg_replace('#[^0-9]#i', '',
$_POST['departure_year']); //
$departure_date = "$departure_year-$departure_month-$departure_day";
$birthday_month = preg_replace('#[^0-9]#i', '',
$_POST['birthday_month']);
$birthday_day = preg_replace('#[^0-9]#i', '',
$_POST['birthday_day']); // filter everything but numbers
$birthday_year = preg_replace('#[^0-9]#i', '',
$_POST['birthday_year']); // filter everything but numbers
$birthday_date = "$birthday_year-$birthday_month-$birthday_day";
$sqlUpdate = mysql_query("UPDATE myMembers SET
firstname='$firstname', lastname='$lastname', gender='$gender',
partner='$partner', country='$country', rank='$rank',
service='$service', position='$position', birthday='$birthday_date',
arrival_date='$arrival_date',departure_date='$departure_date' WHERE
id='$id' LIMIT 1");
if ($sqlUpdate){
$success_msg = '<img src="images/round_success.png" width="20"
height="20" alt="Success" />Personal information has been updated
successfully.';
} else {
$error_msg = '<img src="images/round_error.png" width="20"
height="20" alt="Failure" /> ERROR: Problems arose during the
information exchange, please try again later.</font>';
}
}
$sql_default = mysql_query("SELECT * FROM myMembers WHERE id='$id'");
while($row = mysql_fetch_array($sql_default)){
$firstname = $row["firstname"];
$lastname = $row["lastname"];
$gender = $row["gender"];
$country = $row["country"];
$rank = $row["rank"];
$partner = $row["partner"];
$service = $row["service"];
$position = $row["position"];
$birthday_date = explode("-",$row["birthday"]);
$birthday_year = $birthday_date[0];
$birthday_day = $birthday_date[2];
$birthday_month = date( 'F', mktime(0, 0, 0, $birthday_date[1]) );
$arrival_date = explode("-",$row["arrival_date"]);
$arrival_year = $arrival_date[0];
$arrival_day = $arrival_date[2];
$arrival_month = date( 'F', mktime(0, 0, 0, $arrival_date[1]) );
$departure_date = explode("-",$row["departure_date"]);
$departure_year = $departure_date[0];
$departure_day = $departure_date[2];
$departure_month = date( 'F', mktime(0, 0, 0,
$departure_date[1]) );
$email = $row["email"];
$email_work = $row["email_work"];
$mobile_phone = $row["mobile_phone"];
$office_phone = $row["office_phone"];
$office_fax = $row["office_fax"];
$home_address = $row["home_address"];
$residence = $row["residence"];
$host = $row["host"];
$bio_body = $row["bio_body"];
$bio_body = str_replace("<br />", "", $bio_body);
$bio_body = stripslashes($bio_body);
$website = $row["website"];
$youtube = $row["youtube"];
$facebook = $row["facebook"];
$twitter = $row["twitter"];
/////// Mechanism to Display Pic. See if they have uploaded a pic or
not //////////////////////////
$check_pic = "members/$id/image01.jpg";
if ($gender != "f") {
$default_pic = "members/0/image01.jpg";
} else {
$default_pic = "members/0/image02.jpg";
}
if (file_exists($check_pic)) {
$user_pic = "<img src=\"$check_pic?$cacheBuster\" width=\"50px\" /
> "; // forces picture to be 100px wide and no more
} else {
$user_pic = "<img src=\"$default_pic\" width=\"50px\" />"; // forces
default picture to be 100px wide and no more
}
} // close while loop
<table width="100%" border="0" align="center">
<tr>
<td width="34%"><strong>Date of Arrival</strong></td>
<td width="33%"><strong>Date of Departure</strong></
td>
<td width="33%"><strong>Birthday</strong></td>
</tr>
</table>
<table width="100%" border="0" align="center">
<tr>
<td width="34%">
<select name="arrival_day" class="formFields" id="arrival_day">
<option value="<?php print "$arrival_day"; ?>"><?php print
"$arrival_day"; ?></option>
<option value="01">1</option>
<option value="02">2</option>
<option value="03">3</option>
<option value="04">4</option>
<option value="05">5</option>
<option value="06">6</option>
<option value="07">7</option>
<option value="08">8</option>
<option value="09">9</option>
<option value="10">10</option>
<option value="11">11</option>
<option value="12">12</option>
<option value="13">13</option>
<option value="14">14</option>
<option value="15">15</option>
<option value="16">16</option>
<option value="17">17</option>
<option value="18">18</option>
<option value="19">19</option>
<option value="20">20</option>
<option value="21">21</option>
<option value="22">22</option>
<option value="23">23</option>
<option value="24">24</option>
<option value="25">25</option>
<option value="26">26</option>
<option value="27">27</option>
<option value="28">28</option>
<option value="29">29</option>
<option value="30">30</option>
<option value="31">31</option>
</select>
<select name="arrival_month" class="formFields" id="arrival_month">
<option value="<?php print "$arrival_month"; ?>"><?php print
"$arrival_month"; ?></option>
<option value="01">January</option>
<option value="02">February</option>
<option value="03">March</option>
<option value="04">April</option>
<option value="05">May</option>
<option value="06">June</option>
<option value="07">July</option>
<option value="08">August</option>
<option value="09">September</option>
<option value="10">October</option>
<option value="11">November</option>
<option value="12">December</option>
</select>
<select name="arrival_year" class="formFields" id="arrival_year">
<option value="<?php print "$arrival_year"; ?>"><?php print
"$arrival_year"; ?></option>
<option value="2011">2013</option>
<option value="2011">2012</option>
<option value="2011">2011</option>
<option value="2010">2010</option>
<option value="2009">2009</option>
<option value="2008">2008</option>
<option value="2007">2007</option>
<option value="2006">2006</option>
<option value="2005">2005</option>
<option value="2004">2004</option>
<option value="2003">2003</option>
<option value="2002">2002</option>
<option value="2001">2001</option>
<option value="2000">2000</option>
</select> </td>
<td width="33%">
<select name="departure_day" class="formFields" id="departure_day">
<option value="<?php print "$departure_day"; ?>"><?php print
"$departure_day"; ?></option>
<option value="01">1</option>
<option value="02">2</option>
<option value="03">3</option>
<option value="04">4</option>
<option value="05">5</option>
<option value="06">6</option>
<option value="07">7</option>
<option value="08">8</option>
<option value="09">9</option>
<option value="10">10</option>
<option value="11">11</option>
<option value="12">12</option>
<option value="13">13</option>
<option value="14">14</option>
<option value="15">15</option>
<option value="16">16</option>
<option value="17">17</option>
<option value="18">18</option>
<option value="19">19</option>
<option value="20">20</option>
<option value="21">21</option>
<option value="22">22</option>
<option value="23">23</option>
<option value="24">24</option>
<option value="25">25</option>
<option value="26">26</option>
<option value="27">27</option>
<option value="28">28</option>
<option value="29">29</option>
<option value="30">30</option>
<option value="31">31</option>
</select>
<select name="departure_month" class="formFields"
id="departure_month">
<option value="<?php print "$departure_month"; ?>"><?php print
"$departure_month"; ?></option>
<option value="01">January</option>
<option value="02">February</option>
<option value="03">March</option>
<option value="04">April</option>
<option value="05">May</option>
<option value="06">June</option>
<option value="07">July</option>
<option value="08">August</option>
<option value="09">September</option>
<option value="10">October</option>
<option value="11">November</option>
<option value="12">December</option>
</select>
<select name="departure_year" class="formFields" id="departure_year">
<option value="<?php print "$departure_year"; ?>"><?php print
"$departure_year"; ?></option>
<option value="2011">2015</option>
<option value="2011">2014</option>
<option value="2011">2013</option>
<option value="2011">2012</option>
<option value="2011">2011</option>
<option value="2010">2010</option>
<option value="2009">2009</option>
<option value="2008">2008</option>
<option value="2007">2007</option>
<option value="2006">2006</option>
<option value="2005">2005</option>
<option value="2004">2004</option>
<option value="2003">2003</option>
<option value="2002">2002</option>
<option value="2001">2001</option>
<option value="2000">2000</option>
</select> </td>
<td width="33%"><select name="birthday_day"
class="formFields" id="birthday_day">
<option value="<?php print "$birthday_day"; ?>"><?php print
"$birthday_day"; ?></option>
<option value="01">1</option>
<option value="02">2</option>
<option value="03">3</option>
<option value="04">4</option>
<option value="05">5</option>
<option value="06">6</option>
<option value="07">7</option>
<option value="08">8</option>
<option value="09">9</option>
<option value="10">10</option>
<option value="11">11</option>
<option value="12">12</option>
<option value="13">13</option>
<option value="14">14</option>
<option value="15">15</option>
<option value="16">16</option>
<option value="17">17</option>
<option value="18">18</option>
<option value="19">19</option>
<option value="20">20</option>
<option value="21">21</option>
<option value="22">22</option>
<option value="23">23</option>
<option value="24">24</option>
<option value="25">25</option>
<option value="26">26</option>
<option value="27">27</option>
<option value="28">28</option>
<option value="29">29</option>
<option value="30">30</option>
<option value="31">31</option>
</select>
<select name="birthday_month" class="formFields" id="birthday_month">
<option value="<?php print "$birthday_month"; ?>"><?php print
"$birthday_month"; ?></option>
<option value="01">January</option>
<option value="02">February</option>
<option value="03">March</option>
<option value="04">April</option>
<option value="05">May</option>
<option value="06">June</option>
<option value="07">July</option>
<option value="08">August</option>
<option value="09">September</option>
<option value="10">October</option>
<option value="11">November</option>
<option value="12">December</option>
</select>
<select name="birthday_year" class="formFields" id="birthday_year">
<option value="<?php print "$birthday_year"; ?>"><?php print
"$birthday_year"; ?></option>
<option value="2011">2013</option>
<option value="2011">2012</option>
<option value="2011">2011</option>
<option value="2010">2010</option>
<option value="2009">2009</option>
<option value="2008">2008</option>
<option value="2007">2007</option>
<option value="2006">2006</option>
<option value="2005">2005</option>
<option value="2004">2004</option>
<option value="2003">2003</option>
<option value="2002">2002</option>
<option value="2001">2001</option>
<option value="2000">2000</option>
<option value="1999">1999</option>
<option value="1998">1998</option>
<option value="1997">1997</option>
<option value="1996">1996</option>
<option value="1995">1995</option>
<option value="1994">1994</option>
<option value="1993">1993</option>
<option value="1992">1992</option>
<option value="1991">1991</option>
<option value="1990">1990</option>
<option value="1989">1989</option>
<option value="1988">1988</option>
<option value="1987">1987</option>
<option value="1986">1986</option>
<option value="1985">1985</option>
<option value="1984">1984</option>
<option value="1983">1983</option>
<option value="1982">1982</option>
<option value="1981">1981</option>
<option value="1980">1980</option>
<option value="1979">1979</option>
<option value="1978">1978</option>
<option value="1977">1977</option>
<option value="1976">1976</option>
<option value="1975">1975</option>
<option value="1974">1974</option>
<option value="1973">1973</option>
<option value="1972">1972</option>
<option value="1971">1971</option>
<option value="1970">1970</option>
<option value="1969">1969</option>
<option value="1968">1968</option>
<option value="1967">1967</option>
<option value="1966">1966</option>
<option value="1965">1965</option>
<option value="1964">1964</option>
<option value="1963">1963</option>
<option value="1962">1962</option>
<option value="1961">1961</option>
<option value="1960">1960</option>
<option value="1959">1959</option>
<option value="1958">1958</option>
<option value="1957">1957</option>
<option value="1956">1956</option>
<option value="1955">1955</option>
<option value="1954">1954</option>
<option value="1953">1953</option>
<option value="1952">1952</option>
<option value="1951">1951</option>
<option value="1950">1950</option>
</select> </td>
</tr>
</table>
<table width="100%" border="0" align="center">
<tr>
<td width="34%"><strong>Partner</strong></td>
<td width="33%"><strong> </strong></td>
<td width="33%"><strong> </strong></td>
</tr>
</table>
<table width="100%" border="0" align="center">
<tr>
<td width="34%">
Sorry for the length
Marco
|
|
|
|
| Re: problem saving date fields [message #174096 is a reply to message #174092] |
Sat, 21 May 2011 13:46 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21-05-2011 14:12, Co wrote:
> <option value="01">1</option>
.....
> <option value="31">31</option>
> Sorry for the length
> Marco
;)
replace it with:
<?php
for ($x=0; $x<=31; $x++) {
printf('<option value="%02d">>%02d</option>', $x, $x);
} ?>
--
Luuk
|
|
|
|
| Re: problem saving date fields [message #174097 is a reply to message #174096] |
Sat, 21 May 2011 14:02 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21-05-2011 15:46, Luuk wrote:
> On 21-05-2011 14:12, Co wrote:
>> <option value="01">1</option>
> ....
>> <option value="31">31</option>
>
>
>> Sorry for the length
>> Marco
>
> ;)
>
> replace it with:
> <?php
> for ($x=0; $x<=31; $x++) {
> printf('<option value="%02d">>%02d</option>', $x, $x);
> } ?>
>
oops, you need to select some option:
<?php
$day=21;
for ($x=0; $x<=31; $x++) {
printf('<option value="%02d" ', $x);
if ($x==$day) { print ' selected="yes"'; }
printf('>%02d</option>', $x);
} ?>
--
Luuk
|
|
|
|
| Re: problem saving date fields [message #174098 is a reply to message #174096] |
Sat, 21 May 2011 14:09 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 21 mei, 15:46, Luuk <L...@invalid.lan> wrote:
> On 21-05-2011 14:12, Co wrote:
>
>> <option value="01">1</option>
> ....
>> <option value="31">31</option>
>> Sorry for the length
>> Marco
>
> ;)
>
> replace it with:
> <?php
> for ($x=0; $x<=31; $x++) {
> printf('<option value="%02d">>%02d</option>', $x, $x);
>
> } ?>
>
> --
> Luuk
Thanks Luuk
one small typo:
for ($x=0; $x<=31; $x++) {
printf('<option value="%02d">%02d</option>', $x, $x);
would it be possible to have the numbers 1 till 9 have without leading
0?
Marco
|
|
|
|
| Re: problem saving date fields [message #174099 is a reply to message #174079] |
Sat, 21 May 2011 14:32 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/20/2011 11:13 PM, Jeff North wrote:
<Several pieces of unrelated items snipped>
> On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
> <jstucklex(at)attglobal(dot)net>
> <ir78cp$53s$1(at)dont-email(dot)me> wrote:
>
>> |>
>> |> How are you setting the $arrival_* and $depature_* values?
>> |
>> | From the input - after is is sent from his form.
>
> Therefore the variables aren't initialised and would cause php errors
> - right?
>
Not if he's programmed correctly and is not using them. There is no
need to initialize variables which are not being used.
>> |> If this is a new entry then all of the $arrival_* and $depature_* will
>> |> be null or zero - therefore the select options will not be
>> |> automatically selected (View Source of the page to see if there are
>> |> any error messages within these lists).
>> |
>> | No, because he isn't setting them until after the form has been
>> | displayed and the user has made his selection.
>
> Methinks you are making too many assumptions - have you seen the full
> source code of the page?
>
No, but I've seen enough to understand what he's doing.
>
> Who said anything about "add a row every time the page is displayed".
> According to your criteria there would never be any edit pages - only
> add pages.
>
> If editing an existing item wouldn't you want to read the already
> stored data from the database?
>
That's what it looked like you were trying to say.
> i.e.
> // initialise variables to meaningful values
> // if editing an existing entry
> // read record
> // overwrite initialised variables
> // display the page
>
Completely unnecessary to initialize values which are not used.
>> |
>> | He needs to do other validation on the data also, but first he needs to
>> | get this part working.
>
> ...and how do you know this, hmmmm?
>
Because I see the code he's using.
>> |>> | $sqlUpdate = mysql_query("UPDATE myMembers SET
>> |>> | firstname='$firstname', lastname='$lastname', gender='$gender',
>> |>> | partner='$partner', country='$country', rank='$rank',
>> |>> | service='$service', position='$position',
>> |>> | arrival_date='$arrival_date',departure_date='$departure_date' WHERE
>> |>> | id='$id' LIMIT 1");
>> |>> |
>> |>> | Is there a reason why this happens? I do create the right format to
>> |>> | put the data back in the table.
>> |>
>> |> But are the values your setting the ones you expect?
>> |
>> | That's why the suggestion to print the SQL statement he generated.
>
> The SQL statement should be ok - it's the "When I change of them the
> other one gets set back to default: 00-00-0000" I'm considering.
>
The SQL statement is NOT ok. As he would find if he printed it out as
was suggested.
>> | BTW - your sig separator is broken. It needs to be exactly
>> | hyphen-hyphen-space-newline.
>
> Oh Jerry is now the sig line cop :-P
> Complain to the writers of Thunderbird as I couldn't care less about
> whether or not my sig appears 'correctly' in your news reader.
> -- -------------------------------------------------
> The supplied code is for guideline purposes only.
It has nothing to do with Thunderbird. It has EVERYTHING to do with
following usenet standards, in this case RFC 3736.
But I see you're as clueless about rfcs as you are programming.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174100 is a reply to message #174098] |
Sat, 21 May 2011 14:34 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21-05-2011 16:09, Co wrote:
> On 21 mei, 15:46, Luuk <L...@invalid.lan> wrote:
>> On 21-05-2011 14:12, Co wrote:
>>
>>> <option value="01">1</option>
>> ....
>>> <option value="31">31</option>
>>> Sorry for the length
>>> Marco
>>
>> ;)
>>
>> replace it with:
>> <?php
>> for ($x=0; $x<=31; $x++) {
>> printf('<option value="%02d">>%02d</option>', $x, $x);
>>
>> } ?>
>>
>> --
>> Luuk
>
> Thanks Luuk
>
> one small typo:
> for ($x=0; $x<=31; $x++) {
> printf('<option value="%02d">%02d</option>', $x, $x);
>
> would it be possible to have the numbers 1 till 9 have without leading
> 0?
>
> Marco
sure, look at http://nl2.php.net/printf
than you will find the answer is to leave out the '0' after the '%'
printf('<option value="%2d">%2d</option>', $x, $x);
or, if you dont want these leading '0' you could also simply use print,
and not printf()....
--
Luuk
|
|
|
|
| Re: problem saving date fields [message #174101 is a reply to message #174081] |
Sat, 21 May 2011 14:37 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/21/2011 3:18 AM, Co wrote:
> On 21 mei, 08:47, Co<vonclausow...@gmail.com> wrote:
>>
>> Did some testing with the print command.
>> When I update the dates these are the results.
>>
>> when I change departure:
>> arrival 2009-0120 departure 11-07-01
>>
>> when I change arrival:
>> arrival 2009-07-01 departure 2011-01
>>
>> it doesn't make any sense to me.
>>
>> Marco
>
> After some more testing I figured out that the month value of the date
> which is not
> updated makes the date go corrupt (set to default). So someone the
> month value doesn't get read
> well from the $_POST['departure_month'].
>
> Any thoughts.
>
> MArco
What's in your $_POST array?
print_var($_POST);
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174102 is a reply to message #174101] |
Sat, 21 May 2011 15:07 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 21 mei, 16:37, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> On 5/21/2011 3:18 AM, Co wrote:
>
>
>
>
>
>
>
>
>
>> On 21 mei, 08:47, Co<vonclausow...@gmail.com> wrote:
>
>>> Did some testing with the print command.
>>> When I update the dates these are the results.
>
>>> when I change departure:
>>> arrival 2009-0120 departure 11-07-01
>
>>> when I change arrival:
>>> arrival 2009-07-01 departure 2011-01
>
>>> it doesn't make any sense to me.
>
>>> Marco
>
>> After some more testing I figured out that the month value of the date
>> which is not
>> updated makes the date go corrupt (set to default). So someone the
>> month value doesn't get read
>> well from the $_POST['departure_month'].
>
>> Any thoughts.
>
>> MArco
>
> What's in your $_POST array?
>
> print_var($_POST);
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================
Well basically when I change one of the dates; the one changed is
fine.
The other one untouched will only return the day and the year.
Something like this: 122009.
This doesn't happen when I change any other field; leaving the dates
unchanged.
Marco
|
|
|
|
| Re: problem saving date fields [message #174103 is a reply to message #174099] |
Sat, 21 May 2011 16:08 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php Jerry Stuckle
<jstucklex(at)attglobal(dot)net>
<ir8idn$ojm$1(at)dont-email(dot)me> wrote:
> | On 5/20/2011 11:13 PM, Jeff North wrote:
> |
> | <Several pieces of unrelated items snipped>
> |
> | > On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
> | > <jstucklex(at)attglobal(dot)net>
> | > <ir78cp$53s$1(at)dont-email(dot)me> wrote:
> | >
> | >> |>
> | >> |> How are you setting the $arrival_* and $depature_* values?
> | >> |
> | >> | From the input - after is is sent from his form.
> | >
> | > Therefore the variables aren't initialised and would cause php errors
> | > - right?
> | >
> |
> | Not if he's programmed correctly
doubtful.
> | and is not using them. There is no
> | need to initialize variables which are not being used.
There is no need to have variables in the code that aren't being used.
> | >> |> If this is a new entry then all of the $arrival_* and $depature_* will
> | >> |> be null or zero - therefore the select options will not be
> | >> |> automatically selected (View Source of the page to see if there are
> | >> |> any error messages within these lists).
> | >> |
> | >> | No, because he isn't setting them until after the form has been
> | >> | displayed and the user has made his selection.
> | >
> | > Methinks you are making too many assumptions - have you seen the full
> | > source code of the page?
> |
> | No, but I've seen enough to understand what he's doing.
> |
> | > Who said anything about "add a row every time the page is displayed".
> | > According to your criteria there would never be any edit pages - only
> | > add pages.
> | >
> | > If editing an existing item wouldn't you want to read the already
> | > stored data from the database?
> |
> | That's what it looked like you were trying to say.
> |
> | > i.e.
> | > // initialise variables to meaningful values
> | > // if editing an existing entry
> | > // read record
> | > // overwrite initialised variables
> | > // display the page
> | >
> |
> | Completely unnecessary to initialize values which are not used.
If you are not using the variables then they shouldn't appear in the
code in the first place - very sloppy programming.
[snip]
> | > The SQL statement should be ok - it's the "When I change of them the
> | > other one gets set back to default: 00-00-0000" I'm considering.
> |
> | The SQL statement is NOT ok. As he would find if he printed it out as
> | was suggested.
If the SQL statement was not ok then the record wouldn't be updated.
> | >> | BTW - your sig separator is broken. It needs to be exactly
> | >> | hyphen-hyphen-space-newline.
> | >
> | > Oh Jerry is now the sig line cop :-P
> | > Complain to the writers of Thunderbird as I couldn't care less about
> | > whether or not my sig appears 'correctly' in your news reader.
> | > -- -------------------------------------------------
> | > The supplied code is for guideline purposes only.
> |
> | It has nothing to do with Thunderbird. It has EVERYTHING to do with
> | following usenet standards, in this case RFC 3736.
Please highlight the line(s) from RFC 3736 that can back up your
claim.
> | But I see you're as clueless about rfcs as you are programming.
-- -------------------------------------------------
The supplied code is for guideline purposes only.
|
|
|
|
| Re: problem saving date fields [message #174106 is a reply to message #174102] |
Sat, 21 May 2011 23:55 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/21/2011 11:07 AM, Co wrote:
> On 21 mei, 16:37, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>> On 5/21/2011 3:18 AM, Co wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 21 mei, 08:47, Co<vonclausow...@gmail.com> wrote:
>>
>>>> Did some testing with the print command.
>>>> When I update the dates these are the results.
>>
>>>> when I change departure:
>>>> arrival 2009-0120 departure 11-07-01
>>
>>>> when I change arrival:
>>>> arrival 2009-07-01 departure 2011-01
>>
>>>> it doesn't make any sense to me.
>>
>>>> Marco
>>
>>> After some more testing I figured out that the month value of the date
>>> which is not
>>> updated makes the date go corrupt (set to default). So someone the
>>> month value doesn't get read
>>> well from the $_POST['departure_month'].
>>
>>> Any thoughts.
>>
>>> MArco
>>
>> What's in your $_POST array?
>>
>> print_var($_POST);
>>
>
> Well basically when I change one of the dates; the one changed is
> fine.
> The other one untouched will only return the day and the year.
> Something like this: 122009.
> This doesn't happen when I change any other field; leaving the dates
> unchanged.
>
> Marco
That doesn't answer my question.
If you want help, you need to answer our questions.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174107 is a reply to message #174103] |
Sun, 22 May 2011 00:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/21/2011 12:08 PM, Jeff North wrote:
> On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php Jerry Stuckle
> <jstucklex(at)attglobal(dot)net>
> <ir8idn$ojm$1(at)dont-email(dot)me> wrote:
>
>> | On 5/20/2011 11:13 PM, Jeff North wrote:
>> |
>> |<Several pieces of unrelated items snipped>
>> |
>> |> On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
>> |> <jstucklex(at)attglobal(dot)net>
>> |> <ir78cp$53s$1(at)dont-email(dot)me> wrote:
>> |>
>> |>> |>
>> |>> |> How are you setting the $arrival_* and $depature_* values?
>> |>> |
>> |>> | From the input - after is is sent from his form.
>> |>
>> |> Therefore the variables aren't initialised and would cause php errors
>> |> - right?
>> |>
>> |
>> | Not if he's programmed correctly
>
> doubtful.
>
But you don't know that.
>> | and is not using them. There is no
>> | need to initialize variables which are not being used.
>
> There is no need to have variables in the code that aren't being used.
>
Yes, there is. In fact, it is quite common to have variables in the
code which are not being use *at this time*. And very good reasons for
*not* initializing them - as a *programmer* would know.
>> |>> |> If this is a new entry then all of the $arrival_* and $depature_* will
>> |>> |> be null or zero - therefore the select options will not be
>> |>> |> automatically selected (View Source of the page to see if there are
>> |>> |> any error messages within these lists).
>> |>> |
>> |>> | No, because he isn't setting them until after the form has been
>> |>> | displayed and the user has made his selection.
>> |>
>> |> Methinks you are making too many assumptions - have you seen the full
>> |> source code of the page?
>> |
>> | No, but I've seen enough to understand what he's doing.
>> |
>> |> Who said anything about "add a row every time the page is displayed".
>> |> According to your criteria there would never be any edit pages - only
>> |> add pages.
>> |>
>> |> If editing an existing item wouldn't you want to read the already
>> |> stored data from the database?
>> |
>> | That's what it looked like you were trying to say.
>> |
>> |> i.e.
>> |> // initialise variables to meaningful values
>> |> // if editing an existing entry
>> |> // read record
>> |> // overwrite initialised variables
>> |> // display the page
>> |>
>> |
>> | Completely unnecessary to initialize values which are not used.
>
> If you are not using the variables then they shouldn't appear in the
> code in the first place - very sloppy programming.
>
Just because the are not being used *at this time* doesn't mean they
shouldn't appear - as a *programmer* would understand.
> [snip]
>
>> |> The SQL statement should be ok - it's the "When I change of them the
>> |> other one gets set back to default: 00-00-0000" I'm considering.
>> |
>> | The SQL statement is NOT ok. As he would find if he printed it out as
>> | was suggested.
>
> If the SQL statement was not ok then the record wouldn't be updated.
>
Or the row (tables have ROWS, not RECORDS) is not being updated with the
correct data - which is the case here. But then a *programmer* would
understand that.
>> |>> | BTW - your sig separator is broken. It needs to be exactly
>> |>> | hyphen-hyphen-space-newline.
>> |>
>> |> Oh Jerry is now the sig line cop :-P
>> |> Complain to the writers of Thunderbird as I couldn't care less about
>> |> whether or not my sig appears 'correctly' in your news reader.
>> |> -- -------------------------------------------------
>> |> The supplied code is for guideline purposes only.
>> |
>> | It has nothing to do with Thunderbird. It has EVERYTHING to do with
>> | following usenet standards, in this case RFC 3736.
>
> Please highlight the line(s) from RFC 3736 that can back up your
> claim.
>
>> | But I see you're as clueless about rfcs as you are programming.
> -- -------------------------------------------------
> The supplied code is for guideline purposes only.
Typo - the rfc is 3676, which you could find if you knew how to do a
simple google search. But that looks to be beyond your capability, also.
There are three types of people who refuse to follow accepted practices:
idiots, trolls and arrogant anal orifices.
Which are you?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174108 is a reply to message #174107] |
Sun, 22 May 2011 00:30 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:ir9jom$663$1(at)dont-email(dot)me,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
> On 5/21/2011 12:08 PM, Jeff North wrote:
>> On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net>
>> <ir8idn$ojm$1(at)dont-email(dot)me> wrote:
>>
>>>> On 5/20/2011 11:13 PM, Jeff North wrote:
>>>>
>>>> <Several pieces of unrelated items snipped>
>>>>
>>>> > On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php
>>>> > Jerry Stuckle <jstucklex(at)attglobal(dot)net>
>>>> > <ir78cp$53s$1(at)dont-email(dot)me> wrote:
>>>> >
>>>> >> |>
>>>> >> |> How are you setting the $arrival_* and
>>>> >> $depature_* values? |
>>>> >> | From the input - after is is sent from his form.
>>>> >
>>>> > Therefore the variables aren't initialised and would
>>>> > cause php errors - right?
>>>> >
>>>>
>>>> Not if he's programmed correctly
>>
>> doubtful.
>>
>
> But you don't know that.
>
>>>> and is not using them. There is no
>>>> need to initialize variables which are not being used.
>>
>> There is no need to have variables in the code that
>> aren't being used.
>
> Yes, there is. In fact, it is quite common to have
> variables in the code which are not being use *at this
> time*. And very good reasons for *not* initializing them
> - as a *programmer* would know.
>>>> >> |> If this is a new entry then all of the
>>>> >> $arrival_* and $depature_* will |> be null or
>>>> >> zero - therefore the select options will not be |> automatically
>>>> >> selected (View Source of the page to
>>>> >> see if there are |> any error messages within
>>>> >> these lists). | | No, because he isn't setting them
>>>> >> until after the form has been | displayed and the
>>>> >> user has made his selection.
>>>> >
>>>> > Methinks you are making too many assumptions - have
>>>> > you seen the full source code of the page?
>>>>
>>>> No, but I've seen enough to understand what he's doing.
>>>>
>>>> > Who said anything about "add a row every time the
>>>> > page is displayed". According to your criteria there
>>>> > would never be any edit pages - only add pages.
>>>> >
>>>> > If editing an existing item wouldn't you want to
>>>> > read the already stored data from the database?
>>>>
>>>> That's what it looked like you were trying to say.
>>>>
>>>> > i.e.
>>>> > // initialise variables to meaningful values
>>>> > // if editing an existing entry
>>>> > // read record
>>>> > // overwrite initialised variables
>>>> > // display the page
>>>> >
>>>>
>>>> Completely unnecessary to initialize values which are
>>>> not used.
>>
>> If you are not using the variables then they shouldn't
>> appear in the code in the first place - very sloppy
>> programming.
>
> Just because the are not being used *at this time*
> doesn't mean they shouldn't appear - as a *programmer*
> would understand.
>> [snip]
>>
>>>> > The SQL statement should be ok - it's the "When I
>>>> > change of them the other one gets set back to
>>>> > default: 00-00-0000" I'm considering.
>>>>
>>>> The SQL statement is NOT ok. As he would find if he
>>>> printed it out as was suggested.
>>
>> If the SQL statement was not ok then the record wouldn't
>> be updated.
>
> Or the row (tables have ROWS, not RECORDS) is not being
> updated with the correct data - which is the case here. But then a
> *programmer* would understand that.
>
>>>> >> | BTW - your sig separator is broken. It needs to
>>>> >> be exactly | hyphen-hyphen-space-newline.
>>>> >
>>>> > Oh Jerry is now the sig line cop :-P
>>>> > Complain to the writers of Thunderbird as I couldn't
>>>> > care less about whether or not my sig appears
>>>> > 'correctly' in your news reader. --
>>>> > -------------------------------------------------
>>>> > The supplied code is for guideline purposes only.
>>>>
>>>> It has nothing to do with Thunderbird. It has
>>>> EVERYTHING to do with following usenet standards, in
>>>> this case RFC 3736.
>>
>> Please highlight the line(s) from RFC 3736 that can back
>> up your claim.
>>
>>>> But I see you're as clueless about rfcs as you are
>>>> programming.
>> -- -------------------------------------------------
>> The supplied code is for guideline purposes only.
>
>
> Typo - the rfc is 3676, which you could find if you knew
> how to do a simple google search. But that looks to be
> beyond your capability, also.
> There are three types of people who refuse to follow
> accepted practices: idiots, trolls and arrogant anal
> orifices.
And mr suckle has just shown you all three! He's like that; a real idiot.
>
> Which are you?
|
|
|
|
| Re: problem saving date fields [message #174110 is a reply to message #174108] |
Sun, 22 May 2011 03:13 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/21/2011 8:30 PM, Twayne wrote:
> And mr suckle has just shown you all three! He's like that; a real idiot.
>
>>
>> Which are you?
>
>
>
Speaking of trolls... the second biggest one in the newsgroup rears his
ugly head again. But don't worry - you have a long ways to go to catch
the greatest one - TNP.
And "mr suckle"? I haven't heard that one since 3rd grade or so. Shows
your maturity level! ROFLAMO!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174112 is a reply to message #174107] |
Sun, 22 May 2011 04:28 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Sat, 21 May 2011 20:01:17 -0400, in comp.lang.php Jerry Stuckle
<jstucklex(at)attglobal(dot)net>
<ir9jom$663$1(at)dont-email(dot)me> wrote:
> | On 5/21/2011 12:08 PM, Jeff North wrote:
> | > On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php Jerry Stuckle
> | > <jstucklex(at)attglobal(dot)net>
> | > <ir8idn$ojm$1(at)dont-email(dot)me> wrote:
> | >
[snip]
> | > There is no need to have variables in the code that aren't being used.
> |
> | Yes, there is. In fact, it is quite common to have variables in the
> | code which are not being use *at this time*. And very good reasons for
> | *not* initializing them - as a *programmer* would know.
Programmers who know more that just PHP know that you are full of
crap.
[snip]
> | >> |> The SQL statement should be ok - it's the "When I change of them the
> | >> |> other one gets set back to default: 00-00-0000" I'm considering.
> | >> |
> | >> | The SQL statement is NOT ok. As he would find if he printed it out as
> | >> | was suggested.
> | >
> | > If the SQL statement was not ok then the record wouldn't be updated.
> |
> | Or the row (tables have ROWS, not RECORDS) is not being updated with the
> | correct data - which is the case here. But then a *programmer* would
> | understand that.
A row, or record, would NOT be updated if the SQL statement is NOT ok
- even a moron like you can understand that - oh you do that is why
you chose to answer the question the way you did.
> | >> |>> | BTW - your sig separator is broken. It needs to be exactly
> | >> |>> | hyphen-hyphen-space-newline.
[snip]
> | >> | It has nothing to do with Thunderbird. It has EVERYTHING to do with
> | >> | following usenet standards, in this case RFC 3736.
> | >
> | > Please highlight the line(s) from RFC 3736 that can back up your
> | > claim.
> | >
> | >> | But I see you're as clueless about rfcs as you are programming.
> | > -- -------------------------------------------------
> | > The supplied code is for guideline purposes only.
> |
> | Typo - the rfc is 3676,
3676 and 3736 is NOT a typo not matter how you try to spin it. If you
are going to speak with the voice of authority then get your facts
correct first.
> | which you could find if you knew how to do a
> | simple google search.
Everyone would know that they needed to search for "The Text/Plain
Format and DelSp Parameters" to get to the relevant information that
you got wrong in the first place - right?
> | But that looks to be beyond your capability, also.
http://www.apps.ietf.org/rfc/rfc3676.html#sec-4.3
"There is a long-standing convention in Usenet news which also
commonly appears in Internet mail of using "-- " as the separator line
between the body and the signature of a message. When generating a
Format=Flowed message containing a Usenet-style separator before the
signature, the separator line is sent as-is."
Now where does it state "It needs to be exactly
hyphen-hyphen-space-newline."
[snip]
-- -----------------------------------------------------------
"Pr0r3p" <pr0r3p(at)yahoo(dot)com> wrote:
I said I was aiming at your stupidity, not your brain.
"Johnny" <wxpprofessional(at)msn(dot)com> writes:
You missed. You can not hit a non-existent thing.
-- -----------------------------------------------------------
|
|
|
|
| Re: problem saving date fields [message #174113 is a reply to message #174112] |
Sun, 22 May 2011 10:45 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jeff North wrote:
[attribution novels trimmed, quotation prefixes fixed, see
<http://learn.to/quote>]
> Jerry Stuckle wrote:
>> On 5/21/2011 12:08 PM, Jeff North wrote:
>>> Jerry Stuckle wrote:
>>> There is no need to have variables in the code that aren't being used.
>> Yes, there is. In fact, it is quite common to have variables in the
>> code which are not being use *at this time*. And very good reasons for
>> *not* initializing them - as a *programmer* would know.
>
> Programmers who know more that just PHP know that you are full of
> crap.
Please name one that is not you in order to substantiate your claim.
Further, please explain what this has to do with Jerry's statement.
>>>> > The SQL statement should be ok - it's the "When I change of them
>>>> > the other one gets set back to default: 00-00-0000" I'm
>>>> > considering.
>>>> The SQL statement is NOT ok. As he would find if he printed it out
>>>> as was suggested.
>>> If the SQL statement was not ok then the record wouldn't be updated.
>> Or the row (tables have ROWS, not RECORDS) is not being updated with the
>> correct data - which is the case here. But then a *programmer* would
>> understand that.
>
> A row, or record, would NOT be updated if the SQL statement is NOT ok
He did not debate that. He offered another possibility: the SQL statement
being syntactically correct but attempting to write different data than were
desired.
> - even a moron like you can understand that - oh you do that is why
> you chose to answer the question the way you did.
So no need for name-calling.
>>>> >> BTW - your sig separator is broken. It needs to be exactly
>>>> >> hyphen-hyphen-space-newline.
>
> [snip]
>
>>>> It has nothing to do with Thunderbird. It has EVERYTHING to do
>>>> with following usenet standards, in this case RFC 3736.
>>>
>>> Please highlight the line(s) from RFC 3736 that can back up your
>>> claim.
>>>
>>>> But I see you're as clueless about rfcs as you are programming.
>>> -- -------------------------------------------------
>>> The supplied code is for guideline purposes only.
>>
>> Typo - the rfc is 3676,
>
> 3676 and 3736 is NOT a typo
You cannot be sure about that. The Free Online Dictionary defines a typo as
follows:
,-<http://www.thefreedictionary.com/typo>
|
| Noun 1. typo - a mistake in printed matter resulting from mechanical
| failures of some kind
| Synonyms: erratum, literal, literal error, misprint, typographical
| error
| Related words: mistake, error - part of a statement that is not
| correct; "the book was full of errors"
|
| Based on WordNet 3.0, Farlex clipart collection. © 2003-2008 Princeton
| University, Farlex Inc.
So it could very well have been a typo, either caused by mechanical keyboard
malfunction or mechanical confusion between the fingers of the (quick)
typist when using the keyboard.
>> which you could find if you knew how to do a simple google search.
>
> Everyone would know that they needed to search for "The Text/Plain
> Format and DelSp Parameters" to get to the relevant information that
> you got wrong in the first place - right?
It was a valid assumption. If you search on Google for "rfc 3736 usenet
signature" you will be presented with a hyperlink to the correct RFC (3676)
at the first position, thanks to Google's implicit error correction.
>> But that looks to be beyond your capability, also.
>
> http://www.apps.ietf.org/rfc/rfc3676.html#sec-4.3
> "There is a long-standing convention in Usenet news which also
> commonly appears in Internet mail of using "-- " as the separator line
> between the body and the signature of a message. When generating a
> Format=Flowed message containing a Usenet-style separator before the
> signature, the separator line is sent as-is."
>
> Now where does it state "It needs to be exactly
> hyphen-hyphen-space-newline."
A separator line needs to be ended with newline (<CR><LF> in Internet
messages, see RFC 5322, section 2.1) in order to separate the line that
precedes it from the line that follows it. The definition of a separator
line includes that no other characters than those stated, in the stated
order, can be part of the line for it to be (recognized as) a separator
line. (A separator is a thing that separates other things from one another,
and a seperator line is a line that is considered a separator.)
So
> [snip]
> -- -----------------------------------------------------------
this is _not_ a signature separator line, and
> "Pr0r3p" <pr0r3p(at)yahoo(dot)com> wrote:
> I said I was aiming at your stupidity, not your brain.
>
> "Johnny" <wxpprofessional(at)msn(dot)com> writes:
> You missed. You can not hit a non-existent thing.
this is is not a properly delimited signature according to RFC 3676 (and
1855). It is also not a proper Usenet signature according to RFC 1855,
for with five lines it exceeds the recommended length of four lines by one.
> -- -----------------------------------------------------------
And this is a rather pointless string of characters because nothing follows
that would be separated from the preceding text.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
| Re: problem saving date fields [message #174116 is a reply to message #174112] |
Sun, 22 May 2011 12:26 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/22/2011 12:28 AM, Jeff North wrote:
> On Sat, 21 May 2011 20:01:17 -0400, in comp.lang.php Jerry Stuckle
> <jstucklex(at)attglobal(dot)net>
> <ir9jom$663$1(at)dont-email(dot)me> wrote:
>
>> | On 5/21/2011 12:08 PM, Jeff North wrote:
>> |> On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php Jerry Stuckle
>> |> <jstucklex(at)attglobal(dot)net>
>> |> <ir8idn$ojm$1(at)dont-email(dot)me> wrote:
>> |>
>
> [snip]
>
>> |> There is no need to have variables in the code that aren't being used.
>> |
>> | Yes, there is. In fact, it is quite common to have variables in the
>> | code which are not being use *at this time*. And very good reasons for
>> | *not* initializing them - as a *programmer* would know.
>
> Programmers who know more that just PHP know that you are full of
> crap.
>
I've probably forgotten more languages than you ever learned - starting
with autocoder.
> [snip]
>
>> |>> |> The SQL statement should be ok - it's the "When I change of them the
>> |>> |> other one gets set back to default: 00-00-0000" I'm considering.
>> |>> |
>> |>> | The SQL statement is NOT ok. As he would find if he printed it out as
>> |>> | was suggested.
>> |>
>> |> If the SQL statement was not ok then the record wouldn't be updated.
>> |
>> | Or the row (tables have ROWS, not RECORDS) is not being updated with the
>> | correct data - which is the case here. But then a *programmer* would
>> | understand that.
>
> A row, or record, would NOT be updated if the SQL statement is NOT ok
> - even a moron like you can understand that - oh you do that is why
> you chose to answer the question the way you did.
>
What an idiot. An incorrect SQL statement can cause the row to be
inserted or updated with incorrect data also, as is the case here.
However, it takes intelligence to understand that, which you obviously
do not have.
>> |>> |>> | BTW - your sig separator is broken. It needs to be exactly
>> |>> |>> | hyphen-hyphen-space-newline.
>
> [snip]
>
>> |>> | It has nothing to do with Thunderbird. It has EVERYTHING to do with
>> |>> | following usenet standards, in this case RFC 3736.
>> |>
>> |> Please highlight the line(s) from RFC 3736 that can back up your
>> |> claim.
>> |>
>> |>> | But I see you're as clueless about rfcs as you are programming.
>> |> -- -------------------------------------------------
>> |> The supplied code is for guideline purposes only.
>> |
>> | Typo - the rfc is 3676,
>
> 3676 and 3736 is NOT a typo not matter how you try to spin it. If you
> are going to speak with the voice of authority then get your facts
> correct first.
>
OK, now we know you are a troll and an anal orifice.
>> | which you could find if you knew how to do a
>> | simple google search.
>
> Everyone would know that they needed to search for "The Text/Plain
> Format and DelSp Parameters" to get to the relevant information that
> you got wrong in the first place - right?
>
Ditto.
>> | But that looks to be beyond your capability, also.
>
> http://www.apps.ietf.org/rfc/rfc3676.html#sec-4.3
> "There is a long-standing convention in Usenet news which also
> commonly appears in Internet mail of using "-- " as the separator line
> between the body and the signature of a message. When generating a
> Format=Flowed message containing a Usenet-style separator before the
> signature, the separator line is sent as-is."
>
Which RFC is that?
> Now where does it state "It needs to be exactly
> hyphen-hyphen-space-newline."
>
In the RFC. But you can't read either, so we also know you are an idiot.
> [snip]
> -- -----------------------------------------------------------
> "Pr0r3p"<pr0r3p(at)yahoo(dot)com> wrote:
> I said I was aiming at your stupidity, not your brain.
>
> "Johnny"<wxpprofessional(at)msn(dot)com> writes:
> You missed. You can not hit a non-existent thing.
> -- -----------------------------------------------------------
So, in one post you've proven you are all three. Good job - even
"Pointed Head" hasn't managed that.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174118 is a reply to message #174112] |
Sun, 22 May 2011 13:11 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:7otgt6963n7tt7ns1of8ug7d5uf0ne641d(at)4ax(dot)com,
Jeff North <jnorthau(at)yahoo(dot)com(dot)au> typed:
> On Sat, 21 May 2011 20:01:17 -0400, in comp.lang.php
> Jerry Stuckle <jstucklex(at)attglobal(dot)net>
> <ir9jom$663$1(at)dont-email(dot)me> wrote:
>
>>> On 5/21/2011 12:08 PM, Jeff North wrote:
>>>> On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php
>>>> Jerry Stuckle <jstucklex(at)attglobal(dot)net>
>>>> <ir8idn$ojm$1(at)dont-email(dot)me> wrote:
>>>>
>
> [snip]
>
>>>> There is no need to have variables in the code that
>>>> aren't being used.
>>>
>>> Yes, there is. In fact, it is quite common to have
>>> variables in the code which are not being use *at this
>>> time*. And very good reasons for *not* initializing
>>> them - as a *programmer* would know.
>
> Programmers who know more that just PHP know that you are
> full of crap.
>
> [snip]
>
>>>> >>> The SQL statement should be ok - it's the "When I
>>>> >>> change of them the other one gets set back to
>>>> >>> default: 00-00-0000" I'm considering.
>>>> >>
>>>> >> The SQL statement is NOT ok. As he would find if he
>>>> >> printed it out as was suggested.
>>>>
>>>> If the SQL statement was not ok then the record
>>>> wouldn't be updated.
>>>
>>> Or the row (tables have ROWS, not RECORDS) is not being
>>> updated with the correct data - which is the case here.
>>> But then a *programmer* would understand that.
>
> A row, or record, would NOT be updated if the SQL
> statement is NOT ok - even a moron like you can
> understand that - oh you do that is why you chose to
> answer the question the way you did.
>
>>>> >>>> | BTW - your sig separator is broken. It needs
>>>> >>>> to be exactly | hyphen-hyphen-space-newline.
>
> [snip]
>
>>>> >> It has nothing to do with Thunderbird. It has
>>>> >> EVERYTHING to do with following usenet standards, in
>>>> >> this case RFC 3736.
>>>>
>>>> Please highlight the line(s) from RFC 3736 that can
>>>> back up your claim.
>>>>
>>>> >> But I see you're as clueless about rfcs as you are
>>>> >> programming.
>>>> -- -------------------------------------------------
>>>> The supplied code is for guideline purposes only.
>>>
>>> Typo - the rfc is 3676,
>
> 3676 and 3736 is NOT a typo not matter how you try to
> spin it. If you are going to speak with the voice of
> authority then get your facts correct first.
>
>>> which you could find if you knew how to do a
>>> simple google search.
>
> Everyone would know that they needed to search for "The
> Text/Plain Format and DelSp Parameters" to get to the
> relevant information that you got wrong in the first
> place - right?
>
>>> But that looks to be beyond your capability, also.
>
> http://www.apps.ietf.org/rfc/rfc3676.html#sec-4.3
> "There is a long-standing convention in Usenet news which
> also commonly appears in Internet mail of using "-- " as
> the separator line between the body and the signature of
> a message. When generating a Format=Flowed message
> containing a Usenet-style separator before the signature,
> the separator line is sent as-is."
>
> Now where does it state "It needs to be exactly
> hyphen-hyphen-space-newline."
>
> [snip]
> --
> -----------------------------------------------------------
> "Pr0r3p" <pr0r3p(at)yahoo(dot)com> wrote:
> I said I was aiming at your stupidity, not your brain.
>
> "Johnny" <wxpprofessional(at)msn(dot)com> writes:
> You missed. You can not hit a non-existent thing.
> --
> -----------------------------------------------------------
I can't tell you which of the netiquette/protocol RFCs contains the
dash-dash-space conventon, but it is included in one of them. For instance,
neither of the two sig delimiters above has the requisite space after it, so
it was not removed in this reply.
Otherwise I agree with you.
HTH,
Twayne`
|
|
|
|
| Re: problem saving date fields [message #174119 is a reply to message #174116] |
Sun, 22 May 2011 13:20 |
Twayne
Messages: 135
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In news:irave9$qdq$1(at)dont-email(dot)me,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> typed:
> On 5/22/2011 12:28 AM, Jeff North wrote:
>> On Sat, 21 May 2011 20:01:17 -0400, in comp.lang.php
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net>
>> <ir9jom$663$1(at)dont-email(dot)me> wrote:
>>
>>>> On 5/21/2011 12:08 PM, Jeff North wrote:
>>>> > On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php
>>>> > Jerry Stuckle <jstucklex(at)attglobal(dot)net>
>>>> > <ir8idn$ojm$1(at)dont-email(dot)me> wrote:
>>>> >
>>
>> [snip]
>>
>>>> > There is no need to have variables in the code that
>>>> > aren't being used.
>>>>
>>>> Yes, there is. In fact, it is quite common to have
>>>> variables in the code which are not being use *at this
>>>> time*. And very good reasons for *not* initializing
>>>> them - as a *programmer* would know.
>>
>> Programmers who know more that just PHP know that you
>> are full of crap.
>>
>
> I've probably forgotten more languages than you ever
> learned - starting with autocoder.
That's irrelevant and means nothing to the OPs query. Who cares what other
languages you know or don't know?
>
>> [snip]
>>
>>>> >> |> The SQL statement should be ok - it's the
>>>> >> "When I change of them the |> other one gets set
>>>> >> back to default: 00-00-0000" I'm considering. |
>>>> >> | The SQL statement is NOT ok. As he would find if
>>>> >> he printed it out as | was suggested.
>>>> >
>>>> > If the SQL statement was not ok then the record
>>>> > wouldn't be updated.
>>>>
>>>> Or the row (tables have ROWS, not RECORDS) is not
>>>> being updated with the correct data - which is the
>>>> case here. But then a *programmer* would understand
>>>> that.
>>
>> A row, or record, would NOT be updated if the SQL
>> statement is NOT ok - even a moron like you can
>> understand that - oh you do that is why you chose to
>> answer the question the way you did.
>
> What an idiot.
Yes, you are, suckle.
An incorrect SQL statement can cause the
> row to be inserted or updated with incorrect data also,
> as is the case here.
> However, it takes intelligence to understand that, which
> you obviously do not have.
Too bad that's not the only thing you're lacking! Your rants can only be
described as stupid and irrelevant. Have you EVER actually helped anyone? I
know I seldom read your posts unless I have the time for a bit of
entertainment by a powerless, groping idiot.
>
>>>> >> |>> | BTW - your sig separator is broken. It
>>>> >> needs to be exactly |>> |
>>>> >> hyphen-hyphen-space-newline.
>>
>> [snip]
>>
>>>> >> | It has nothing to do with Thunderbird. It has
>>>> >> EVERYTHING to do with | following usenet standards,
>>>> >> in this case RFC 3736.
>>>> >
>>>> > Please highlight the line(s) from RFC 3736 that can
>>>> > back up your claim.
>>>> >
>>>> >> | But I see you're as clueless about rfcs as you
>>>> >> are programming.
>>>> > -- -------------------------------------------------
>>>> > The supplied code is for guideline purposes only.
>>>>
>>>> Typo - the rfc is 3676,
>>
>> 3676 and 3736 is NOT a typo not matter how you try to
>> spin it. If you are going to speak with the voice of
>> authority then get your facts correct first.
>>
>
> OK, now we know you are a troll and an anal orifice.
>
>>>> which you could find if you knew how to do a
>>>> simple google search.
>>
>> Everyone would know that they needed to search for "The
>> Text/Plain Format and DelSp Parameters" to get to the
>> relevant information that you got wrong in the first
>> place - right?
>
> Ditto.
>
>>>> But that looks to be beyond your capability, also.
>>
>> http://www.apps.ietf.org/rfc/rfc3676.html#sec-4.3
>> "There is a long-standing convention in Usenet news
>> which also commonly appears in Internet mail of using
>> "-- " as the separator line between the body and the
>> signature of a message. When generating a Format=Flowed
>> message containing a Usenet-style separator before the
>> signature, the separator line is sent as-is."
>
> Which RFC is that?
>
>
>> Now where does it state "It needs to be exactly
>> hyphen-hyphen-space-newline."
>>
>
> In the RFC. But you can't read either, so we also know
> you are an idiot.
Maybe blatherskite and a total lack of interpersonal skills are better
descrips for suckie; and apparently it hurts his feelings to be called on
it. One must never let a usenet post bug them.
>
>> [snip]
>> --
>> -----------------------------------------------------------
>> "Pr0r3p"<pr0r3p(at)yahoo(dot)com> wrote: I said I was aiming at your stupidity,
>> not your brain.
>>
>> "Johnny"<wxpprofessional(at)msn(dot)com> writes:
>> You missed. You can not hit a non-existent thing.
>> --
>> -----------------------------------------------------------
>
> So, in one post you've proven you are all three. Good
> job - even "Pointed Head" hasn't managed that.
|
|
|
|
| Re: problem saving date fields [message #174121 is a reply to message #174116] |
Sun, 22 May 2011 14:08 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Sun, 22 May 2011 08:26:48 -0400, in comp.lang.php Jerry Stuckle
<jstucklex(at)attglobal(dot)net>
<irave9$qdq$1(at)dont-email(dot)me> wrote:
> | On 5/22/2011 12:28 AM, Jeff North wrote:
> | > On Sat, 21 May 2011 20:01:17 -0400, in comp.lang.php Jerry Stuckle
> | > <jstucklex(at)attglobal(dot)net>
> | > <ir9jom$663$1(at)dont-email(dot)me> wrote:
[snip]
> | > http://www.apps.ietf.org/rfc/rfc3676.html#sec-4.3
> | > "There is a long-standing convention in Usenet news which also
> | > commonly appears in Internet mail of using "-- " as the separator line
> | > between the body and the signature of a message. When generating a
> | > Format=Flowed message containing a Usenet-style separator before the
> | > signature, the separator line is sent as-is."
> |
> | Which RFC is that?
Have a look at the hyperlink provided but incase you can't read
hyperlinks it is RFC 3676 - the one that YOU provided - remember?
> | > Now where does it state "It needs to be exactly
> | > hyphen-hyphen-space-newline."
> |
> | In the RFC. But you can't read either, so we also know you are an idiot.
Which RFC is that - it isn't in the one you provided (3676 or 3736).
Care to provide another RFC?
|
|
|
|
| Re: problem saving date fields [message #174125 is a reply to message #174121] |
Sun, 22 May 2011 17:47 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/22/2011 10:08 AM, Jeff North wrote:
> On Sun, 22 May 2011 08:26:48 -0400, in comp.lang.php Jerry Stuckle
> <jstucklex(at)attglobal(dot)net>
> <irave9$qdq$1(at)dont-email(dot)me> wrote:
>
>> | On 5/22/2011 12:28 AM, Jeff North wrote:
>> |> On Sat, 21 May 2011 20:01:17 -0400, in comp.lang.php Jerry Stuckle
>> |> <jstucklex(at)attglobal(dot)net>
>> |> <ir9jom$663$1(at)dont-email(dot)me> wrote:
>
> [snip]
>
>> |> http://www.apps.ietf.org/rfc/rfc3676.html#sec-4.3
>> |> "There is a long-standing convention in Usenet news which also
>> |> commonly appears in Internet mail of using "-- " as the separator line
>> |> between the body and the signature of a message. When generating a
>> |> Format=Flowed message containing a Usenet-style separator before the
>> |> signature, the separator line is sent as-is."
>> |
>> | Which RFC is that?
>
> Have a look at the hyperlink provided but incase you can't read
> hyperlinks it is RFC 3676 - the one that YOU provided - remember?
>
>> |> Now where does it state "It needs to be exactly
>> |> hyphen-hyphen-space-newline."
>> |
>> | In the RFC. But you can't read either, so we also know you are an idiot.
>
> Which RFC is that - it isn't in the one you provided (3676 or 3736).
> Care to provide another RFC?
3767. Learn to read, idiot. But we already know that is beyond your
limited capabilities.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174127 is a reply to message #174125] |
Sun, 22 May 2011 18:17 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/22/2011 1:47 PM, Jerry Stuckle wrote:
> 3767. Learn to read, idiot. But we already know that is beyond your
> limited capabilities.
You can make your point without being a bully, Mr. Stuckle.
Bill B
|
|
|
|
| Re: problem saving date fields [message #174128 is a reply to message #174127] |
Sun, 22 May 2011 18:26 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/22/2011 2:17 PM, Bill B wrote:
> On 5/22/2011 1:47 PM, Jerry Stuckle wrote:
>> 3767. Learn to read, idiot. But we already know that is beyond your
>> limited capabilities.
>
> You can make your point without being a bully, Mr. Stuckle.
>
> Bill B
You can take your self-righteous attitude and stuff it where the sun
doesn't shine. That way it will be right next to your head.
But like all trolls, you never have anything to add to a conversation
but feel you have to stick your ass in anyway.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: problem saving date fields [message #174132 is a reply to message #174128] |
Sun, 22 May 2011 20:27 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/22/2011 2:26 PM, Jerry Stuckle wrote:
> On 5/22/2011 2:17 PM, Bill B wrote:
>> On 5/22/2011 1:47 PM, Jerry Stuckle wrote:
>>> 3767. Learn to read, idiot. But we already know that is beyond your
>>> limited capabilities.
>>
>> You can make your point without being a bully, Mr. Stuckle.
>>
>> Bill B
>
> You can take your self-righteous attitude and stuff it where the sun
> doesn't shine. That way it will be right next to your head.
>
> But like all trolls, you never have anything to add to a conversation
> but feel you have to stick your ass in anyway.
Grape Nuts, Mr. Stuckle.
Bill B
|
|
|
|
| Re: problem saving date fields [message #174136 is a reply to message #174106] |
Sun, 22 May 2011 21:20 |
Co
Messages: 75
Registered: May 2011
Karma: 0
|
Member |
|
|
On 22 mei, 01:55, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> On 5/21/2011 11:07 AM, Co wrote:
>
>
>
>
>
>
>
>
>
>> On 21 mei, 16:37, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>>> On 5/21/2011 3:18 AM, Co wrote:
>
>>>> On 21 mei, 08:47, Co<vonclausow...@gmail.com> wrote:
>
>>>> > Did some testing with the print command.
>>>> > When I update the dates these are the results.
>
>>>> > when I change departure:
>>>> > arrival 2009-0120 departure 11-07-01
>
>>>> > when I change arrival:
>>>> > arrival 2009-07-01 departure 2011-01
>
>>>> > it doesn't make any sense to me.
>
>>>> > Marco
>
>>>> After some more testing I figured out that the month value of the date
>>>> which is not
>>>> updated makes the date go corrupt (set to default). So someone the
>>>> month value doesn't get read
>>>> well from the $_POST['departure_month'].
>
>>>> Any thoughts.
>
>>>> MArco
>
>>> What's in your $_POST array?
>
>>> print_var($_POST);
>
>> Well basically when I change one of the dates; the one changed is
>> fine.
>> The other one untouched will only return the day and the year.
>> Something like this: 122009.
>> This doesn't happen when I change any other field; leaving the dates
>> unchanged.
>
>> Marco
>
> That doesn't answer my question.
>
> If you want help, you need to answer our questions.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================
No you are right Jerry.
Problem is my program doesn't know the command print_var($POST);
Marco
|
|
|
|
| Re: problem saving date fields [message #174138 is a reply to message #174136] |
Sun, 22 May 2011 21:28 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/22/2011 5:20 PM, Co wrote:
> On 22 mei, 01:55, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>> On 5/21/2011 11:07 AM, Co wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On 21 mei, 16:37, Jerry Stuckle<jstuck...@attglobal.net> wrote:
>>>> On 5/21/2011 3:18 AM, Co wrote:
>>
>>>> > On 21 mei, 08:47, Co<vonclausow...@gmail.com> wrote:
>>
>>>> >> Did some testing with the print command.
>>>> >> When I update the dates these are the results.
>>
>>>> >> when I change departure:
>>>> >> arrival 2009-0120 departure 11-07-01
>>
>>>> >> when I change arrival:
>>>> >> arrival 2009-07-01 departure 2011-01
>>
>>>> >> it doesn't make any sense to me.
>>
>>>> >> Marco
>>
>>>> > After some more testing I figured out that the month value of the date
>>>> > which is not
>>>> > updated makes the date go corrupt (set to default). So someone the
>>>> > month value doesn't get read
>>>> > well from the $_POST['departure_month'].
>>
>>>> > Any thoughts.
>>
>>>> > MArco
>>
>>>> What's in your $_POST array?
>>
>>>> print_var($_POST);
>>
>>> Well basically when I change one of the dates; the one changed is
>>> fine.
>>> The other one untouched will only return the day and the year.
>>> Something like this: 122009.
>>> This doesn't happen when I change any other field; leaving the dates
>>> unchanged.
>>
>>> Marco
>>
>> That doesn't answer my question.
>>
>> If you want help, you need to answer our questions.
>>
>> --
>> ==================
>> Remove the "x" from my email address
>> Jerry Stuckle
>> JDS Computer Training Corp.
>> jstuck...@attglobal.net
>> ==================
>
> No you are right Jerry.
> Problem is my program doesn't know the command print_var($POST);
>
> Marco
My mistake - should be print_r(). Sorry.
And the value is $_POST, not $POST.
print_r() and var_dump() are both good debugging tools to help you.
--
==================
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
]