Writing a Front End for Claims_DB Part 6 - Closing Notes
This content was originally posted to benscomputer.no-ip.org
Writing a Front End for Claims_DB - Part 5
- gen_report.sh
In this tutorial we have inserted a Database into the Claims_DB system and created a simple front end, users can add records and run a pre-defined query.
There are however a few caveats within this tutorial, and within the Claims_DB system itself.
Because of the use of temporary files within the processing functions of this tutorial, only one user can access your system at one time. Two simultaneous connections could lead to a data clash, this is currently also a problem within Claims_DB itself, and one that is being given a high priority for the next release.
If you are writing front ends for yourself, it is advised that you devise a way to avoid a clash of temporary files within the front-end, this could be implemented by appending the remote hostname to the filename of the temporary file, or simply by loading everything into variables instead.
If you can code around this issue, then when the next release of the database engine is made you should have a functioning multi-user system.
You will also note that we did not provide a front-end page for the removal or editing of records. This is because the engine doesn't yet support that functionality very well, although it is improving. It is possible to DROP a record, or edit it from a front-end but it is a dangerous functionality.
If you require this functionality try something along the lines of the following
Take good note of the comments, and test any implementation very carefully! It would be very easy to hose the entire table this way. If you were using this method to edit a record, you would then call Claims_DB as if you were adding the record for the first time.
There is a great deal more that you can do, the query-line call above is very useful if you wish to create a form or report to find a record by its Primary Key.
You should also note that the GET method of submitting forms is only really useful for small forms, both browsers and Webservers can only accept URL's of a limited length, so large forms, or forms with a lot of input will not work. Internet Explorer has a particularly short length, so if you implement using the GET method and the submit button doesn't seem to work, try re-submitting from Firefox or Opera.
For long forms use the POST method, though you will probably find it easier to parse POST data using Perl or PHP.
Be aware that long reports can take quite some time to generate, if anyone can find a faster method than the one shown on the previous page be sure to let me know!!!!
To make these scripts 'live' place them into your webservers CGI folder, and ensure that they are executable by whatever user your server daemon runs as.
A tarball containing copies of all the scripts we've written today can be obtained from here.
In this tutorial we have inserted a Database into the Claims_DB system and created a simple front end, users can add records and run a pre-defined query.
There are however a few caveats within this tutorial, and within the Claims_DB system itself.
Because of the use of temporary files within the processing functions of this tutorial, only one user can access your system at one time. Two simultaneous connections could lead to a data clash, this is currently also a problem within Claims_DB itself, and one that is being given a high priority for the next release.
If you are writing front ends for yourself, it is advised that you devise a way to avoid a clash of temporary files within the front-end, this could be implemented by appending the remote hostname to the filename of the temporary file, or simply by loading everything into variables instead.
If you can code around this issue, then when the next release of the database engine is made you should have a functioning multi-user system.
You will also note that we did not provide a front-end page for the removal or editing of records. This is because the engine doesn't yet support that functionality very well, although it is improving. It is possible to DROP a record, or edit it from a front-end but it is a dangerous functionality.
If you require this functionality try something along the lines of the following
#!/bin/bash
#
# Deletes a record from the table - DANGEROUS
#
# Copyright Ben Tasker 2009
# Released under the GNU GPL
# See http://benscomputer.no-ip.org/LICENSE for details
DBNAME="Sample_DB"
# Get your QueryString and store it in the variable COL1
# Store the Column that your QueryString appears in in COLNUMBER
# Best to only use Primary Keys for this code
DBROOT="$DBNAME" TABLE="Catalogue" "$CLAIMS_PROGS"bin/read_records_claims.sh -query-line "$COL1" $COLNUMBER > /tmp/LINENO.tmp
LINE_NUMBER=$( cat /tmp/LINENO.tmp )
READ_LINE=$( sed -n "$LINE_NUMBER"p "$CLAIMS_PROGS"/db/"$DBNAME"/Catalogue.csv )
cat "$CLAIMS_PROGS"/db/"$DBNAME"/Catalogue.csv | grep -v "$READ_LINE" > /tmp/CLAIMSTMP.db
cat /tmp/CLAIMSTMP.db > "$CLAIMS_PROGS"/db/"$DBNAME"/Catalogue.csv
Take good note of the comments, and test any implementation very carefully! It would be very easy to hose the entire table this way. If you were using this method to edit a record, you would then call Claims_DB as if you were adding the record for the first time.
There is a great deal more that you can do, the query-line call above is very useful if you wish to create a form or report to find a record by its Primary Key.
You should also note that the GET method of submitting forms is only really useful for small forms, both browsers and Webservers can only accept URL's of a limited length, so large forms, or forms with a lot of input will not work. Internet Explorer has a particularly short length, so if you implement using the GET method and the submit button doesn't seem to work, try re-submitting from Firefox or Opera.
For long forms use the POST method, though you will probably find it easier to parse POST data using Perl or PHP.
Be aware that long reports can take quite some time to generate, if anyone can find a faster method than the one shown on the previous page be sure to let me know!!!!
To make these scripts 'live' place them into your webservers CGI folder, and ensure that they are executable by whatever user your server daemon runs as.
A tarball containing copies of all the scripts we've written today can be obtained from here.
