Strange Session-String-Date behaviour

[lovemy7]

I am developing an online purchasing site. To identify a specific transaction I set up a uniqueRef based on the userID(int) a "-" and date("U") concatenated together the minus sign is a separator  so I can strip the ID later when returned from the bank.
[code]$BR_unique_Ref = (string)$row_FindUser['userID']."-".date("U");
$_SESSION['invoiceData(4)'] = (string)$BR_unique_Ref;[/code]
I have cast to force to string!

My problem is between pages on the site the $_SESSION increments by a few seconds blowing apart my unique ref completely.

What am I doing wrong, does PHP back reference a variable to it's original components thus allowing the clock to run even though its has been concatenated and cast to a string?

[bache]

Well,
I don't think that's the case. Are you sure you are not asigning this value once again before printing it?

[hvle]

no,

You probably call this procedure again somewhere on the other pages.

and you do not have to type cast (string) every time.  PHP features type juggling and it would cast to an appropriate type for you automaticly.

[lovemy7]

Hi,
I set the Session var once only. Then all I desire is for the value in that session var to stay the same so that I can compare it to values stored in my DB to identify the transaction.

If I echo the Session on the same page 20 times it stays the same the moment I call a new page the value changes ... sometimes, not always. Now my issue is what more must I do to force the Session var to stay the same and not change!

When I create the string I cast (string)... when I assign the string to the Session var I cast (string) thereafter I only read the value, never reset it.

Thanks

[hvle]

The session variables do not change unless you deliberately change it yourself.  I think somewhere in the new page did change it.  Check all your include in the new page to make sure. 

[HuggieBear]

Simplify the above by just using this:

[code=php:0]$_SESSION['invoiceData(4)'] = $row_FindUser['userID'] . "-" . date("U");[/code]

Then use $_SESSION['invoiceData(4)'] everywhere from now on, (including when you insert into the database) this way you'll be guaranteed the value always remains the same.

Regards
Huggie

[lovemy7]

Hi hvle,

I verified that I had not reset the var first! below is every instance of the particular Session var cut and pasted.
[code]<?php
$BR_colname_GetTempInvoice = "-1";
if (isset($_SESSION['invoiceData(4)'])) {
  $BR_colname_GetTempInvoice = (get_magic_quotes_gpc()) ? $_SESSION['invoiceData(4)'] : addslashes($_SESSION['invoiceData(4)']);
}
?>
<p><?php echo $row_FormPrompts['youwillnowbetrans']; ?></p><?php echo $_SESSION['invoiceData(4)']; ?>
<input name="MB" type="hidden" value="<?php echo $_SESSION['invoiceData(4)']; ?>" />[/code]

As you can see that they are all referenced but not set unless addslashes applies. But once again it is supposed to be a string and not the individual components of the made up string.

I only ever set the string in one place in the whole site as below in a two step process. The first step was added to try and stop this nightmare.
[code]<?php $BR_unique_Ref = (string)$row_FindUser['userID']."-".date("U");
$_SESSION['invoiceData(4)'] = (string)$BR_unique_Ref;
?>[/code]

So I will again ask my original question...does PHP back reference a variable to it's original components thus allowing the clock to run even though its has been concatenated and cast to a string?

I am beginning to believe it does, this could have very serious ramifications.

BTW I am not a beginner at PHP or programming and posted here because I believe this forum to be the quintessential repository of PHP knowledge and have tried every other venue for this problem. 

[HuggieBear]

[quote author=lovemy7 link=topic=124877.msg518847#msg518847 date=1170328718]
So I will again ask my original question...does PHP back reference a variable to it's original components thus allowing the clock to run even though its has been concatenated and cast to a string?
[/quote]

No, you can use references, but in this instance, the answer is no!

You must have reassigned it somewhere in the code.

Regards
Huggie

[hvle]

I honestly do not believe you are an experienced PHP programmer due to the way you write your code:
Experienced programmer do not jump back and forth between php and html like you did:
<?php echo $row_FormPrompts['youwillnowbetrans']; ?></p><?php echo $_SESSION['invoiceData(4)']; ?>
and also, naming a variable like "invoiceData(4)" (the 4 inside parenthesis?).  I never see anybody did it like that, unless there is a really personal special reason.

Lastly, if you know PHP well, you would never believe such thing like PHP reference back to original components.  That is absurd and go against the very basic concept of programming.

So, to answer your question again, NO.
And again, you have a bug in your code and if you stop believing nonsense and start debugging, you will find it.

[HuggieBear]

[quote author=hvle link=topic=124877.msg518855#msg518855 date=1170329783]
I honestly do not believe you are an experienced PHP programmer due to the way you write your code:
[/quote]

Hey, this isn't a forum for flaming!

Huggie

[hvle]

shoosh, get back with your boozeee bear.

[HuggieBear]

[quote author=hvle link=topic=124877.msg518860#msg518860 date=1170330194]
shoosh, get back with your boozeee bear.
[/quote]

Sorry I didn't reply sooner, I've been in the pub ;)

Lovemy7, if you're certain that you haven't made a mistake then maybe you could post the complete code, with errors in, and we'll take a look.

Regards
Huggie

[lovemy7]

To hvle:

The reason the (4) is behind the var is that I have a security man who will not allow me to post the actual var name as it is passed to the bank. I edited the var suffixes to comply with my paranoid client and so I could quickly change them back!
Now the reason there is PHP within the XHTML is because this is a multilingual web page/site capable of serving any of up to 255 languages to the same page. All prompts and content are in a database and are dynamically placed in position based on the language selected. Remember we live in a multi-lingual society where English is not the only language (in fact a minor language). A vast amount of both the XHTML and the content have to be changed depending on the language chosen. Finally the shopping basket is an AJAX system placing the information in the database and then being extracted at invoice level.

In our original development stage we compared the speed and accuracy of generating all XHTML from PHP and interspersing a XHTML framework with dynamic script. The second option is faster as PHP parses that which is PHP and then the HTML is done, the other way it places an additional burden on the PHP parser to process all the HTML then the  HTML still has to be parsed.
To HuggieBear

I would love to post all of the script but 1: My client wont allow it and 2: the two pages concerned with includes amount to over 900 lines of script.

Again to hvle:

Do not judge the whole book by a few words! You do not know everything and all you have succeeded in doing is pissing me off. Please post a photo of you walking on water.

[HuggieBear]

[quote author=lovemy7 link=topic=124877.msg518926#msg518926 date=1170338641]
To hvle:

Do not judge the whole book by a few words! You do not know everything and all you have succeeded in doing is pissing me off. Please post a photo of you walking on water.
[/quote]

Superb... Don't say I didn't warn you hvle!

I know what you're dealing with lovemy7, I've dealt with both banking and insurance institutions so I know what the guidelines are like.  However, based on the amount of code you've said there is, the chances of PHP making a mistake and not you, are looking very slim.

I'm afraid I can't really comment any more on this post past what I already have, as there's no issues with the code syntax you've shown us.

Good luck in your quest.

Regards
Huggie

[hvle]

Why are you wasting your time explain your top secret project while not able to post a single code so we can help you out.  With an ego like you, I ain't get too far in programming.  Here, we learn by mistake and criticism, and if you can not take it, go elsewhere, or do not ask. 

Judging by the way you presented your PHP, I could easily spot your novice experience on this.  1 + 1 - 1 = what???.
Look at how you jump back and forth with PHP.  I don't want to say it over again, but you're obviously pretty shallow on PHP.  Don't mad, just spend more time on it and you will get it. 

The bug in there, you just gotta find it.  Since you can't post your code, how do anybody suppose to help you.

Anyway, if you like to see a picture of me doing ice-skating, let me know.

[lovemy7]

Dear All,

hvle wrote"PHP features type juggling and it would cast to an appropriate type for you automaticly."

And herein lies the issue and the problem:

An integer followed by a minus followed by an integer?? {date("U")} may be construed as an integer or at best float.
By changing the separator to an underscore "_" which is not an operator the SESSION works just fine, changing back to a minus "-" returns all the issues.
Now hvle I never said I was an expert at PHP I said I was not a beginner at PHP or programming.

I am certain you are an expert. If so please understand that the website we are building is a XHTML /CSS framework with content, some structure, language, attributes, presentation and some behaviors served dynamically by PHP. The client side behaviour is javascript but many of the external scripts are served dynamically in the XHTML structure by PHP.

Now this may offend your sensibilities in wanting to gun code every morsel in PHP and echo every XHTML tag, content, behavior etc. But it is just not possible.

I am now going to blast my 7 down the road to vent my frustration:)

[lovemy7]

To hvle,

Message received thanks for the offer, cant reply problem solved see above post.

Once again thanks to all!

[hvle]

This is still very weird.  It should not be work like that.

lovemy7, I am very not an expert, i am here to learn like you, like this problem of yours, I never encountered this problem but i'm sure in the future I will.

 

So, again, sorry for the jabbing and misunderstanding.  Please post again if you got something you'd like to share.