[RESOLVED] UNEXPECTED RESULT

[davidmorley]

I wrote some data into a dbt as follows

date_default_timezone_set("Europe/London");
$dt = new DateTime();
$result = $dt->format('Y-m-d/%/H:i:s');


$query = "INSERT INTO hitcount VALUES(NULL, '$result', 25, 26, 27, 28 )";
$result = $conn->query($query);
if (!$result) die ("Database access failed: " . $conn->error);

// If this repeated section is omitted $result is set to 1 in the dbt after the first insert. I don't know why at 20 Jan 17

date_default_timezone_set("Europe/London");
$dt = new DateTime();
$result = $dt->format('Y-m-d/%/H:i:s');

// end of repeated section

$query = "INSERT INTO hitcount VALUES(NULL, '$result', 16, 17, 18, 19 )";
$result = $conn->query($query);
if (!$result) die ("Database access failed: " . $conn->error);

I cannot understand why I need to "re-calculate" $result after the first INSERT.

Could someone explain this to me, please ?

[NogDog]

Once you create the DateTime object, it defaults to the current time when it is instantiated. You could reset it using:

$result = $dt->setTimestamp(time());

However, seems to me it would be a lot simpler to let the DB do it if you just want the current date/time:

$query = "INSERT INTO hitcount VALUES(NULL, NOW(), 25, 26, 27, 28 )";

[dalecosp]

NogDog has a great answer.

Just as a side point, what's up with this format?

$result = $dt->format('Y-m-d/%/H:i:s'); 

Doesn't that yield something like:

2017-01-20/%/09:26:26

? I don't think that "%" gets expanded to anything useful, does it?

[NogDog]

Yep, that's what I get:

13:55 $ php -a
Interactive mode enabled

php > $dt = new DateTime();
php > $result = $dt->format('Y-m-d/%/H:i:s');
php > echo $result;
2017-01-20/%/13:54:27

[dalecosp]

Seems like having to code around that for queries, and potentially display, would be as bad/worse than saving the UNIX_TIMESTAMP().

[Weedpacket]

All of the above, but I think the proximate cause is trying to use the same variable (the generically-named [font=monospace]$result[/font]) for two completely different things at the same time.

[davidmorley]

Thank you all for this. The /%/ is a historical hang-over from an earlier (different) application which had a very long string to store. I used the /%/ as a seperator so that when I had pasted the result into Excel I could easily separate out the bits and put them in different columns. I know it looks a bit odd but it did the job OK.

I had thought that $result, once formed, was just a variable like any other variable.

[Derokorian]

davidmorley;11059643 wrote:

I had thought that $result, once formed, was just a variable like any other variable.

It is, but you are reassigning its value many times throughout the code. Specifically, on the following 4 lines, the variable's value gets overwritten each subsequent time.

davidmorley;11059627 wrote:

$result = $dt->format('Y-m-d/%/H:i:s');

$result = $conn->query($query);

$result = $dt->format('Y-m-d/%/H:i:s');

$result = $conn->query($query);

[dalecosp]

Derokorian;11059645 wrote:

It is, but you are reassigning its value many times throughout the code. Specifically, on the following 4 lines, the variable's value gets overwritten each subsequent time.

LOL, I've bitten myself with that more than once. There are probably plenty of bits around that look similar to:

$s = "Select foo from bar;";
$r = $db->query($s);

//extraction code here

$s  = "select baz from bar;";
$r2 = $db->query($s);

if (($r && $r2) && ($r->num_rows && $r2->num_rows)) {
 //...
}

Not exactly (as a JOIN or UNION would probably have taken care of some of that), but you get the idea. AAMOF I think there's a bug in the tracker now about some bit appending the wrong bit of HTML to a cached file (causing PHP's parser to bark) because at some point in the past I thought a great name for a global var would be "$htmlout" ...