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
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][!]
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.
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.
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.