This project demonstrates the use of the HostServerClient.UserParams a property of the TdbOAppServerClient sub-property of the TdbOClientDataset to pass a unique UserID to the server-side application for validation.

In over-the-internet environments, anyone can get a copy of your software, particularly since you are probably producing ultra-thin client executables. That means anyone can run those executables and attempt to gain access to your server databases.

 

The n-tier structure lets you protect against unauthorized access by intercepting logon attempts where user information (username, password and so on) doesn't match secure information. This example demonstrates how to get information from the user (including accessing the Registry for the user's name and company) and pass it to the object server: ServerObjectUsers.pas for validation.

 

There is a great deal of flexibility available in setting registry values, retrieving same, passing values to the server and retrieving information back, all demonstrated here.

A quick demonstration using Delphi's standard DBDEMOS database, accessing Paradox tables. Paradox tables have unique requirements to be used with normal SQL expressions.

A simple demonstration of basic updating. No coding required. You can use either the non-threaded or threaded server object functionality to retrieve data.

A simple demonstration of basic updating using InfoPower controls.

This sample demonstrates the ability of an application to switch tier technologies instantly.

 

Selecting n-tier uses TCP/IP protocol to connect through dbOvernet components to a database residing who knows where, either over the Internet or through LocalHost on your own machine or LAN.

 

Selecting 2-tier switches to traditional client/server technology using standard Delphi data controls: TDatabase and TQuery.

 

Why is this important? Simply because n-tier technology is not always the answer to optimum performance. As you work with different applications, you may find a need for both capabilities. For instance, a LAN-based workgroup may be doing outbound telemarketing using a pre-designed questionnaire that is also offered on your web site or intra/extranet to inbound Web-based visitors. You would use 2-tier for the workgroup and n-tier for the visitors.

 

With the dual functionality capabilities of dbOvernet, you can design one very thin application incorporating both technologies, and assign the tier type that is appropriate to the requirement.

In this demo, we start by retrieving the traditional fish images from Delphi's BioLife. If you deselect the Retrieve blobs with data checkbox, the images will no longer be retrieved with the data. This is important in network environments where line speed is an issue (like WANs and the Internet).

 

When the Retrieve blobs with data checkbox is unselected, you can select any record in the grid, then click [Fetchimage] to retrieve it. Using the techniques in this demo, you can decide when it's appropriate to retrieve the blob images with the data retrieval and when it's not.

This very powerful app demonstrates retrieving and sending files (including images) to and from the server.

 

The code shows how easy it is to do with dbOvernet's FunctionParams commands used send special functions to the server:

 

FunctionParamsClear - clear the special function parameters

FunctionParamsSetCode('GetFile') - specify the function to be executed in a ServerObject in the server-side application.

FunctionParamsAdd([Param Value]) - add a parameter

FunctionParamsSendAndWait - send the function and parameters to the server-side application and wait for a response

This application perfectly mimics Delphi's standard FishFacts app, and demonstrates retrieving blobs as images and memo fields.

This demo introduces briefcasing. A more extensive treatment of the briefcase mode and offline processing is included in the CachedUpdates demo.

 

This app demonstrates alternative approaches to working in Briefcase mode. One approach actually uses a client-side table that is used to hold the current records. This method provides a table that can then be accessed by other applications in the usual manner.

 

The alternative uses a high-speed buffer dump, to stream the current data to a local file. This enables full briefcasing, since you can quickly stream the file's data back into the buffer at any time. However, this does not necessarily allow other applications to access that local file.

 

You can click back and forth between the alternatives, rapidly storing and retrieving data offline.

This application demonstrates Cached Updating, briefcasing, high-speed local storage, offline/online updating and error handling.

All changes, additions and deletions are stored in a pending cache (shown as the list under the Transactions tab), rather than being posted to the server database as each record is completed.

When you are ready to apply the updates, click the [Post the Transactions] button. All the changes will be sent as a single packet to the server. The server will initiate a transaction and attempt to apply the changes, one by one. If there is a failure at any point, none of the changes at the server will be applied - the transaction will be rolled back and an error message will be issued.

Alternatively, you can group records so that only individual groups are rejected on update failure, enabling other groups to proceed normally.

Why are cached updates important?

This application can be used as the basis for offline data manipulation. All the changes could be stored locally in a pending log. When you next connect to the server, you could post the log as a cached update.

Cached updates can play a role in one to many applications, where you want to ensure that, before posting any data, the user has a chance to review all the data.

For instance, in an invoice application, you might want to let the user complete the entire invoice, including all the detail lines, before posting any part of the invoice.

A complete implementation of a high-speed, multi-user chat system, including client and server functions, demonstrating push techniques, broadcasting and selective user identification.

A practical implementation of a customer maintenance application, demonstrating:

1. Selecting records based on a simple filter
2. Displaying records in a defined sequence
3. Scrolling through records using a grid and navigator bar
4. Adding, deleting and editing records using the customary edit box approach
5. Adding, deleting and editing records using the grid
6. Obtaining field structure (metadata) information

The entire project is developed as an n-tier application and is also demonstrated on this web page as an ActiveX project. You can be running it over the Internet, where everything you do is communicated to our database servers somewhere in North America.

A project like this could be far more difficult to develop than a standard Visual Basic or Delphi project that uses the traditional 2 tier client/server method, were it not for the tools and methods dbOvernet provides to simplify handling metadata retrieval, local caching, data synchronicity, data type conversion and other aspects unique to multi-tier applications.

The above customer project as an ActiveX control (see also our ActiveX implementation on this web site).

A complete visual query builder with links to end-user report designers.

Client and server-side applications demonstrating the use of this popular Interbase BDE alternative.

This demo illustrates the speed of accessing data from in-memory tables, where you need to use lookup tables for quick information retrieval. The demo gives you an idea of when you could be using in-memory tables for lookups as opposed to going back out to the server.

 

Table information retrieved from remote sources is stored in-memory with dbOvernet, unless you want to briefcase it (see our Briefcase demo for more information on that). dbOvernet uses in-memory BOF to EOF search mechanisms to lookup data. For instance, in our One to Many to Many demonstration, the Employees and Products tables are stored in-memory and accessed every time a record is retrieved. There is no delay, since it's all done in-memory.

 

We also provide a record count and a modified TQueryInMemorySearch that performs a btree-type search, if you want to speed up searches.

If you need to load large datasets into the client, you may also need some mechanism to filters those datasets without re-retrieving the data from the server.

 

This demonstrates a large dataset with a quick search and select mechanism. You:

 

1. Select a field to filter on and select whether or not you wish to filter within a range.

2. Set the start value for the filter.

3. If you wish to get all values "like" a certain value, then click the Like checkbox

4. If applicable, enter an end value for your range.

5. Click Apply to run the filter.

6. Click on any row in the small display grid to display the record in the edit area and larger grid.

 

For example, you could filter on CustomerID for the customers data, enter W as a value and click the Like box, then click Apply.

 

The filtered group will display in the filter list. You can then click on any row to automatically select that row for editing.

Client and server-side applications demonstrating the use of Interbase tables.

This app demonstrates using the TdbOClientDataSet to provide ad-hoc query results, retrieve database information, metadata, table lists and field names. It can be used for multi-table UpdateSQL functions as well as to search various Ports at the connected server.

This app demonstrates the acquisition of data from multiple tables into a single dataset result and enables editing and updating of any of the fields of the prime table (in this example, the customer table is prime, linked to the orders table on customer ID).

 

The SQL expression is shown in a read-only memo, and accesses a param named "customernum". You can change that param and re-retrieve datasets.

The framework for a corporate-wide messaging system enabling message dispatching, external (Internet) connectivity, "While you were out" storage, and more.

A completely-exposed rendition of a complex one-to-many-to many (Customer > Order > Order Details) application, with these features:

1. You can decide how many customers to bring across using the filter.
2. You can decide whether to view only the customer records, or link in all orders and details as well.
3. You can set the display order of the selected customers.
4. Each customer record automatically links in all the order records for the customer. Every time you move to a new customer, the application goes out over the Internet and retrieves all the orders for that customer.
5. Each order record automatically links in all the order lines for the order. Every time you move to a different order, the application goes out over the Internet and retrieves all the details for that order.
6. Although you see an Employee name in the order line, the display is really a virtual field, calculated on-the-fly based on an employee number. Every time an order line is displayed, the employee number on that order is looked up into an in-memory table containing all the employees, and the employee's last name and first name are obtained from that in-memory table, concatenated and displayed as the Employee name.
7. Detail lines contain product names which are virtual names, taken from another in-memory table - Products - by referencing a product number from the detail record to the in-memory table.
8. Extended value is calculated on-the-fly as the detail record is retrieved and displayed.

A point about the in-memory tables. The two tables, Employees and Products, were automatically brought across the Internet and loaded into memory the first time the application retrieves some customer records. That slight delay pays off handsomely by making virtual field retrieval and display instantaneous.

 

FYI - there are 9 employee records and 77 product records in this sample.

This is a fairly sophisticated application, delving into much more than just one to many to many retrieval. Several options are available to control what and how information is retrieved and displayed. There are instances of calculated fields from in-memory table lookups as well as numeric calculations.

Of interest is the methodology to control blocking or synchronous mode of data retrieval. Since we could be operating over the Internet, delays can occur in delivery of linked record sets. By setting the Asynchronous mode option to synchronous, you can ensure retrieval of only the pertinent record sets, thus preventing a backlog of requests at the server.

We also demonstrate turning on and off the retrieval of linked sets, making it easier for the user to scroll through the customer records and retrieve the relational datasets as needed.

This app demonstates codeless one to many to many, including calculated fields (employee name and product name). It is functionally equivalent to the above  OneToMToMProject.DPR, but requires virtually no code.

 

Various visual properties are provided to set and link tables together. A ClientConnection component is used to coordinate data retrieval in the correct hierarchial order, and to ensure that the user cannot move off a record while child records are still being retrieved.

 

The algorithms used to structure the 1>M>M are efficient. The entire group for any level is first retrieved, then the first record of that group is selected and used as the control record for the next lower level. This means that you are not cascading through dozens of record retrievals every time you retrieve a new higher-level record.

 

Displays pop up immediately - there is no blinking or enforced refreshing.

 

(Note: Calculated field lookups require LookupCache to be set true, since lookup data comes from the in-memory lookup tables, Employees and Products.)

Using a database containing the tables: Names, CrossLinks and Addresses tables, this app demonstrates dbOvernet's 1>M>M functionality to produce a many to many app using a central, cross link table.

The framework for an Internet ordering system including customer validation, passwords, wizard pages and order summaries.

This application uses a dbOvernet remote procedure call from a client application into ServerObjectRPC, an object providing server functions, to retrieve a dataset, including its meta data, instead of using the built-in SQL SELECT functionality. The dataset can then be handled live in the normal manner, permitting INSERT, UPDATE, APPEND and so on.

 

The techniques shown here can be used to provide special access to various databases and/or flat files that may be scattered around various computers and/or folders.

Remote procedures are something like Stored Procedures, except they are executed in the middleware, instead of in the database.

 

This application demonstrates the remote procedures, to execute procedures and functions in the middleware. The app demonstrates use of math, table record count and CustomerID validation methods placed in the middleware and called by the client.

 

The techniques shown in this app can be applied to provide business rules, return results, or just execute special procedures before connecting to the actual data source.

 

All procedures are located in a server-side Server Object named ServerObjectRPC and included in both the BDEServerProject and the SimpleServerProject. There is no obligation to use this particular Server Object, since you can easily create any number of ServerObjects to serve any purposes.

dbOvernet provides several server applications, designed to demonstrate simple to advanced functionality using both traditional database engines like the BDE as well as other engines, like ODBCExpress and IBObjects.

dbOvernet enables connectivity to virtually any datasource, including data warehouses, document centers and similar storage mechanisms, as well as to all the different types of databases.

This application demonstrates the use of stored procedures. The Interbase demo, IBLOCAL, is used for this demo, but any suitable database can be used.

 

The application lets you obtain a list of all stored procedures from the applicable database. You can then select and execute any one of them.

 

It displays the parameters in a Parameters window and you can click on any procedure, then click [Execute procedure] to run that stored procedure. A pop-up asks for any input parameters, and output params from the server will be returned to the client displayed in the output grid.

This app executes stored procs that return multiple rows in a dataset.