Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6

This WebDNA talk-list message is from

2020


It keeps the original formatting.
numero = 115026
interpreted = N
texte = 2654 --Apple-Mail=_AB73BE42-B83D-4F6A-90CC-B08C321CD539 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Scott Thanks for the offer. At the moment the problem is on a dev server. I want to work out if = issue is server wide, site wide or just the two known dbs. I also want to test with different fcgi versions. The coding is 100% correct and the dbs are very small and simple - 20 = rows, 3 columns each. I will let you know of the outcome. =20 Kind regards Stuart Tremain Pharoah Lane Software AUSTRALIA webdna@plsoftware.com.au > On 20 Feb 2020, at 10:14, talk@webdna.us wrote: >=20 > Just to check, are there any particularly large DBs also in the mix on = that server instance, despite if they're part of this mix or not? If so = that could account for the delayed working response as per step 5 below, = assuming I've followed correctly. > =20 > If helpful I will try to replicate this end first thing in the morning = mate, am running 8.5.1 FCGI on CentOS > If you've any redacted test files that you're using, mail them over. > =20 > If it's super urgent and helpful and you're in the proverbial then = shout soonish and I'll attempt it tonight. > =20 > Regards, > Scott > =20 > From: talk@webdna.us > Sent: 19 February 2020 22:41 > To: WebDNA Talk List > Subject: Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI = version 8.6 > =20 > Hi Scott >=20 > My methodology: >=20 > 1) run the ajax >=20 > 2) open the db to ensure that changes have been made >=20 > 3) Clear browser cache, test the page that relies on the new value. = Repeat. >=20 > 4) No positive result from step 3, flush db from /WebDNA directory = link >=20 > 5) 2nd test of page that relies on the new value - page works properly = now with correct value. >=20 > I will be testing this across the other dbs in the site and dbs in = other sites that use the same version of the fcgi and a different = version of the fcgi. Currently I know of the problem in two dbs in the = same site >=20 > Kind regards >=20 > Stuart Tremain > Pharoah Lane Software > AUSTRALIA > webdna@plsoftware.com.au >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On 20 Feb 2020, at 03:34, talk@webdna.us = wrote: >>=20 >> Hi Stuart, >> =20 >> When you use Flush, to my (perhaps limited) understanding the data is = written to disk and purged from memory, and can take a few seconds at = times. Only then when another call to that DB is made is the DB reloaded = into memory. Perhaps the second call is happening before the flush has = completed? In this case, Commit would do it I gather. >> =20 >> I notice below you mentioned the use of Commit already also to no = avail. One check might be just to ensure that the DB name var is being = passed properly, as no error message would be generated if it wasn=E2=80=99= t, and the Commit wouldn=E2=80=99t show the drop in DB from memory on = the admin pages. >> =20 >> Just my 2cents chap. >> =20 >> BR >> Scott >> =20 >> =20 >> =20 >> From: talk@webdna.us >=20 >> Sent: Wednesday, February 19, 2020 1:32 AM >> To: WebDNA Talk List > >> Subject: Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI = version 8.6 >> =20 >> Hi Terry >> =20 >> It is hard to work out who sent email to the list now that the = =E2=80=9Cfrom" has changed. >> =20 >> =20 >> The call is very simple, a url with variables.=20 >> =20 >> =20 >> = admin-switch.dna?task=3Dswitch-6&dbid=3D6&dbidname=3DSM-ID&dbname=3Dshippi= ngmethods&dbfield=3DSM-ACTIVE&active=3DT >> =20 >> =20 >> The receiving page is very simple too. >>=20 >>=20 >> [REPLACE db=3D../data/[DBNAME].db&eq[DBIDNAME]datarq=3D[DBID]&max=3D1][= !] >> [/!][DBFIELD]=3D[URL][DBVALUE][/URL][!] >> [/!][/REPLACE] >> =20 >> =20 >> The replace is 100% correct in the db file if I open it up, the = problem is that until I manually flush the dbs it is not recognised. >> =20 >> I have tried putting in [CLOSEDATABASE db=3D../data/[DBNAME].db] or = [COMMITDATABASE db=3D../data/[DBNAME].db] or even [FLUSHDATABASES] with = no resolution. >> =20 >> It is not the one db, I have another ajax update for another db which = has the same issue. I have not gone through the entire system checking = for others. >> =20 >> Kind regards >> =20 >> Stuart Tremain >> Pharoah Lane Software >> AUSTRALIA >> webdna@plsoftware.com.au >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >>=20 >>=20 >> On 19 Feb 2020, at 12:11, talk@webdna.us = wrote: >> =20 >> Morning Stuart, >> =20 >> You mentioned =E2=80=9CI have include [FLUSHDATABASES] in the ajax = call=E2=80=9D =E2=80=A6.am I correct to say that you are either doing a = GET or POST Ajax call to a file sitting on the server that has the tags = to execute the flush webdna tag? >> =20 >> If so =E2=80=A6can share the ajax call script and the page called by = it so that I can try to assist you. It is indeed strange that the change = is stored in RAM but not committed into the DB even with all the = settings you mentioned. Regardless =E2=80=A6after the update, the = uncommitted change should still be showing up when called upon by other = pages relying on it. >> =20 >> Cheers TDn >> =20 >> From: talk@webdna.us >=20 >> Sent: Wednesday, February 19, 2020 07:39 AM >> To: WebDNA Talk List > >> Subject: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version = 8.6 >> =20 >> I am having an issue with a couple of dbs. >> =20 >> Permissions are correct 775 >> Ownership is correct www-data:www-data >> =20 >> I am updating the db with an ajax call, I open the db ofter it has = been modified and the mod is there in the db. >> =20 >> The ajax call does a replace on the db. >> =20 >> There is no error reported from the ajax call. >>=20 >>=20 >>=20 >> The WebDNA preference is "Automatically commit databases to disk = after modification" >> =20 >> The problem is that another page on the site is dependant on the new = value. This new value is not being found. >> =20 >> I have include [FLUSHDATABASES] in the ajax call to force the db to = clear however it is still not finding the new value. >> =20 >> If I use the WebDNA admin to [FLUSHDATABASES] then the page finds the = new value. >> =20 >> Any ideas ? >> =20 >> Kind regards >> =20 >> Stuart Tremain >> Pharoah Lane Software >> AUSTRALIA >> webdna@plsoftware.com.au >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> =20 >> --------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us >> --------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us >> =20 >> --------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us = N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7=A7=EF=BF= =BD=EF=BF=BD2=EF=BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C=EF=BF=BD= &=EF=BF=BDv=EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSEDR_^#<=D6=A5=EF=BF= =BD=07=EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF=BF=BD=EF=BF=BDm=EF= =BF=BD&j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF=BD=EF=BF=BD=1Em=EF=BF=BD=DA=BA= =C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF=BD = 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us = N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7=A7=EF=BF= =BD=EF=BF=BD2=EF=BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C=EF=BF=BD= &=EF=BF=BDv=EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSEDR_^#<=D6=A5=EF=BF= =BD=07=EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF=BF=BD=EF=BF=BDm=EF= =BF=BD&j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF=BD=EF=BF=BD=1Em=EF=BF=BD=DA=BA= =C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF=BD=0C= 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg --Apple-Mail=_AB73BE42-B83D-4F6A-90CC-B08C321CD539 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Scott

Thanks for the = offer.

At the = moment the problem is on a dev server. I want to work out if issue is = server wide, site wide or just the two known dbs.
I also want to test with different = fcgi versions.

The coding is 100% correct and the dbs are very small and = simple - 20 rows, 3 columns each.

I will let you know of the = outcome.
 
Kind regards

Stuart Tremain
Pharoah Lane Software
AUSTRALIA







On 20 Feb 2020, at 10:14, talk@webdna.us wrote:

Just to = check, are there any particularly large DBs also in the mix on that = server instance, despite if they're part of this mix or not? If so that = could account for the delayed working response as per step 5 below, = assuming I've followed correctly.
 
If helpful I will try to replicate this end first thing in = the morning mate, am running 8.5.1 FCGI on CentOS
If you've any redacted test files that = you're using, mail them over.
 
If it's super urgent and helpful and you're in the proverbial = then shout soonish and I'll attempt it tonight.
 
Regards,
Scott
 
From: talk@webdna.us
Sent: 19 = February 2020 22:41
To: WebDNA Talk List
Subject: Re: [WebDNA] = COMMITDATABASE in linux unix 64bits FastCGI version 8.6
 
Hi Scott

My methodology:

1) run the ajax

2) open the db to ensure that changes = have been made

3) Clear browser cache, test the page that relies on the new = value. Repeat.

4) No positive result from step 3, flush db from /WebDNA = directory link

5) 2nd test of page that relies on the new value - page works properly = now with correct value.

I will = be testing this across the other dbs in the site and dbs in other sites = that use the same version of the fcgi and a different version of the = fcgi. Currently  I know of the problem in two dbs in the same = site

Kind = regards

Stuart = Tremain
Pharoah Lane Software
AUSTRALIA
webdna@plsoftware.com.au







On 20 = Feb 2020, at 03:34, talk@webdna.us wrote:

Hi Stuart,
 
When you use Flush, to my (perhaps limited) = understanding the data is written to disk and purged from memory, and = can take a few seconds at times. Only then when another call to that DB = is made is the DB reloaded into memory. Perhaps the second call is = happening before the flush has completed? In this case, Commit would do = it I gather.
 
I notice below you = mentioned the use of Commit already also to no avail. One check might be = just to ensure that the DB name var is being passed properly, as no = error message would be generated if it wasn=E2=80=99t, and the Commit = wouldn=E2=80=99t show the drop in DB from memory on the admin pages.
 
Just my 2cents chap.
 
BR
Scott
 
 
 
From: talk@webdna.us <talk@webdna.us> 
Sent: Wednesday, February 19, = 2020 1:32 AM
To: WebDNA Talk List <talk@webdna.us>
Subject: Re: [WebDNA] COMMITDATABASE = in linux unix 64bits FastCGI version 8.6
 
Hi Terry
 
It is hard to work out who sent email to the  list now = that the =E2=80=9Cfrom" has changed.
 
 
The call is very simple, a url with = variables. 
 
 
admin-switch.dna?task=3Dswitch-6&dbid=3D6&dbidname=3DSM= -ID&dbname=3Dshippingmethods&dbfield=3DSM-ACTIVE&active=3DT
 
 
The receiving page is very simple = too.


[REPLACE = db=3D../data/[DBNAME].db&eq[DBIDNAME]datarq=3D[DBID]&max=3D1][!]
          &nb= sp;   [/!][DBFIELD]=3D[URL][DBVALUE][/URL][!]
[/!][/REPLACE]
 
 
The replace is 100% correct in the db = file if I open it up, the problem is that until I manually flush the dbs = it is not recognised.
 
I have tried putting in [CLOSEDATABASE = db=3D../data/[DBNAME].db] or [COMMITDATABASE = db=3D../data/[DBNAME].db] or even [FLUSHDATABASES] with no = resolution.
 
It is not the one db, I have another ajax update for another = db which has the same issue. I have not gone through the entire system = checking for others.
 
Kind regards
 
Stuart Tremain
Pharoah Lane Software
AUSTRALIA
 
 
 
 

 



On 19 Feb 2020, at 12:11, talk@webdna.us wrote:
 
Morning Stuart,
 
You mentioned =E2=80=9CI have include [FLUSHDATABASES] in the ajax call=E2=80=9D =E2=80=A6.a= m I correct to say that you are either doing a GET or POST Ajax call to = a file sitting on the server that has the tags to execute the flush = webdna tag?
 
If = so =E2=80=A6can share the ajax call script and the page called by it so = that I can try to assist you. It is indeed strange that the change is = stored in RAM but not committed into the DB even with all the settings = you mentioned. Regardless =E2=80=A6after the update, the uncommitted = change should still be showing up when called upon by other pages = relying on it.
 
Cheers TDn
 
From: talk@webdna.us <talk@webdna.us> 
Sent: Wednesday, February 19, = 2020 07:39 AM
To: WebDNA Talk List <talk@webdna.us>
Subject: [WebDNA] COMMITDATABASE in = linux unix 64bits FastCGI version 8.6
 
I am having an issue with a couple = of dbs.
 
Permissions are correct 775
Ownership is correct www-data:www-data
 
I am updating the db with an ajax call, I open the = db ofter it has been modified and the mod is there in the db.
 
The ajax call does a replace on the db.
 
There is no error reported from the ajax call.



The WebDNA preference is "Automatically commit databases to disk = after modification"
 
The problem is that another page on the site is dependant on the = new value. This new value is not being found.
 
I have include [FLUSHDATABASES] in the ajax call to = force the db to clear however it is still not finding the new value.
 
If I use the WebDNA admin to [FLUSHDATABASES] then = the page finds the new value.
 
Any ideas ?
 
Kind regards
 
Stuart Tremain
Pharoah Lane Software
AUSTRALIA
 
 
 
 

 

 
--------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail = to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
--------------------------------------------------------- = This message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
 
--------------------------------------------------------- = This message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail = to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7= =A7=EF=BF=BD=EF=BF=BD2=EF=BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C= =EF=BF=BD&=EF=BF=BDv=EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSED= R_^#<=D6=A5=EF=BF=BD=07=EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF= =BF=BD=EF=BF=BDm=EF=BF=BD&j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF= =BD=EF=BF=BD=1Em=EF=BF=BD=DA=BA=C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF= =BD = 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg

---------------------------------------------------------= This message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail = to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7=A7=EF=BF=BD=EF=BF=BD2=EF= =BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C=EF=BF=BD&=EF=BF=BDv= =EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSEDR_^#<=D6=A5=EF=BF=BD=07= =EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF=BF=BD=EF=BF=BDm=EF=BF=BD= &j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF=BD=EF=BF=BD=1Em=EF=BF=BD= =DA=BA=C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF=BD=0C= 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg
=

= --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --Apple-Mail=_AB73BE42-B83D-4F6A-90CC-B08C321CD539-- . Associated Messages, from the most recent to the oldest:

    
  1. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Terry Nair" 2020)
  2. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  3. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Terry Nair" 2020)
  4. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Donovan Brooke 2020)
  5. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  6. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Donovan Brooke 2020)
  7. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  8. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Scott @ Itsula" 2020)
  9. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Scott @ Itsula" 2020)
  10. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  11. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Scott @ Itsula" 2020)
  12. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  13. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  14. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Scott @ Itsula" 2020)
  15. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Brian Fries 2020)
  16. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Jym Duane 2020)
  17. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  18. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Terry Nair" 2020)
  19. Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
  20. RE: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 ("Terry Nair" 2020)
  21. [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version 8.6 (Stuart Tremain 2020)
2654 --Apple-Mail=_AB73BE42-B83D-4F6A-90CC-B08C321CD539 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Scott Thanks for the offer. At the moment the problem is on a dev server. I want to work out if = issue is server wide, site wide or just the two known dbs. I also want to test with different fcgi versions. The coding is 100% correct and the dbs are very small and simple - 20 = rows, 3 columns each. I will let you know of the outcome. =20 Kind regards Stuart Tremain Pharoah Lane Software AUSTRALIA webdna@plsoftware.com.au > On 20 Feb 2020, at 10:14, talk@webdna.us wrote: >=20 > Just to check, are there any particularly large DBs also in the mix on = that server instance, despite if they're part of this mix or not? If so = that could account for the delayed working response as per step 5 below, = assuming I've followed correctly. > =20 > If helpful I will try to replicate this end first thing in the morning = mate, am running 8.5.1 FCGI on CentOS > If you've any redacted test files that you're using, mail them over. > =20 > If it's super urgent and helpful and you're in the proverbial then = shout soonish and I'll attempt it tonight. > =20 > Regards, > Scott > =20 > From: talk@webdna.us > Sent: 19 February 2020 22:41 > To: WebDNA Talk List > Subject: Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI = version 8.6 > =20 > Hi Scott >=20 > My methodology: >=20 > 1) run the ajax >=20 > 2) open the db to ensure that changes have been made >=20 > 3) Clear browser cache, test the page that relies on the new value. = Repeat. >=20 > 4) No positive result from step 3, flush db from /WebDNA directory = link >=20 > 5) 2nd test of page that relies on the new value - page works properly = now with correct value. >=20 > I will be testing this across the other dbs in the site and dbs in = other sites that use the same version of the fcgi and a different = version of the fcgi. Currently I know of the problem in two dbs in the = same site >=20 > Kind regards >=20 > Stuart Tremain > Pharoah Lane Software > AUSTRALIA > webdna@plsoftware.com.au >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On 20 Feb 2020, at 03:34, talk@webdna.us = wrote: >>=20 >> Hi Stuart, >> =20 >> When you use Flush, to my (perhaps limited) understanding the data is = written to disk and purged from memory, and can take a few seconds at = times. Only then when another call to that DB is made is the DB reloaded = into memory. Perhaps the second call is happening before the flush has = completed? In this case, Commit would do it I gather. >> =20 >> I notice below you mentioned the use of Commit already also to no = avail. One check might be just to ensure that the DB name var is being = passed properly, as no error message would be generated if it wasn=E2=80=99= t, and the Commit wouldn=E2=80=99t show the drop in DB from memory on = the admin pages. >> =20 >> Just my 2cents chap. >> =20 >> BR >> Scott >> =20 >> =20 >> =20 >> From: talk@webdna.us >=20 >> Sent: Wednesday, February 19, 2020 1:32 AM >> To: WebDNA Talk List > >> Subject: Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI = version 8.6 >> =20 >> Hi Terry >> =20 >> It is hard to work out who sent email to the list now that the = =E2=80=9Cfrom" has changed. >> =20 >> =20 >> The call is very simple, a url with variables.=20 >> =20 >> =20 >> = admin-switch.dna?task=3Dswitch-6&dbid=3D6&dbidname=3DSM-ID&dbname=3Dshippi= ngmethods&dbfield=3DSM-ACTIVE&active=3DT >> =20 >> =20 >> The receiving page is very simple too. >>=20 >>=20 >> [REPLACE db=3D../data/[DBNAME].db&eq[DBIDNAME]datarq=3D[DBID]&max=3D1][= !] >> [/!][DBFIELD]=3D[url][DBVALUE][/URL][!] >> [/!][/REPLACE] >> =20 >> =20 >> The replace is 100% correct in the db file if I open it up, the = problem is that until I manually flush the dbs it is not recognised. >> =20 >> I have tried putting in [CLOSEDATABASE db=3D../data/[DBNAME].db] or = [COMMITDATABASE db=3D../data/[DBNAME].db] or even [flushdatabases] with = no resolution. >> =20 >> It is not the one db, I have another ajax update for another db which = has the same issue. I have not gone through the entire system checking = for others. >> =20 >> Kind regards >> =20 >> Stuart Tremain >> Pharoah Lane Software >> AUSTRALIA >> webdna@plsoftware.com.au >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >>=20 >>=20 >> On 19 Feb 2020, at 12:11, talk@webdna.us = wrote: >> =20 >> Morning Stuart, >> =20 >> You mentioned =E2=80=9CI have include [flushdatabases] in the ajax = call=E2=80=9D =E2=80=A6.am I correct to say that you are either doing a = GET or POST Ajax call to a file sitting on the server that has the tags = to execute the flush webdna tag? >> =20 >> If so =E2=80=A6can share the ajax call script and the page called by = it so that I can try to assist you. It is indeed strange that the change = is stored in RAM but not committed into the DB even with all the = settings you mentioned. Regardless =E2=80=A6after the update, the = uncommitted change should still be showing up when called upon by other = pages relying on it. >> =20 >> Cheers TDn >> =20 >> From: talk@webdna.us >=20 >> Sent: Wednesday, February 19, 2020 07:39 AM >> To: WebDNA Talk List > >> Subject: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI version = 8.6 >> =20 >> I am having an issue with a couple of dbs. >> =20 >> Permissions are correct 775 >> Ownership is correct www-data:www-data >> =20 >> I am updating the db with an ajax call, I open the db ofter it has = been modified and the mod is there in the db. >> =20 >> The ajax call does a replace on the db. >> =20 >> There is no error reported from the ajax call. >>=20 >>=20 >>=20 >> The WebDNA preference is "Automatically commit databases to disk = after modification" >> =20 >> The problem is that another page on the site is dependant on the new = value. This new value is not being found. >> =20 >> I have include [flushdatabases] in the ajax call to force the db to = clear however it is still not finding the new value. >> =20 >> If I use the WebDNA admin to [flushdatabases] then the page finds the = new value. >> =20 >> Any ideas ? >> =20 >> Kind regards >> =20 >> Stuart Tremain >> Pharoah Lane Software >> AUSTRALIA >> webdna@plsoftware.com.au >> =20 >> =20 >> =20 >> =20 >> =20 >>=20 >> =20 >> --------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us >> --------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us >> =20 >> --------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us = N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7=A7=EF=BF= =BD=EF=BF=BD2=EF=BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C=EF=BF=BD= &=EF=BF=BDv=EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSEDR_^#<=D6=A5=EF=BF= =BD=07=EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF=BF=BD=EF=BF=BDm=EF= =BF=BD&j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF=BD=EF=BF=BD=1Em=EF=BF=BD=DA=BA= =C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF=BD = 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list = talk@webdna.us To unsubscribe, E-mail to: = talk-leave@webdna.us archives: = http://www.webdna.us/page.dna?numero=3D55 = Bug Reporting: = support@webdna.us = N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7=A7=EF=BF= =BD=EF=BF=BD2=EF=BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C=EF=BF=BD= &=EF=BF=BDv=EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSEDR_^#<=D6=A5=EF=BF= =BD=07=EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF=BF=BD=EF=BF=BDm=EF= =BF=BD&j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF=BD=EF=BF=BD=1Em=EF=BF=BD=DA=BA= =C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF=BD=0C= 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg --Apple-Mail=_AB73BE42-B83D-4F6A-90CC-B08C321CD539 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Scott

Thanks for the = offer.

At the = moment the problem is on a dev server. I want to work out if issue is = server wide, site wide or just the two known dbs.
I also want to test with different = fcgi versions.

The coding is 100% correct and the dbs are very small and = simple - 20 rows, 3 columns each.

I will let you know of the = outcome.
 
Kind regards

Stuart Tremain
Pharoah Lane Software
AUSTRALIA







On 20 Feb 2020, at 10:14, talk@webdna.us wrote:

Just to = check, are there any particularly large DBs also in the mix on that = server instance, despite if they're part of this mix or not? If so that = could account for the delayed working response as per step 5 below, = assuming I've followed correctly.
 
If helpful I will try to replicate this end first thing in = the morning mate, am running 8.5.1 FCGI on CentOS
If you've any redacted test files that = you're using, mail them over.
 
If it's super urgent and helpful and you're in the proverbial = then shout soonish and I'll attempt it tonight.
 
Regards,
Scott
 
From: talk@webdna.us
Sent: 19 = February 2020 22:41
To: WebDNA Talk List
Subject: Re: [WebDNA] = COMMITDATABASE in linux unix 64bits FastCGI version 8.6
 
Hi Scott

My methodology:

1) run the ajax

2) open the db to ensure that changes = have been made

3) Clear browser cache, test the page that relies on the new = value. Repeat.

4) No positive result from step 3, flush db from /WebDNA = directory link

5) 2nd test of page that relies on the new value - page works properly = now with correct value.

I will = be testing this across the other dbs in the site and dbs in other sites = that use the same version of the fcgi and a different version of the = fcgi. Currently  I know of the problem in two dbs in the same = site

Kind = regards

Stuart = Tremain
Pharoah Lane Software
AUSTRALIA
webdna@plsoftware.com.au







On 20 = Feb 2020, at 03:34, talk@webdna.us wrote:

Hi Stuart,
 
When you use Flush, to my (perhaps limited) = understanding the data is written to disk and purged from memory, and = can take a few seconds at times. Only then when another call to that DB = is made is the DB reloaded into memory. Perhaps the second call is = happening before the flush has completed? In this case, Commit would do = it I gather.
 
I notice below you = mentioned the use of Commit already also to no avail. One check might be = just to ensure that the DB name var is being passed properly, as no = error message would be generated if it wasn=E2=80=99t, and the Commit = wouldn=E2=80=99t show the drop in DB from memory on the admin pages.
 
Just my 2cents chap.
 
BR
Scott
 
 
 
From: talk@webdna.us <talk@webdna.us> 
Sent: Wednesday, February 19, = 2020 1:32 AM
To: WebDNA Talk List <talk@webdna.us>
Subject: Re: [WebDNA] COMMITDATABASE = in linux unix 64bits FastCGI version 8.6
 
Hi Terry
 
It is hard to work out who sent email to the  list now = that the =E2=80=9Cfrom" has changed.
 
 
The call is very simple, a url with = variables. 
 
 
admin-switch.dna?task=3Dswitch-6&dbid=3D6&dbidname=3DSM= -ID&dbname=3Dshippingmethods&dbfield=3DSM-ACTIVE&active=3DT
 
 
The receiving page is very simple = too.


[REPLACE = db=3D../data/[DBNAME].db&eq[DBIDNAME]datarq=3D[DBID]&max=3D1][!]
          &nb= sp;   [/!][DBFIELD]=3D[url][DBVALUE][/URL][!]
[/!][/REPLACE]
 
 
The replace is 100% correct in the db = file if I open it up, the problem is that until I manually flush the dbs = it is not recognised.
 
I have tried putting in [CLOSEDATABASE = db=3D../data/[DBNAME].db] or [COMMITDATABASE = db=3D../data/[DBNAME].db] or even [flushdatabases] with no = resolution.
 
It is not the one db, I have another ajax update for another = db which has the same issue. I have not gone through the entire system = checking for others.
 
Kind regards
 
Stuart Tremain
Pharoah Lane Software
AUSTRALIA
 
 
 
 

 



On 19 Feb 2020, at 12:11, talk@webdna.us wrote:
 
Morning Stuart,
 
You mentioned =E2=80=9CI have include [flushdatabases] in the ajax call=E2=80=9D =E2=80=A6.a= m I correct to say that you are either doing a GET or POST Ajax call to = a file sitting on the server that has the tags to execute the flush = webdna tag?
 
If = so =E2=80=A6can share the ajax call script and the page called by it so = that I can try to assist you. It is indeed strange that the change is = stored in RAM but not committed into the DB even with all the settings = you mentioned. Regardless =E2=80=A6after the update, the uncommitted = change should still be showing up when called upon by other pages = relying on it.
 
Cheers TDn
 
From: talk@webdna.us <talk@webdna.us> 
Sent: Wednesday, February 19, = 2020 07:39 AM
To: WebDNA Talk List <talk@webdna.us>
Subject: [WebDNA] COMMITDATABASE in = linux unix 64bits FastCGI version 8.6
 
I am having an issue with a couple = of dbs.
 
Permissions are correct 775
Ownership is correct www-data:www-data
 
I am updating the db with an ajax call, I open the = db ofter it has been modified and the mod is there in the db.
 
The ajax call does a replace on the db.
 
There is no error reported from the ajax call.



The WebDNA preference is "Automatically commit databases to disk = after modification"
 
The problem is that another page on the site is dependant on the = new value. This new value is not being found.
 
I have include [flushdatabases] in the ajax call to = force the db to clear however it is still not finding the new value.
 
If I use the WebDNA admin to [flushdatabases] then = the page finds the new value.
 
Any ideas ?
 
Kind regards
 
Stuart Tremain
Pharoah Lane Software
AUSTRALIA
 
 
 
 

 

 
--------------------------------------------------------- This = message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail = to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
--------------------------------------------------------- = This message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
 
--------------------------------------------------------- = This message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail = to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7= =A7=EF=BF=BD=EF=BF=BD2=EF=BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C= =EF=BF=BD&=EF=BF=BDv=EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSED= R_^#<=D6=A5=EF=BF=BD=07=EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF= =BF=BD=EF=BF=BDm=EF=BF=BD&j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF= =BD=EF=BF=BD=1Em=EF=BF=BD=DA=BA=C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF= =BD = 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg

---------------------------------------------------------= This message is sent to you because you are subscribed to the mailing = list talk@webdna.us To unsubscribe, E-mail = to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us
N=18=EF=BF=BD=EF=BF=BD,j=07=EF=BF=BD=C7=A7=EF=BF=BD=EF=BF=BD2=EF= =BF=BD=EF=BF=BD=EF=BF=BDq=EF=BF=BD{*.j=EF=BF=BD=1C=EF=BF=BD&=EF=BF=BDv= =EF=BF=BD-=EF=BF=BD=E9=9A=8AX=EF=BF=BDX#<^_NSEDR_^#<=D6=A5=EF=BF=BD=07= =EF=BF=BDvv=EF=BF=BD:.=EF=BF=BD=CB=9B=EF=BF=BD=EF=BF=BD=EF=BF=BDm=EF=BF=BD= &j)m#<^_NSEDR_^#<=D6=A5=EF=BF=BDW=EF=BF=BD=EF=BF=BD=1Em=EF=BF=BD= =DA=BA=C6=ABr=18=EF=BF=BDz=EF=BF=BDm=EF=BF=BD=EF=BF=BD=0C= 0y=EF=BF=BDgj=EF=BF=BD?=EF=BF=BD=1Evv=EF=BF=BDg=EF=BF=BD=0Ey=06=EF=BF=BD=11= z=EF=BF=BD+=EF=BF=BD)=EF=BF=BD=EF=BF=BDi=EF=BF=BDpy=EF=BF=BDg
=
= --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list talk@webdna.us To unsubscribe, E-mail to: talk-leave@webdna.us archives: http://www.webdna.us/page.dna?numero=3D55 Bug Reporting: support@webdna.us --Apple-Mail=_AB73BE42-B83D-4F6A-90CC-B08C321CD539-- . Stuart Tremain

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Nesting format tags (1997) WebCat2: Items xx to xx shown, etc. (1997) Email notification to one of multiple vendors ? (1997) form data submission gets truncated (1997) Image maps/Webcat (1997) Trouble serving graphics on protected templates (1998) Been meaning to ask... (1997) multi-paragraph fields (1997) [WebDNA] Sorry WebDNA server not running (2014) Wanted: Broader string manipulation functions (1997) WCf2 and nested tags (1997) Mac Programs (1998) I give up!! (1997) maybe even an easier plan to satisfy need for solid tech support? (2000) Initiating NewCart (1997) E-mail loop ! (1997) Summ=T Problem (1997) Need relative path explanation (1997) [SearchString] usage (1997) ShowCart (2001)