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 = 115030
interpreted = N
texte = 2658 --Apple-Mail=_C228C42E-2DB6-40DB-8923-C792A8AC0C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stuart, Extending Terry=E2=80=99s question=E2=80=A6 you replied: =E2=80=9C >>>> 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] " Just for clarification.. did you put the [flushdatabase] (or alike) on = that 'receiving page=E2=80=99 below the replace? You may need to use a [waitforfile..] with a timeout depending on your = process flow.=20 Posting your (simplified) code could help.=20 Donovan > On Feb 19, 2020, at 5:45 PM, talk@webdna.us wrote: >=20 > No a straight WebDNA search. >=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 10:36, talk@webdna.us = wrote: >>=20 >> Is the second page calling via AJAX? >> If so, are you resolving a JS promise when the state has changed to 4 = & 200? If not, could just be JS async timing.. >> =20 >> From: talk@webdna.us >> Sent: 19 February 2020 23:27 >> To: WebDNA Talk List >> Subject: Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI = version 8.6 >> =20 >> Hi Scott >>=20 >> Thanks for the offer. >>=20 >> 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. >>=20 >> I also want to test with different fcgi versions. >>=20 >> The coding is 100% correct and the dbs are very small and simple - 20 = rows, 3 columns each. >>=20 >> I will let you know of the outcome. >> =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 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 = 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 >=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 Donovan Brooke Owner - EUCA Iola, WI 54945 --Apple-Mail=_C228C42E-2DB6-40DB-8923-C792A8AC0C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Stuart,

Extending = Terry=E2=80=99s question=E2=80=A6  you replied:
=E2=80=9C
The receiving page is very simple too.


[REPLACE = db=3D../data/[DBNAME].db&eq[DBIDNAME]datarq=3D[DBID]&max=3D1][!]
        &= nbsp;     [/!][DBFIELD]=3D[URL][DBVALUE][/URL][!]
[/!][/REPLACE]
"

Just for clarification.. did you put = the [flushdatabase] (or alike) on that 'receiving page=E2=80=99 below = the replace?

You= may need to use a  [waitforfile..] with a timeout depending on = your process flow. 

Posting your (simplified) code could help. 

Donovan



On Feb 19, 2020, at 5:45 PM, talk@webdna.us wrote:

No a straight WebDNA = search.

Kind = regards

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







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

Is the = second page calling via AJAX?
If so, = are you resolving a JS promise when the state has changed to 4 & = 200? If not, could just be JS async timing..
 
From: talk@webdna.us
Sent: 19 = February 2020 23:27
To: WebDNA Talk List
Subject: Re: [WebDNA] = COMMITDATABASE in linux unix 64bits FastCGI version 8.6
 
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
webdna@plsoftware.com.au







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=3D= SM-ID&dbname=3Dshippingmethods&dbfield=3DSM-ACTIVE&active=3DT<= o:p class=3D"">
 
 
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
webdna@plsoftware.com.au
 
 
 
 

 



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=BD= v=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
=

---------------------------------------------------------= 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=BD= v=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

Donovan Brooke
Owner - = EUCA
Iola, WI 54945



= --------------------------------------------------------- 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=_C228C42E-2DB6-40DB-8923-C792A8AC0C97-- . 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)
2658 --Apple-Mail=_C228C42E-2DB6-40DB-8923-C792A8AC0C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stuart, Extending Terry=E2=80=99s question=E2=80=A6 you replied: =E2=80=9C >>>> 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] " Just for clarification.. did you put the [flushdatabase] (or alike) on = that 'receiving page=E2=80=99 below the replace? You may need to use a [waitforfile..] with a timeout depending on your = process flow.=20 Posting your (simplified) code could help.=20 Donovan > On Feb 19, 2020, at 5:45 PM, talk@webdna.us wrote: >=20 > No a straight WebDNA search. >=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 10:36, talk@webdna.us = wrote: >>=20 >> Is the second page calling via AJAX? >> If so, are you resolving a JS promise when the state has changed to 4 = & 200? If not, could just be JS async timing.. >> =20 >> From: talk@webdna.us >> Sent: 19 February 2020 23:27 >> To: WebDNA Talk List >> Subject: Re: [WebDNA] COMMITDATABASE in linux unix 64bits FastCGI = version 8.6 >> =20 >> Hi Scott >>=20 >> Thanks for the offer. >>=20 >> 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. >>=20 >> I also want to test with different fcgi versions. >>=20 >> The coding is 100% correct and the dbs are very small and simple - 20 = rows, 3 columns each. >>=20 >> I will let you know of the outcome. >> =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 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 = 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 >=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 Donovan Brooke Owner - EUCA Iola, WI 54945 --Apple-Mail=_C228C42E-2DB6-40DB-8923-C792A8AC0C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Stuart,

Extending = Terry=E2=80=99s question=E2=80=A6  you replied:
=E2=80=9C
The receiving page is very simple too.


[REPLACE = db=3D../data/[DBNAME].db&eq[DBIDNAME]datarq=3D[DBID]&max=3D1][!]
        &= nbsp;     [/!][DBFIELD]=3D[url][DBVALUE][/URL][!]
[/!][/REPLACE]
"

Just for clarification.. did you put = the [flushdatabase] (or alike) on that 'receiving page=E2=80=99 below = the replace?

You= may need to use a  [waitforfile..] with a timeout depending on = your process flow. 

Posting your (simplified) code could help. 

Donovan



On Feb 19, 2020, at 5:45 PM, talk@webdna.us wrote:

No a straight WebDNA = search.

Kind = regards

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







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

Is the = second page calling via AJAX?
If so, = are you resolving a JS promise when the state has changed to 4 & = 200? If not, could just be JS async timing..
 
From: talk@webdna.us
Sent: 19 = February 2020 23:27
To: WebDNA Talk List
Subject: Re: [WebDNA] = COMMITDATABASE in linux unix 64bits FastCGI version 8.6
 
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
webdna@plsoftware.com.au







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=3D= SM-ID&dbname=3Dshippingmethods&dbfield=3DSM-ACTIVE&active=3DT<= o:p class=3D"">
 
 
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
webdna@plsoftware.com.au
 
 
 
 

 



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=BD= v=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
=

---------------------------------------------------------= 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=BD= v=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

Donovan Brooke
Owner - = EUCA
Iola, WI 54945



= --------------------------------------------------------- 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=_C228C42E-2DB6-40DB-8923-C792A8AC0C97-- . Donovan Brooke

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:

Multiple SSL Keys (1998) If search results are blank... (2003) WebCat2.0 [format thousands .0f] no go (1997) group searching problem (2002) Editing the search string (1997) Webmerchant (1999) Speed Optimization - Mac (1997) my price won't move (1997) WebDNA with WebStar V (2003) [WebDNA] [BULK] Windows XP Pro Success! (2008) HTML editing and webcatalog (2000) serial number dishing (1997) REPOST: WebCat & WebSTAR V (2002) WebCat2 - [format thousands] (1997) A better WebCat whois (was [OT] Domain Name Scam) (2000) Encrypt Problems (2000) Big Databases (1997) [include ...] behavior (1997) Pull down menu for categories (2000) Daze to Dates (1998)