Regarding SQLiteDBMS:
During shutdown Puppy 2.17.1 did not save the files in /var/sqlitedbms/. Should this have happened? The other sqlitedbms files were saved.
zygo: Regarding the Opera HTML display error try SeaMonkey. I also had a problem with the java client but lost my install (above) before I could confirm the problem.
Igo AtM: Perhaps you could start a thread dedicated to SQLiteDBMS with your next release.
I really like the idea of SQLiteDBMS: using sqlite3 over a web interface. I have played around with a bash script front end for sqlite3 but a web interface is a better approach for many reasons. I look forward to future releases.
Dotpet Package of Motion (Webcam Video Surveillance)
Hi brucehohl
Thanks for your response it is for the issues you have raised that SQLiteDBMS was put out in the first place so appreciated
Anyway I shall setup a test usb for just this situation and later tonight upgrade the pet to switch the server root to /root/my-documents
As far as the issue with Opera zygo one of the main problems with the original version of SQLiteDBMS was that the client interfaces were made to service IE6 they do not even do that very well. I'm in the process of rewriting the entire client both HTML and javascript which should take about a week before the first versions appear. The pet I put up was only tested on seamonkey as the included browser on puppy but I guarantee the version I am writing is WC3 complaint. As far as the data returned in the HTML browser it is raw XML with no native style sheet so at best it will return a unformatted text document. Again this will be upgraded very soon.
I have already some fixes for issues relating to the javascript version not refreshing data correctly mainly these are filtering through to the existing client as I develop the new version. I don't see the sense in delaying the release of the new one to spend time trying to repair the existing client as it's code base is not so good. I will feed these into the pet as quickly as I can so check back or tag the thread if you want the new versions
thanks for you feed back
Thanks for your response it is for the issues you have raised that SQLiteDBMS was put out in the first place so appreciated
I normally run a development version of puppy from a low spec laptop in order that pet's generated should be backward compatible but as a hard drive install it of course preserves var on reboot the other test machines I use I run from a usb and I never save as this ensures I do not taint the test with left over libs from other packages. I am not sure but thinking about you lost data it is likely var is not one of the locations that puppy preserves none install dir's when exiting So I may need to find another home for the data the safest and most obvious is root/my-documents/sqlitedbms. Out of interest did it preserve the var/log/sqlitedbms dir ?During shutdown Puppy 2.17.1 did not save the files in /var/sqlitedbms/. Should this have happened? The other sqlitedbms files were saved.
Anyway I shall setup a test usb for just this situation and later tonight upgrade the pet to switch the server root to /root/my-documents
As far as the issue with Opera zygo one of the main problems with the original version of SQLiteDBMS was that the client interfaces were made to service IE6 they do not even do that very well. I'm in the process of rewriting the entire client both HTML and javascript which should take about a week before the first versions appear. The pet I put up was only tested on seamonkey as the included browser on puppy but I guarantee the version I am writing is WC3 complaint. As far as the data returned in the HTML browser it is raw XML with no native style sheet so at best it will return a unformatted text document. Again this will be upgraded very soon.
I have already some fixes for issues relating to the javascript version not refreshing data correctly mainly these are filtering through to the existing client as I develop the new version. I don't see the sense in delaying the release of the new one to spend time trying to repair the existing client as it's code base is not so good. I will feed these into the pet as quickly as I can so check back or tag the thread if you want the new versions
thanks for you feed back
Issues with directory persistence
Thanks Barry for raising the profile on this by the way. I just hope I can deal with the immediacy of the demand. It has already served a very useful purpose by highlighting the dir/program persistence issue (which also effects motionMon by the way ) I am in the habit of logging to the standard Linux log locations as with program generated web data which I like to locate in a standard safe if possible sandbox location.
I can understand very well why it would be removed on a Puppy installation. I once had to deal with a program which went ballistic and generated 4 gigs of log garbage in a 24hr period. So what would be the preferred choice for this data on Puppy?
For now I shall move the data dir to /root/my-documents/sqlitedbms but the logs ? SQLiteDBMS drops out on boot up if the log dir has been zapped And I'm not overly keen on placing logs which aren't needed until there are needed. In a random application selected hide away. So what would be the recommended location?
One advantage of this is it has made me rethink an application Puppy type install As such I shall add options to tie down log reporting rotation and g-zipping to the configuration options.
Next release probably around Tuesday assuming I can get the free time
I can understand very well why it would be removed on a Puppy installation. I once had to deal with a program which went ballistic and generated 4 gigs of log garbage in a 24hr period. So what would be the preferred choice for this data on Puppy?
For now I shall move the data dir to /root/my-documents/sqlitedbms but the logs ? SQLiteDBMS drops out on boot up if the log dir has been zapped And I'm not overly keen on placing logs which aren't needed until there are needed. In a random application selected hide away. So what would be the recommended location?
One advantage of this is it has made me rethink an application Puppy type install As such I shall add options to tie down log reporting rotation and g-zipping to the configuration options.
Next release probably around Tuesday assuming I can get the free time
Puppy SQLiteDBMS 5.1.2
I have updated SQLiteDBMS to a version that saves to /root/my-documents This should resolve the issue with data persistence across reboots. I have started to use a little bit of version tracking so now we have 5.1.2 all updates will have the 5.1.xx with xx representing the latest version until I post the client I am working on at which point we will become 5.2.xx and when stable 6.xx.xx (this so puppy people know what to expect from updates ). There are a number of small code fixes to this version that may make the current client more responsive. The issues with the failure of the client to refresh data ie screens not uploading are cache clearing and should resolve themselves when the new client comes on line.
For people following this thread reference motionMon I'm sort of holding until SQLiteDBMS is functioning with its new client but it is not forgotten. I may move the majority of info re motionMon to the wiki where I have been given some space.
For people following this thread reference motionMon I'm sort of holding until SQLiteDBMS is functioning with its new client but it is not forgotten. I may move the majority of info re motionMon to the wiki where I have been given some space.
Igo AtM: I encountered a few problems with the new SQLiteDBMS package under Puppy 2.17.1 as follows:
(1) HTML client:
In the HTML version of the client "select * from contacts;" produces the following using SeaMonkey:
This XML file does not appear to have any style information associated with it. The document tree is shown below.
−
<response>
<changes>0</changes>
<rowid>0</rowid>
<rows>4</rows>
<time>0.018052</time>
−
<columns>
<columnname>idx</columnname>
<columnname>Name</columnname>
<columnname>add1</columnname>
<columnname>add2</columnname>
<columnname>add3</columnname>
<columnname>add4</columnname>
<columnname>add5</columnname>
<columnname>addpc</columnname>
<columnname>phone_ll</columnname>
<columnname>phone_m</columnname>
</columns>
−
<row>
<data>1</data>
<data>plop</data>
<data>101 Numpty lane</data>
<data>Isadump</data>
<data>Plankton Dirigable</data>
<data>Utopia</data>
<data>-</data>
<data>PO Box 134567</data>
<data>0989-0870987</data>
<data>0777-1324321</data>
</row>
etc ...
Note using Opera the result is as follows:
0040.113281 idxNameadd1add2add3add4add5addpcphone_llphone_m 1plop101 Numpty laneIsadumpPlankton DirigableUtopia-PO Box 1345670989-08709870777-1324321 2glop102 Numpty LaneIsadumpPlankton DirigableUtopia-Box 10690455-0022734560778-546778 3goop103 Numpty LaneWaddermezzLahula-hantaUtopia---- 4loop104 Numpty HouseBlazewaterWiken-by-trogYammamoto-444
(2) Java client:
From the java client I am unable to type a query in the "query box" using SeaMonkey or Opera.
When I attempted a remote connection to the java client I was not offered any databases to choose from on the drop down list, thus, could not connect.
(3) HTML client note:
It would be nice to have a drop down list of available databases like on the java client.
Regards, BH
(1) HTML client:
In the HTML version of the client "select * from contacts;" produces the following using SeaMonkey:
This XML file does not appear to have any style information associated with it. The document tree is shown below.
−
<response>
<changes>0</changes>
<rowid>0</rowid>
<rows>4</rows>
<time>0.018052</time>
−
<columns>
<columnname>idx</columnname>
<columnname>Name</columnname>
<columnname>add1</columnname>
<columnname>add2</columnname>
<columnname>add3</columnname>
<columnname>add4</columnname>
<columnname>add5</columnname>
<columnname>addpc</columnname>
<columnname>phone_ll</columnname>
<columnname>phone_m</columnname>
</columns>
−
<row>
<data>1</data>
<data>plop</data>
<data>101 Numpty lane</data>
<data>Isadump</data>
<data>Plankton Dirigable</data>
<data>Utopia</data>
<data>-</data>
<data>PO Box 134567</data>
<data>0989-0870987</data>
<data>0777-1324321</data>
</row>
etc ...
Note using Opera the result is as follows:
0040.113281 idxNameadd1add2add3add4add5addpcphone_llphone_m 1plop101 Numpty laneIsadumpPlankton DirigableUtopia-PO Box 1345670989-08709870777-1324321 2glop102 Numpty LaneIsadumpPlankton DirigableUtopia-Box 10690455-0022734560778-546778 3goop103 Numpty LaneWaddermezzLahula-hantaUtopia---- 4loop104 Numpty HouseBlazewaterWiken-by-trogYammamoto-444
(2) Java client:
From the java client I am unable to type a query in the "query box" using SeaMonkey or Opera.
When I attempted a remote connection to the java client I was not offered any databases to choose from on the drop down list, thus, could not connect.
(3) HTML client note:
It would be nice to have a drop down list of available databases like on the java client.
Regards, BH
Current Client Feedback
Again thanks for your feedback brucehohl
re the issues you raised
What you are seeing is the server response to the query just dumped into the lower frame. There is no attempt to format it at all. it is left to the capabilities of the individual browser as to how it will display the data. In a way this makes sens as by definition you are using a basic HTML connection hence the assumption is there is no browser capability for scripting js or css. At the base level the server is responding as if you have connected via a text terminal. However as is shown by the seamonkey output there is xml formating piped to the browser which in the case of opera, the browser has striped the tags and just left the text content. I am of a mind to leave this functionality in the version I am building as it dose offer the lowest level text access to the data. This also then would reflect on the issue of having a drop down database selector in the HTML browser as if it is designed for basic access then there would be no way to process the unique data in the form after log on.
As a remedy to these issues what is in the new version is a halfway house which assumes a none javascript browser that is css capable or code that will degrade to an acceptable form in a none css browser. This version dose parse the returned data (or at least the server sends headers that allows it to be dealt with in the browser DOM ) Also selectors are provided for db selection as well as key word SQL selection. As this is being coded into the new version it dose not seem worthwhile correcting it in the existing version.
Again thanks for your feed back. By the way when I post the bugfix version (should be 0.5.1.3 I think ) you should upload it as I have picked up a bug in the server that causes data/page transmissions above 32k to be corrupted that can give unknown/undesirable effects on your browser so it needs replacing.
Have opened a new topic for SQLiteDBMS link below (A new version awaits)
http://www.murga-linux.com/puppy/viewto ... 211#162211
re the issues you raised
One of the problems with the existing HTML client is it only returns raw data from the database via the server and directed to the client browsers lower frame.(1) HTML client:
In the HTML version of the client "select * from contacts;" produces the following using SeaMonkey:
What you are seeing is the server response to the query just dumped into the lower frame. There is no attempt to format it at all. it is left to the capabilities of the individual browser as to how it will display the data. In a way this makes sens as by definition you are using a basic HTML connection hence the assumption is there is no browser capability for scripting js or css. At the base level the server is responding as if you have connected via a text terminal. However as is shown by the seamonkey output there is xml formating piped to the browser which in the case of opera, the browser has striped the tags and just left the text content. I am of a mind to leave this functionality in the version I am building as it dose offer the lowest level text access to the data. This also then would reflect on the issue of having a drop down database selector in the HTML browser as if it is designed for basic access then there would be no way to process the unique data in the form after log on.
As a remedy to these issues what is in the new version is a halfway house which assumes a none javascript browser that is css capable or code that will degrade to an acceptable form in a none css browser. This version dose parse the returned data (or at least the server sends headers that allows it to be dealt with in the browser DOM ) Also selectors are provided for db selection as well as key word SQL selection. As this is being coded into the new version it dose not seem worthwhile correcting it in the existing version.
There is a known issue with the js client and the SQL query screen A fix will be on its way either today or early tomorrow.(2) Java client:
From the java client I am unable to type a query in the "query box" using SeaMonkey or Opera.
With the log in screen it will sometimes not refresh data to the client properly as a simple resolution to this if you select cancel and open out the side bar clicking log in from there and you should see the databases (every second time ???). Its a kinda weird issue as when I look at the debug output for the server response to the client there is no difference in data between a good and bad log on. On the bright side it is not an issue in the new version where a correct document type is sent with the page so I am assuming it as an issue with that or just uncleared data buffers in the client jsWhen I attempted a remote connection to the java client I was not offered any databases to choose from on the drop down list, thus, could not connect.
Again thanks for your feed back. By the way when I post the bugfix version (should be 0.5.1.3 I think ) you should upload it as I have picked up a bug in the server that causes data/page transmissions above 32k to be corrupted that can give unknown/undesirable effects on your browser so it needs replacing.
Have opened a new topic for SQLiteDBMS link below (A new version awaits)
http://www.murga-linux.com/puppy/viewto ... 211#162211