Web Connection
Web Store
Gravatar is a globally recognized avatar based on your email address. Web Store
  Jim Monte
  All
  Nov 23, 2015 @ 09:35am
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?

Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Rick Strahl
  Jim Monte
  Nov 23, 2015 @ 10:06am
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 Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 11:20am
I deleted the session file.. it was auto recreated.. however .. using IE11 and latest chrome still share same cart..


http://70.61.231.5/wwstore



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?



Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 11:38am
also the file.field wws_tlineitems.sessionid and is only 9 chars long is blank for all items in the cart.....

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?



Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 12:10pm
also.. only 1 record is created in the wwsession.dbf .. no matter how many people are on the site...


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?



Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 02:52pm
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?



Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Rick Strahl
  Jim Monte
  Nov 23, 2015 @ 04:00pm

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 Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 04:12pm
I can change the llpersist flag back to .t... and you can go to http://70.61.231.5/wwstore and login with 2 or 4 different browsers.. only 1 session record gets created.. all 3 different browsers get the same cart...

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?






Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 04:15pm
i'm sure setting the flag to .f. will cause problems though... will this cause countless records to get created?

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?






Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 04:25pm
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?






Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Rick Strahl
  Jim Monte
  Nov 23, 2015 @ 04:28pm
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 Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 04:29pm
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?









Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Jim Monte
  Nov 23, 2015 @ 04:30pm
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?










Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Rick Strahl
  Jim Monte
  Nov 23, 2015 @ 04:32pm
I don't know then. You need to debug into the session and see why all these browsers are apparently using the same session cookie. That makes no sense. Clear your cookies in all browsers then try this again.

+++ 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?













Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Jim Monte
  Nov 23, 2015 @ 04:33pm
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?











Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Jim Monte
  Nov 23, 2015 @ 05:03pm
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?












Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Rick Strahl
  Jim Monte
  Nov 23, 2015 @ 07:28pm
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 EMPTY(lcSessionId)
RETURN .F.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?














Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 07:36pm
Nice.. Not nice that there's a bug.. nice that you found out what it is... good thing it was found while in Beta..

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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?















Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 07:43pm
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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?















Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Jim Monte
  Nov 23, 2015 @ 07:45pm
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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?
















Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Jim Monte
  Nov 23, 2015 @ 07:50pm
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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?

















Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Rick Strahl
  Jim Monte
  Nov 23, 2015 @ 08:18pm
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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?




















Rick Strahl
West Wind Technologies

Making waves on the Web
from Maui

Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 23, 2015 @ 09:26pm
Thanks again Rick!


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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?




















Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 24, 2015 @ 06:57am
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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?




















Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Rick Strahl
  Jim Monte
  Nov 24, 2015 @ 09:03am
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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?






















Rick Strahl
West Wind Technologies

Making waves on the Web
from Hood River

Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 24, 2015 @ 05:58pm
I agree to some extend.. Cell phones can benefit from SPA with less page reloads.. but yes there would be less static stuff... Maybe I'll keep a few pages.. and tweak with AJAX calls where I can..

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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?






















Gravatar is a globally recognized avatar based on your email address. Re: Web Store
  Jim Monte
  Rick Strahl
  Nov 24, 2015 @ 05:59pm
I also made it responsive.. still have a few things to do... but everything wraps nicely.. etc..


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.
ENDIF

THIS.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 SessionId

lcLocateId = 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
ENDIF

RETURN 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?






















© 1996-2024