| |
t e m p o r a l |
d o o r w a y |
|||||||||
The Simplest C++ Builder Database Program |
|||||||||||
|
This is even simpler in some ways than the simplest C++ Builder program... It needs no code at all to work. Here's the form's appearance:
And here is the form VCL code - you can copy and paste this onto a blank form in C++ Builder. object Table1: TTableSetting Up To Use This FormAll you need to do is create a table. Use the BDE Administrator program (Bdeadmin.exe) to establish an alias to a directory or file in your favorite DBMS. Then use Database Desktop to create a simple table in that alias. Set up at least a memo field, a text field, and a boolean field. Now, at design-time using the IDE Object Inspector...
Compile and run the application. You can click on different rows in the grid and see the content of the data aware controls change as you do. You can edit the fields in the table by clicking on them in the grid or on their data aware controls on the form. You can create a new record in the grid with the Insert key or by using the down arrow key when on the last row. You can delete a row by clicking on the leftmost column (the grey indicator column with the arrow in it) and pressing the Delete key. Easy, isn't it? Using A QueryWant to use a query instead of a table? Try this at design-time in the IDE...
Using a query in this manner is common when connecting to client server databases. Proper PracticeThe way this program has been set up is not really the best way to set up a larger database application. To make this project more scalable...
In a real application, the data module should be named the same as your database entity (i.e. Account, Order, Member) and your Table, if the primary entity table should be named (surprise) Table. Then your code which works with the table from the form can refer to things like Member->Table, which is neat. The DataSource for the entity table should be Source. You may also need other tables in an entity data module - for instance, domain tables from which values (foreign keys) are drawn. Such things as Order->Product or Member->Dues. And there is sometimes a need for a lookup table which can be used for Locate and lookup fields - those can be called Account->LookupTable... etc. Another important concept for the scalable database program is the persistent field. In many database applications, programmers hard code the name of a field in expressions like Account->Table->FieldByName("ID"). It is better to set this up at design time by double-clicking on the TTable component and then right clicking to get a menu from which you Add Fields from the database. This action creates permanent TField objects which can be directly referenced... such as Account->TableID (this is the ID field of Account->Table not an ID of Table in Account); these references can also be checked at compile time for existence, which makes your program safer at run time. And since the definition of the field does not need to be looked up on every reference, it is even more efficient. More details on these concepts can be found in the September 1999 issue of
C++ Builder Developer's Journal, where
an article by Mark Cashman discusses advanced database concepts and planning
for scalability. |
|||||||||||
|
Copyright © 2004 by Mark
Cashman (unless otherwise indicated), All Rights Reserved
|