Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
West Wind Technologies
Making waves on the Web
from Maui
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
The newly created session file sessionid is now varchar 17..
Should I make the sessionid field in wws_tlineitems.sessionid varchar 17?
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
West Wind Technologies
Making waves on the Web
from Maui
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
West Wind Technologies
Making waves on the Web
from Maui
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
+++ Rick ---
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
West Wind Technologies
Making waves on the Web
from Maui
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMPTY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
Thanks
Jim
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
One more question.... Since the wwsession file has the sessionid field as varchar 17.. should I change the sessionid field in wws_tlineitems from char 9 to varchar 17?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
And yes you should widen the field to match.
The code for the store is pretty old - it was update for Version 5.0 so it can run but it's dated nevertheless. It works, but obviously it shows signs of its age both in the UI and some of the code features.
+++ Rick ---
by the way.. you have a bug in your fix.. emtpy should be empty:) lol.. no biggie
One more question.... Since the wwsession file has the sessionid field as varchar 17.. should I change the sessionid field in wws_tlineitems from char 9 to varchar 17?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
West Wind Technologies
Making waves on the Web
from Maui
Yup I typed that in as an after thought here, but it's correct in the core code base.
And yes you should widen the field to match.
The code for the store is pretty old - it was update for Version 5.0 so it can run but it's dated nevertheless. It works, but obviously it shows signs of its age both in the UI and some of the code features.
+++ Rick ---
by the way.. you have a bug in your fix.. emtpy should be empty:) lol.. no biggie
One more question.... Since the wwsession file has the sessionid field as varchar 17.. should I change the sessionid field in wws_tlineitems from char 9 to varchar 17?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
Thanks
JimM
Yup I typed that in as an after thought here, but it's correct in the core code base.
And yes you should widen the field to match.
The code for the store is pretty old - it was update for Version 5.0 so it can run but it's dated nevertheless. It works, but obviously it shows signs of its age both in the UI and some of the code features.
+++ Rick ---
by the way.. you have a bug in your fix.. emtpy should be empty:) lol.. no biggie
One more question.... Since the wwsession file has the sessionid field as varchar 17.. should I change the sessionid field in wws_tlineitems from char 9 to varchar 17?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
A WebStore is probably one of those use cases that doesn't make for a good SPA application because you want to ensure searchability of the content from static HTML. Not sure there would be much benefit of making a store a SPA - it's not what qualifies as a very interactive application that requires lots of dynamic stuff to occur. The handful of things that might be - like stock data or cart status can easily be done with a few simple AJAX updates.
+++ Rick ---
I updated the store to bootstrap 3 / fontawesome / jquery etc.. looks pretty good.. / once we test everything and it seems to be running fine... I'll turn it into a SPA app.. with just ajax calls for data.. but for the time being I really like what you have done!!
Thanks
JimM
Yup I typed that in as an after thought here, but it's correct in the core code base.
And yes you should widen the field to match.
The code for the store is pretty old - it was update for Version 5.0 so it can run but it's dated nevertheless. It works, but obviously it shows signs of its age both in the UI and some of the code features.
+++ Rick ---
by the way.. you have a bug in your fix.. emtpy should be empty:) lol.. no biggie
One more question.... Since the wwsession file has the sessionid field as varchar 17.. should I change the sessionid field in wws_tlineitems from char 9 to varchar 17?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
West Wind Technologies
Making waves on the Web
from Hood River
Thanks
JimM
Jim,
A WebStore is probably one of those use cases that doesn't make for a good SPA application because you want to ensure searchability of the content from static HTML. Not sure there would be much benefit of making a store a SPA - it's not what qualifies as a very interactive application that requires lots of dynamic stuff to occur. The handful of things that might be - like stock data or cart status can easily be done with a few simple AJAX updates.
+++ Rick ---
I updated the store to bootstrap 3 / fontawesome / jquery etc.. looks pretty good.. / once we test everything and it seems to be running fine... I'll turn it into a SPA app.. with just ajax calls for data.. but for the time being I really like what you have done!!
Thanks
JimM
Yup I typed that in as an after thought here, but it's correct in the core code base.
And yes you should widen the field to match.
The code for the store is pretty old - it was update for Version 5.0 so it can run but it's dated nevertheless. It works, but obviously it shows signs of its age both in the UI and some of the code features.
+++ Rick ---
by the way.. you have a bug in your fix.. emtpy should be empty:) lol.. no biggie
One more question.... Since the wwsession file has the sessionid field as varchar 17.. should I change the sessionid field in wws_tlineitems from char 9 to varchar 17?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?
Jim,
A WebStore is probably one of those use cases that doesn't make for a good SPA application because you want to ensure searchability of the content from static HTML. Not sure there would be much benefit of making a store a SPA - it's not what qualifies as a very interactive application that requires lots of dynamic stuff to occur. The handful of things that might be - like stock data or cart status can easily be done with a few simple AJAX updates.
+++ Rick ---
I updated the store to bootstrap 3 / fontawesome / jquery etc.. looks pretty good.. / once we test everything and it seems to be running fine... I'll turn it into a SPA app.. with just ajax calls for data.. but for the time being I really like what you have done!!
Thanks
JimM
Yup I typed that in as an after thought here, but it's correct in the core code base.
And yes you should widen the field to match.
The code for the store is pretty old - it was update for Version 5.0 so it can run but it's dated nevertheless. It works, but obviously it shows signs of its age both in the UI and some of the code features.
+++ Rick ---
by the way.. you have a bug in your fix.. emtpy should be empty:) lol.. no biggie
One more question.... Since the wwsession file has the sessionid field as varchar 17.. should I change the sessionid field in wws_tlineitems from char 9 to varchar 17?
Nice!!! I updated the code.. Looks good!!
Thanks Rick
You Rock!!
Ok. I finally had some time to take a look at this and get the store running here locally.
So I have to apologize :-) I was able to duplicate the behavior you're seeing...
There's a serious regression bug in the wwSession code in Beta 2 that's causing this issue. Basically it's related to a database change going to VarChar fields in the session table and causing the Session to always be found even if it's empty.
You can fix this by updating the wwSession::LocateSession() method with
************************************************************************
* wwSession :: LocateSession
*********************************
*** Function: Loads the oData member with the session data.
*** This is a low level function that you typically
*** won't address directly. Use IsValidSession instead.
*** Pass: lcSessionID - Session to load (or reload current)
*** llIgnoreTimeo - retrieves a session entry even
*** if it's expired
************************************************************************
FUNCTION LocateSession
LPARAMETERS lcSessionId, llIgnoreTimeout
LOCAL llResult
lcSessionId=IIF(type("lcSessionId")="C",lcSessionId,THIS.cSessionId)IF EMTPY(lcSessionId)
RETURN .F.
ENDIFTHIS.OpenTable()
** Force table buffers to refresh!!!
** Necessary for high volume applications so that sessions
** created in one request can immediately be seen by others
** such as scripts or other iframes/ajax calls
REPLACE SessionId with SessionIdlcLocateId = lcSessionId
llResult = .F.
IF !llIgnoreTimeout
LOCATE FOR SessionId == lcLocateId AND ;
LastOn > DATETIME() - THIS.nSessionTimeout
IF FOUND()
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
RETURN .T.
ENDIF
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ELSE
SELECT TOP 1 * FROM wwSession ;
WHERE SessionId == lcLocateId ;
ORDER BY LastOn DESC ;
INTO CURSOR __TSession
IF _tally > 0
SCATTER NAME THIS.oData MEMO
THIS.cSessionId=wwSession.SessionId
this.oData.LastOn = DATETIME()
llResult = .T.
ELSE
SCATTER NAME THIS.oData MEMO BLANK
THIS.cSessionId=""
ENDIF
USE IN __TSession
SELECT wwSession
ENDIFRETURN llResult
ENDFUNC
* LocateSession
This should fix the problem.
Thanks for pointing it out - I'm rather surprised nobody's reported this because this is a pretty major issue that would have caused all sorts of strange behavior.
+++ Rick ---
fundamental problem?.. I know the store is sold as is.. We just need to get this running.. We can pay you if you'd like.. I don't want to fiddle with anything to do with sessions as I may cause more problems than fix the current problem...
ok.. i set the flag back to .t. if you'd like to try..
i can change the flag back to true.. and you can try..
yes.. 3 different browser.. ie11.. chrome... safari..
Again - are you using two completely different browsers? IOW: Chrome and Internet Explorer? If you use the same browser - even new windows started from the desktop you will get the same browser session as cookies are always shared across browser sessions.
If that is not working you got a more fundamental problem that has nothing to do with the store.
+++ Rick ---
every browser physically has a different session cookie with unique value in its storage.. however.. the first one to create the record on the server gets their session id stored in it... the rest of the browsers "although they have a unique sessionid" don't create their own record on the server...
If you have a single entry in your session table you're not using separate browsers. IOW the same session is shared across your multiple browser windows (even if you launched a new instance of the same browser). You have to test with completely separate browsers.
+++ Rick ---
changing "llpersist to .f." THIS.InitSession(Config.cCookiename,3600,.t.) to THIS.InitSession(Config.cCookiename,3600,.f.) in wwstore.prg.. it forces a new session...????
Can you check your session table and see what happens with sessions?
You probably need to test with two completely separate browsers - ie. Chrome and IE - in order to simulate two users effectively.
Also make sure your session table is updated to the latest structure. In Web Connection 6.0 the width of the ID field is wider, so if the table field is not wide enough the ids end up duplicating potentially. You can delete the wwSession file - it'll be recreated when you restart.
+++ Rick ---
Foxpro Web Store..
Got the store to work with the new project setup etc.. Thought it was all fine.. until my shopping cart items show up in other peoples shopping cart.. and theirs in mine... I know session were handled differently in older versions of wconnect.. So I'm lost here... I even tried .initsession .releasesession.. nothing seems to work .. any suggestion on what could be causing this?