Home

New features - Version 1.4.0
  • Design Data Center - one-stop Database/Table/Field/Index/SQL specification w/local and remote design-time fetching
  • SOCKS5 support/firewall traversal. The SOCKS specification allows a client application using a custom protocol (like dbOvernet) to connect to a server through a firewall or proxy. Most firewalls and proxies support the SOCKS5 (or SOCKS4) protocol. Through SOCKS, the client is not directly connected to the server - the SOCKS5 server acts as a relay for all communications. This enables companies to use a firewall or proxy to protect their internal network against internet intrusion yet still allow authorized users to connect through the Internet. 
  • Transparent local/remote connectivity You can completely blur the distinction between remote and local loading with a single property setting. Tables can be streamed from local drives, eliminating time-consuming over-the-Net loading, with automated remote updating. 
  • Enhanced business/validation rules demos dbOvernet is true multi-tier. Other products try to simulate that by simply sticking socket transmission between clients and servers. That solution is fine for simplistic, closed-ended approaches, but when you need to move to serious application development, you need an open middle tier and the classes to implement functionality in that tier. That's what it's all about.
            Our middle tier's ServerObject class has always enabled easy construction of business rules, remote procedures, validation and data access rules, centralized in the middle tier, as part of its basic architecture.

With dbOvernet, it's easy to develop cross-connected business rules or preemptive validation (OnBeforePost, OnBeforeEdit, OnNewRecord, OnDelete, etc.). Add callback streaming using our built-in events- logon validation, autonumbering of new records (autoincrement), passback of updated records and more.

None of these solutions require special programming. They simply use new instances of the ServerObject class that you can easily create (or you can tap into our existing ServerObjects, like our RPC models). Because of our open ServerObject class, you can easily develop your own solutions without waiting for new releases or hoping that the software developer will add needed features. It's all there for you as part of the basic architecture.
  • New basic client and server examples Along with many new example applications, to show how easy it is to develop apps, our new basic client example takes no code to develop a complete retrieval and updating application, and our new basic server example has about 3 lines of code to provide complete access to any database. These two examples show how easy it is to develop applications that provide full remote connectivity with functionality against any database.
  • Automatic Active A small point, but now, via our SendOnActive flag (which defaults to true), you can choose whether to trigger Active automatically during runtime startup, or defer to our far more extensive Send functionality. Our technology ensures you have the choice.
           The TdbOClientDataset has always supported the Active property during design, but used the Send property on startup, and that required one line of code in the FormCreate event. Now if you set the TdbOClientDataset's Active property to true during design, it will automatically fetch a result set at runtime to provide an initial dataset to the controls.

Also, during runtime, if you want to refetch data, you only need to issue the Send command. You don't need Disable/ EnableContols or Close/Open. That's all handled internally by the single Send command.

Of course, as you use this technology, you may come across instances where you don't want setting Active to true to automatically trigger a request from a remote server. With SendOnActive, you have a choice.

Both options continue to support our unique AutoSQL feature where SQL expressions are automatically constructed based on values of various properties in the TdbOClientDataset (any change to any property automatically causes the SQL expression to be recreated).

And we continue to provide the LiveData property which allows you to skip data retrieval from a remote database during design (particularly since it can be time-consuming).

It's features and touches like these that show the maturity of dbOvernet as a complete multi-tier toolset. With properties like AutoParams, AutoSQL, AutoUpdate, LiveData, LoadLocal, SendOnActive and UpdateRemote, you can quickly build a visual solution for every situation you might encounter.

  • Performance enhancements/statistics/reliability We've done our homework and now, using a  typical dual 200 mhz NT Server, dbOvernet's Application Server can process over 65 SELECT requests per second at the server.
           Those stats are for server turnaround. The measurements for a complete round tip over a 10 mps network, connecting to an ODBC-driven MS Access database via the BDE engine reduce that to about 30 requests per second. This includes:
1. Dispatched from a client workstation
2. Received by the server
3. Executed in an instantiated ServerObject
4. Packaged and dispatched from the server
5. Received back by the client
6. Unpackaged as a result set into an in-memory TdbOClientDataset and
7. Used to populate a TdbGrid

(Average outbound packet is 7 records of 15 fields - approximately 1,000 bytes). 

It just doesn't get much better than that.

Of course, you can use our threaded and pooled models to ensure throughput for all connections, and you can spread requests over multiple servers and multiple server executables, but these tests with the non-threaded model demonstrate the real efficiency of our client > middle tier > server and return connectivity. They are important benchmarks to ensure you have a common basis for comparison.

For companies not connecting hundreds or thousands of users, the server can be almost any machine. For example, in tests on an old 486-50, we were able to push 10 requests per second. That's more than the majority of networks require. We ran a test of 12 clients continually against a single 486-50 server with 16 meg RAM, running Win95, with each client running a variable, high-demand SELECT loop for 4 hours, without any failure, slowdown or memory leaks. An astonishing 139,694 SELECT requests were processed on the 486 during the 4 hours. That works out to almost 10 requests per second.
  • Improved Help files and documentation We've expanded our Help discussions on concepts and architecture, improved property explanations and re-structured our Contents page.
  • New properties of the TdbOClientDataset and TdbOClientConnection:
            - ChildFilter: enable child filtering beyond the normal master/detail join.
            - SocksAuthentication, SocksPassword, SocksPort, SocksServer, SocksUserCode: SOCKS5 properties
            - DatabaseName: now activated for use with the Data Central Wizard
            - LoadLocal: specify local stream loading as flat file.
            - LocalPath: specify the path for local loading.
            - SendOnActive: let Active decide how data is retrieved on startup
            - ChildFilter: enable child filtering beyond the normal master/detail join.
            - SocksAuthentication, SocksPassword, SocksPort, SocksServer, SocksUserCode: SOCKS5 properties

New features - Version 1.3.7

  • Group updates via ClientConnection Improves our implementation of centralizing cached updates of multiple tables to provide grouped transaction updates through the ClientConnection component. The ClientConnection component assembles and processes updates from linked tables, then disassembles and allots errors to individual tables where applicable.
  • GetNextPacket This method provides persistent-type connectivity, yet maintains the high-speed and ease-of-use functionality of dbOvernet's engines.
           GetNextPacket passes a filter to the server-side application's database and, in conjunction with the MaxRecords property and that filter, the database returns the next set of data records in a dataset to the client, where they are appended to the current client-side dataset.

With this method, developers can comfortably develop applications enabling dataset retrieval of any length, restricted by the MaxRecords property and retrieved through GetNextPacket.
  • NTService dbOvernet server applications running as NT Services is now available.

New features - Version 1.3.5 

  • Blobs as parameters In our continuing commitment to accommodate all databases and engines, V 1.3.5 adds INSERT/UPDATE options to enable blob-type fields (Blob text, binaries, Text sub-types. etc.) to be passed from clients to the server-side application as automatically labelled parameters through BlobsAsParams property. Data packets include the data values for designated blob types in separate records. Server-side applications "glue" them back together through on-the-fly parameter creation.
           This feature ensures back-end database switching where complex blob fields are used, without modification to the client applications.

BlobsAsParams is also enabled in feed-back transmission of partially-successful data inserts/updates where grouped transactions are used. Grouped transactions is unique to dbOvernet, enabling sub-packaging of groups of records in the ApplyUpdates function of cached updating through unique identifiers (like invoice numbers, customer numbers, etc.) assigned to record groups (one to many, one to one). Where records are grouped and sent to the server as a single set for updating through transactions, an invalid group does not affect the validity or acceptance of other groups in the set.

Unsuccessful records are automatically reset to the client, including data records representing blob fields.
  • Client connection component The ClientConnection component now hosts UserParams, enabling broadcasting of this property to all connected TdbOClientDatasets. The component now contains the properties: VersionNumber and VersionDate, to identify the dbOvernet version you are working with.

New features - Version 1.3

For our latest 1.x release, we've concentrated on increasing the client-side functionality, adding depth to dbOvernet as well as some great new properties and methods. Of course, we've added new example and sample programs where appropriate to demonstrate the new features.

  • Remote procedures Execute procedures stored in the middleware! Define business rules, call pre-validation functions, offload processing requirements. Create procedures and functions in the server-side application and execute them from any client. Run any procedure or method, access any datasource, return any number of parameters. Remote procedures are something like stored procedures, except they work before the database is accessed, enabling efficient rules management, pre-processing activity and more.
  • One to Many to Many w/multiple planes Full 1>M>M>n to any level, with unlimited children on any plane, horizontally and vertically! Simple, robust and no code to enable data retrieval and data entry. No blinking, no flashing, no delays and - no code required.
  • Master source/key fields - Designates parent and link keys in master/detail relationship (with automatic generation of connecting parameters) and enables assignment of a source dataset in client-side stored procedures for completely automatic runtime retrieval of parameter values. No code required.
  • Parameterized queries SQL expressions with any parameters. Uses standard Delphi TParams functionality.
  • Stored procedures Full stored procedure functionality - handles all types: input, inputoutput, output. Enables automated list retrieval and select at designtime, automatic param completion - no code required.
  • Automatic param completion Point a client-side stored proc's Datasource to any client-side TdbOClientDataset and the stored proc will look to that datasource to automatically retrieve parameter values at runtime, then pass them to the server for execution.
  • Stored procedure list/select/execute At runtime or design time, retrieve all stored procs using a single, controller TdboClientDataset. Select and execute any proc at any time, with automatic param value completion.
  • FunctionParams command group Simplifies execution of any type of server-side function. Clear to start, SetCode to describe the function, Add to add parameters, SendAndWait to execute and wait for a response. Results returned into the ExecBuffer property of the hosting TdbOClientDataset. Develop new ServerObjects and quickly execute their methods using FunctionParams.

New component - Client Connection The client connection component is a helper component that enables Port and Server setting broadcasting at runtime and design time. Set all client-side TdbOClientDataset components instantly with a change to the TdbOClientConnection component. Also used to manage 1>M>M data retrieval to ensure orderly, hierarchial data retrieval.

Features added to our Version 1.1 Release

New component - TdbOClientDataSet. This one component encapsulates all 4 dbOvernet components used at the client side and is ideal for SQL work. The other components are still available for specialized functions that you might require. TdbOClientDataset has:

  New properties and methods to:

  • Designate the SQL expression through the property, SQL. Automatically generate SQL expressions into the SQL property, from visually-designed properties. Can be overridden. Takes information from the FieldLayout, Filter and ServerTableName properties to create the expression.
  • Automatically re-generate SQL expressions when any linked property changes at design or runtime. Can be overridden.
  • Specify whether or not to retrieve live data at design time.
  • Provide a field name list for the automated SQL expression's SELECT statement. The list is created and inserted into the SQL expression automatically when you close the Field Layout Editor.
  • Provide filter specifications through the Filter property for the WHERE section of the SQL expression. (For instance: customerid like 'd%'.) Can be overridden.
  • Provide the key update field names and field types for automatic server updating through the property, KeyFieldNames. This property is automatically created when you select one or more fields in the Field Layout editor and designate them as the key update fields. Can be overridden.
  • Automate the designation of the server-side table associated with the TdbOClientDataSet through the property, ServerTableName. This field is automatically created when you enter a table name in the Field Layout editor or Import from the Field Layout Import dialog. Can be overridden.
  • Specify cached updating through the boolean property, CachedUpdates. If true, updates are automatically cached for subsequent processing through the new method, ApplyUpdates.
  • Control SQL requests through the property, Send.
  • Apply cached updates through the property, ApplyUpdates.
  • Access error handling through the event, OnDataDone.

Among the other features, not only can you can easily design runtime SQL expressions, but, in most cases, you don't even have to worry about creating a SQL expression - it's all done automatically.

This one component reduces everything to basically no code! Now the only components visible on a form are TdbOClientDataset and TDatasource (or TwwDatasource).

Further, you can override the automated features to directly specify any SQL expression. Execute complex queries to retrieve data from any tables and add expressions using the MetaSQL function, and dbOvernet will return both the metadata field layout information as well as the data.

Note, of course, that all the other dbOvernet components are still shipped with the product, so you have complete access to the entire dbOvernet architecture.

Runtime live data. Permits data to be filtered, viewed and scrolled at design time. You have the option of turning this feature off or on.

Field support. dbOvernet supports all field types in their native structure.

Chat program/remote access management. We now include a fully-functional demonstration chat program as an add-in to any client- and server-side application. Users can communicate with each other or to and from the DBA at the server. Uses standard WHO to retrieve user lists, WHOAMI to obtain current user information, nicknames, etc. The application can run inside any client-side and server-side application, or as a standalone app.

The chat program demonstrates several capabilities of dbOvernet, in addition to chat. Client- and server-side programs become full two-way communicators.

Through this functionality, clients can become servers and servers can be clients, so you have the built-in capability using dbOvernet's exclusive Server Objects to perform any action at the client side.

For instance, applications can be developed to provide remote management to the server-side DBA; others can provide important data and synchronization functions. Software versioning can be handled through this approach, along with callbacks.

Applications can be as simple as dropping components on the client and server applications, along with a few new server objects, or as complex as our full-blown chat program demonstration:

  • Access, retrieve and update databases at the client
  • Manage image and document files,
  • Provide whiteboard and group-based communications,
  • Pass and access emails, ZIP files, synchronization files
  • Upload  updates, current software
  • Provide callback functions

Field layout editor. dbOvernet now has a full field layout editor. You can designate any database and any table during design of your client-side applications, select all or any fields into the layout editor, move fields up/down, delete/rename, etc. for automatic field designation of client-side dbODatasets.

Encryption/compression. We have provided events and methods in the TdbOAppServerClient (client-side coordinator) and TdbOAppServer (server-side coordinator) at key trigger points to enable encryption/decryption and/or compression/decompression of data moving over the media. Example programs using simple encryption algorithms demonstrate the methods and enable linking to other encryption/compression programs.

dbOVisual Query Builder. The VQB was released previously, but we'd just like to remind everyone about this great tool. Click here to have a look at it.

Back to top

 
Contact us