Gary Stephenson <gary[AT]stephensong[DOT]com[DOT]au>
GDBU is a program allowing the creation, maintenance and manipulation of database tables in either the FoxPro DBF/CDX/FPT format or any supported ODBC data source (at the moment Access, MS-SQL 2000 and 2005).
GDBU is dedicated to the idea of declarative programming using XML. As such, it attempts to allow for the specification and deployment of complete applications using no other tool than GDBU itself (in particular no compiler), and the various XML documents used to specify database schema, screen layouts, message formats and so on. Of these, the only one that is maintained externally is that specifying the database schema and connection parameters - all others are contained within the database itself.
GDBU is also intended to provide a working example of the sorts of things that can be achieved using the OxGUI, ObjectXB and XTX libraries. As such it has many features not generally found in tools of this nature, such as support for relational algebra operations, dynamic relations, integrated form designer, runtime database schemas and much more besides.
GDBU also represents my prime test case for verifying the functionality of the OxIDE transpiler . Sooner or later there will an IronPython version of GDBU which will serve as proof that the OxIDE transpiler is correct and fully functional.
In contrast to just about everything else on this site, GDBU is not open-source software, nor is it free. Whilst most of the source code is open-source and included as part of the various free libraries downloadable from this site, the ODBC connection uses a modified commercial 3P library which I am not at liberty to distribute source for. In addition, the main driver routines are not provided elsewhere.
A 30-day time-limited version of GDBU can be downloaded from here. If you find it useful, and wish to continue using it, you can register it from the Payments page.
I have intentionally done nothing to prevent (nor even to trace) you downloading GDBU as many times as you wish to do so, so the time-trial period thing is really more of a suggestion than a demand! If you are so poor that you cannot afford to pay for GDBU, but wish to continue using it you can just download the demo again. Alternatively, you can send me an email requesting a non time-limited version, and I will (most probably) oblige. I do this because I know all too well what it is like to be unable to afford to pay for software tools (albeit that you would prefer to be able to do so).
Unfortunately, GDBU is still not very well documented (as you've probably gathered by now, documentation is not one of my strong suits. :-). Instead, GDBU comes packaged with a sample application called CROX (it's not a crock ;-), which attempts to demonstrate many of it's features. Basically, CROX is the application I use to run the backend of the website - customer information, invoicing, receipts etc (the "CR" stands for "Customer Relations" - not that I actually have any such things as "Customers" , but I've heard tell of them, and I believe that others actually have them ;-).
To get started, edit the provided CROX.xml schema file to contain appropriate parameters for your database (in the DATASOURCE element), and, if using a DBMS, use whatever utility you normally use to create an empty database with the matching name. Then run:
C:\GDBU> gdbu /schema:crox.xml /alter /import:croxdemo.xml
where the /schema switch specifies the schema file to be used (and is always required), and the /alter switch tells GDBU to go ahead and alter the structure of the database to match that specified in the schema.
The /import switch instructs GDBU to import the data contained in the specified file into the database. GDBU provides an HTML based help browsing and editing facility, and the "croxdemo.xml" file populates the database with an initial help set, and a couple of example forms.
One day I will get round to writing up the Relational Algebra operators properly. In the meantime I refer the interested reader to the chapter 6 of Chris Date's "Introduction to Database Systems", and also to Data and Darwen's "Foundations for future Database Systems - the Third Manifesto".
It should be remembered that an algebraic operation *always* return an entirely new table (using the internal RAM based ArrayDBE engine from ObjectXB). They never modify an existing table! Filters and pseudo-projections (columns can be optionally hidden using the Display->Columns menu option) can be used to restrict the range of columns and rows that are used as input to the operation. For those operations involving a second table (such as Join and Union) there is (currently) no way of restricting or projecting that second table. To achieve this, that table will need to pre-prepared to contain the right data prior to executing the operation.
Candidate Keys are inferred for each operation. Note that all operations enforce the relational requirement of no duplicate rows. If no candidate keys can be inferred, the system creates a default one consisting of all columns of the table - thereby enforcing the "no-duplicates" rule.