For those of you using or thinking of using a php based tinywebdb, I have, with some help and encouragement from @Juan_Antonio, come up with a data changed event solution.
You see this event in use with CloudDB and FirebaseDB components, and believe what I have devised follows a similar approach of keeping a connection open to the data, watching for changes. In php terms is is called "long polling". The original concept comes from here:
Try as I might, I could not get the caching to switch off on the webviewer, in order to use the javascript (as above) and the webviewstring to return data to the app, so decided to use a web component instead to replace the client side coding. Thus, all that is needed is the php file on the server, with any other php files and the database file/s, and a few blocks in the app.
You need:
The php file:
<?php
set_time_limit(0);
$data_source_file = 'database.json';
while (true) {
$last_ajax_call = isset($_GET['timestamp']) ? (int)$_GET['timestamp'] : null;
clearstatcache();
$last_change_in_data_file = filemtime($data_source_file);
if ($last_ajax_call == null || $last_change_in_data_file > $last_ajax_call) {
$data = file_get_contents($data_source_file);
$result = array(
'data_from_file' => $data,
'timestamp' => $last_change_in_data_file
);
$json = json_encode($result);
echo $json;
break;
} else {
sleep( 1 );
continue;
}
}
?>
You will have to replace the name of the database file with your own database file if different. In the example above it is called database.json. You could feed this as a parameter to the php file if you have more than one database running...
For the blocks:
A global variable for the timestamp
your server URL and the php file name
a call to the php url from the web component (note: my "server.php" is called "dataChanged.php"), with the timestamp parameter
and then the web gotText block, which handles the returned json array to output the changed data and set the new timestamp, with a looping call to the web component again (which will sit and wait for a response / change in data). I found in testing that I needed to set the responseContent to a variable/local variable for the dictionary processing to work. For some reason this wouldn't work directly.
That is all that is required. The web component will keep the connection open until a change is made to the database, then report back with new data, and then open up the connection again, wait for a change....
Probably some work here for @ABG to do a dictionary comparison to find exactly what changed 
