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:

A quickie question (1997) RE: [WebDNA] Use of MySQL with WebDNA (2010) Redirect and Window Size (2000) restarting service remotely on NT (1997) Search Question (2000) WebDNA Solutions ... sorry! (1997) random in arizona (2003) Problems with webcat 2.01 for NT (1997) Dates - Search and Sorting (1999) European Dates (1998) Bug at start of Apache 2 with iTools 7 (2003) access denied problem (1997) RedHat Linux glibc version 2.1.2 or higher required (2000) ConverChars (1999) Server crash (1997) WebCat2b15MacPlugin - showing [math] (1997) [OT] "Hacker Safe" (2007) Encryption Question (2006) Large sites (2003) Configuring E-mail (1997)