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

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

problem saving date fields

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

Contents

  problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-20 11:38 -0700
    Re: problem saving date fields Luuk <Luuk@invalid.lan> - 2011-05-20 20:50 +0200
    Re: problem saving date fields Jeff North <jnorthau@yahoo.com.au> - 2011-05-21 08:58 +1000
      Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-20 22:35 -0400
        Re: problem saving date fields Jeff North <jnorthau@yahoo.com.au> - 2011-05-21 13:13 +1000
          Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-20 23:47 -0700
            Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-21 00:18 -0700
              Re: problem saving date fields Luuk <Luuk@invalid.lan> - 2011-05-21 09:54 +0200
              Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-21 10:37 -0400
                Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-21 08:07 -0700
                  Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-21 19:55 -0400
                    Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-22 14:20 -0700
                      Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-22 17:28 -0400
          Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-21 10:32 -0400
            Re: problem saving date fields Jeff North <jnorthau@yahoo.com.au> - 2011-05-22 02:08 +1000
              Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-21 20:01 -0400
                Re: problem saving date fields "Twayne" <nobody@devnull.spamcop.net> - 2011-05-21 20:30 -0400
                  Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-21 23:13 -0400
                Re: problem saving date fields Jeff North <jnorthau@yahoo.com.au> - 2011-05-22 14:28 +1000
                  Re: problem saving date fields Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-05-22 12:45 +0200
                  Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-22 08:26 -0400
                    Re: problem saving date fields "Twayne" <nobody@devnull.spamcop.net> - 2011-05-22 09:20 -0400
                    Re: problem saving date fields Jeff North <jnorthau@yahoo.com.au> - 2011-05-23 00:08 +1000
                      Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-22 13:47 -0400
                        Re: problem saving date fields Bill B <me@privacy.net> - 2011-05-22 14:17 -0400
                          Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-22 14:26 -0400
                            Re: problem saving date fields Bill B <me@privacy.net> - 2011-05-22 16:27 -0400
                        Re: problem saving date fields Jeff North <jnorthau@yahoo.com.au> - 2011-05-23 09:01 +1000
                          Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-22 20:21 -0400
                            Re: problem saving date fields Bill B <me@privacy.net> - 2011-05-22 21:36 -0400
                              Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-22 21:46 -0400
                            Re: problem saving date fields Jeff North <jnorthau@yahoo.com.au> - 2011-05-23 12:20 +1000
                              Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-22 22:30 -0400
                                Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-22 21:51 -0700
                                  Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-23 07:13 -0400
                                    Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-23 10:18 -0700
                                    Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-23 10:27 -0700
                                      Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-23 14:16 -0400
                                        Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-23 12:17 -0700
                                          Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-23 18:00 -0400
                                            Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-23 22:30 -0700
                                              Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-24 05:45 -0400
                                                Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-26 02:10 -0700
                                                  Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-26 05:43 -0400
                                      Re: problem saving date fields Co <vonclausowitz@gmail.com> - 2011-05-23 14:26 -0700
                                        Re: problem saving date fields Jerry Stuckle <jstucklex@attglobal.net> - 2011-05-23 18:01 -0400
                              Re: problem saving date fields Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-05-23 23:59 +0200
                  Re: problem saving date fields "Twayne" <nobody@devnull.spamcop.net> - 2011-05-22 09:11 -0400

Page 1 of 3  [1] 2 3  Next page →

#1696 — problem saving date fields

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

[toc] | [next] | [standalone]

#1698

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

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

#1715

On Fri, 20 May 2011 11:38:06 -0700 (PDT), in comp.lang.php Co
<vonclausowitz@gmail.com>
<2407eb47-b406-432c-9aed-b76abc94aae9@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:
>| 
>| <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
-- --------------------------------------------------------------

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

#1720

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@gmail.com>
> <2407eb47-b406-432c-9aed-b76abc94aae9@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:
>> |
>> |<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@attglobal.net
==================

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

#1723

On Fri, 20 May 2011 22:35:03 -0400, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net>
<ir78cp$53s$1@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
>| > <vonclausowitz@gmail.com>
>| > <2407eb47-b406-432c-9aed-b76abc94aae9@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.

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

#1724

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

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

#1725

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

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

#1728

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

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

#1749

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@attglobal.net
==================

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

#1750

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

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

#1754

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@attglobal.net
==================

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

#1784

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

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

#1786

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@attglobal.net
==================

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

#1747

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@attglobal.net>
> <ir78cp$53s$1@dont-email.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@attglobal.net
==================

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

#1751

On Sat, 21 May 2011 10:32:20 -0400, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net>
<ir8idn$ojm$1@dont-email.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@attglobal.net>
>| > <ir78cp$53s$1@dont-email.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.

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

#1755

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@attglobal.net>
> <ir8idn$ojm$1@dont-email.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@attglobal.net>
>> |>  <ir78cp$53s$1@dont-email.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@attglobal.net
==================

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

#1756

In news:ir9jom$663$1@dont-email.me,
Jerry Stuckle <jstucklex@attglobal.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@attglobal.net>
>> <ir8idn$ojm$1@dont-email.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@attglobal.net>
>>>>>  <ir78cp$53s$1@dont-email.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?

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

#1758

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@attglobal.net
==================

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

#1760

On Sat, 21 May 2011 20:01:17 -0400, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net>
<ir9jom$663$1@dont-email.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@attglobal.net>
>| > <ir8idn$ojm$1@dont-email.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@yahoo.com> wrote:
I said I was aiming at your stupidity, not your brain.

"Johnny" <wxpprofessional@msn.com> writes:
You missed. You can not hit a non-existent thing.
-- -----------------------------------------------------------

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

#1761

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@yahoo.com> wrote:
> I said I was aiming at your stupidity, not your brain.
> 
> "Johnny" <wxpprofessional@msn.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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web