Take a moment to consider why you might choose to use the IDS ActiveX Client to build an I*net database solution as opposed to a web/html oriented approach.

In order to get you personally acquainted with the usefulness of the IDS ActiveX client we have developed a demo application you can test by clicking on the link at the bottom of this page. The IDS ActiveX Client demonstration shows the simple power of Client/Server database applications using the I*net. Using the ActiveX Client would be most beneficial when you know who the intended users are and that they would not mind downloading or installing a 500k ± application on their workstation because they will be using it on an ongoing basis.

The IDS application you are about to run is not really a "web database solution" because it does not use HTML or any complicated scripting routines and data manipulations in order to accomplish the simple tasks that "real" Client/Server database applications perform all the time. It is also a browserless approach to utilizing the Internet. Using the ActiveX Client stands in contrast to other approaches because you can use your favorite development environment and build powerful Client/Server applications like you normally do, thereby eliminating multi-layer data access methods. Now that's a refreshing thought!

The ActiveX client demonstration is a simple point-of-sale database application. Even though this demonstration is a simplified program, it still does real work over any TCP/IP connection -- and to do real work, you need multi-threading, extended operations, state maintenance, and client-side caching, things that are common to "real" database applications and that are quite frankly, impossible to do with HTML-based approaches.

Below is a screenshot of the demo application. With this simple point-of-sale application you can enter a new order for one of the existing customers in our database. (Don't worry, we won't really ship them the garden tools you enter.)

In contrast, to perform this same seemingly simple application with an HTML browser based solution would require several pages that had to interact together. You would probably need to use a combination of HTML, various scripting languages and other unfamiliar programming environments (CGI, VB Script, ISAPI etc) in order to accomplish your task.

Both the order entry and the order browser page would have to know the current customer. In addition, product browsing would require a separate page, and on returning, the order entry page would now need to know the selected product in addition to the current customer. All this time, of course, the order page would need to maintain the items that had been entered previously. And this is just the beginning of your problems...

Let's assume you manage to solve the lack of state information (all the while keeping your fingers crossed that the user isn't declining all your cookies). Every time the user jumps back and forth across pages, his browser has to reload the entire page and re-read all of the data associated with that page. At this point, you're certainly hoping the user is following links and not hitting the "Back" and "Forward" buttons on the browser. Getting tired yet? The user might be too!

Finally, doing things like keeping a running total cost, verifying quantity and final price, and maintaining all of the little details in a simple point-of-sale program becomes a painfully laborious task. Should we dare ask you how your programming chops are at scripting languages? How about efficient multi-threading, extended operations, and client side caching in VB Script?

As you can see, the biggest problems with the web/html based approach are three-fold: inefficiency by employing a multi-layered data access approach for what are normally simple database tasks, programming difficulty by using cumbersome and unfamiliar languages and environments, and the limitations inherent with non-IDS approaches.

The good news is that Smithware's I*net Data Server provides solutions for both web approaches and non-web approaches. And the beauty of IDS is that you have the flexibility to choose when to use either approach!

Below is a chart briefly outlining the strengths and weaknesses of using the ActiveX Client with IDS and suggestions about when you might choose the ActiveX Client to build and deploy your I*net database application.

Client	Strengths	Weaknesses	Ideal For...
ActiveX	Familiar and easy to program.	Relatively large footprint.	New applications.
	Works in many development environments.	Requires several support DLL's.	UI-intensive applications.
	Compatible with Smithware's ActiveX Controls for Btrieve.		I*net enabling applications created with Smithware's ActiveX Controls for Btrieve.

Using the ActiveX client allows you to write a program in the Win32 ActiveX environment of your choice (VB4, VB5, Delphi2, Delphi3, C++ Builder, and Visual C++ 4 & 5, to name a few) that can access data transparently over either the Internet or the Intranet. This means the same application can work over the LAN or the Internet without a recompile!

Once you get to choose and use a real programming language, many of the problems of "web applications" go away. For instance, state information can be maintained in a variable. Application flow can be determined by menu configuration, not user whimsy. Records can be cached on the client, so your application isn't constantly running back to the server asking "What was that you said?".

Finally, the ActiveX IDS client allows the developer to do things that are simply impossible with non-IDS approaches. Extended operations are built into the ActiveX so low-bandwidth communication can be optimized and multi-threading -- an essential when working across low-bandwidth lines -- can be used effectively.

Now let's go to the next page so you can see the IDS ActiveX Client in Action!

Onward!

Retreat!

Copyright © 1988, 1998 by Smithware, Inc. All rights reserved.

Smithware, Controls for Btrieve, I*net Data Server, DDF Builder, DDF Sniffer, Btrieve Developer's Journal, and Software Solutions for the Real World are trademarks of Smithware, Inc. Btrieve is a registered trademark of Pervasive Software, Inc. ActiveX, Windows, Windows NT, and Internet Explorer are trademarks of Microsoft Corp. All other product or brand names are trademarks or registered trademarks of their respective owners.