From Knorr Associates - Providing EH&S Software Solutions Since 1979

Welcome to DataPipe USA      The DataPipe Approach      DataPipe In Depth      FAQs      Online Demo      Customer Support      Contact Us

New Page 1

.NET Magazine

May 2002

CASE STUDY:  More Data With a Better Pipe.

Knorr Associates rewrites its data-management app with .NET technology to satisfy current customers - and attract new ones.

by Edmund X. DeJesus  MAY 2002

The old rule of thumb says, “If it ain’t broke, don’t fix it.” It’s an especially good rule in computer development— and engineering in general—because it keeps you from making unnecessary updates to products that already work fine. The trick is to know when to ignore the rule. For example, if keeping a product unchanged costs you customers—or prevents you from gaining new ones—that’s a hint that it’s time for an update. One such product is DataPipe from DataPipe USA Inc. (Butler, N.J.). Knorr, a company that acquires and manages environment, health, and safety (EHS) data for organizations, launched their product in 1979 as a Unix app, which later ran on the first PCs to collect and use data. This base product grew to include over a hundred modules to handle many aspects of EHS data collection, including waste, storage, recycling, medical tests, and Occupational Safety and Health Administration (OSHA) requirements. As you can imagine, a Unix app running on PCs was a tough sell, so in the mid-1980s Knorr took a gamble and created a version for the recently released Microsoft Windows platform. This new model—a complete rewrite from the ground up— took advantage of the modular architecture and graphical user interface (GUI) Windows offered. That’s how DataPipe was born, and its Windows incarnation has served Knorr well for over a decade.

With a winner like DataPipe, why change it? It’s those customers: They always demand improvements to the products they use. For example, Knorr’s customers wanted access to a variety of databases, such as Oracle, DB2, SAP, and PeopleSoft. Hospitals, factories, and other organizations with EHS systems to maintain often work with a multitude of databases, all handling separate pieces of the total picture. One reason for overhauling DataPipe was to acquire input from all those data stores and assemble it into a coherent whole.

In addition, Knorr began to serve a more global customer base. Organizations—including those either based in non-English-speaking countries or based in the U.S. but with global offices—needed their non-English-speaking users to use the same modules as their U.S. counterparts. The new DataPipe had to handle many languages—and multiple language character
sets—to meet the needs of these global customers.

Another reason to update DataPipe was to give users a more generalized interface. Customers based on a wide spectrum of platforms—including desktop workstations, laptops, and handhelds—needed to use DataPipe modules and exchange data with those devices. Although there are a number of possible solutions to this interface issue, the most common one is to create a Web interface. As long as the user’s platform has a browser and a Web connection, they can use the application.

With all these special requirements, Knorr’s developers needed a powerful set of tools to get the job done. Knorr was comfortable with a variety of underlying systems, including Unix and Windows, and could choose any development environment that seemed best. In fact, developers looked at many other development choices, including C, CORBA, and Smalltalk. They carefully considered IBM’s VisualAge for Java as a leading candidate. However, at the time they examined it, they felt that Java was weak in the database area. Knorr finally settled on .NET because these technologies allow what they hoped to accomplish. Moreover, the tools are powerful enough to simplify and speed their development efforts.

Go Beyond the Browser

The transition to a Web-based application is not without its drawbacks. Sure, it makes things easier on IT; with a Web-based app, all the code can reside on a Web server and no one has to deploy the app to a thousand machines. Unfortunately, a standard Web browser interface isn’t as rich as a Windows GUI. “Web applications are all very basic. They don’t do much, and the forms are very simple,” notes Peter Singer, vice president
of product development. Knorr needed more from the application such as on-the-fly field validation or a parent record that could interact with hundreds of reference and child tables. Clearly, a client heftier than a browser would be necessary to accomplish all this processing.

DataPipe developers preferred to preserve a rich interface, so they adopted a hybrid approach. The client machine requires only a Web browser—at first. After establishing communications with the server-based host program, the software downloads to the client automatically. This software establishes a Global Assembly Cache on the client, which proceeds to download any other software necessary for the chosen operation, and to pull together the data required for the task. Microsoft Internet Explorer is the chosen browser to initiate the extra activity.

This sophisticated “thin-to-thick” client strategy augments the browser’s functionality. “ASP.NET may have lots of controls, but it doesn’t compare with the Windows GUI,” comments Singer. Developers couldn’t just use Web forms to implement this strategy; they turned to user controls and put processing power at the interface level.

The ability to access a variety of databases was also not as straightforward as Microsoft, IBM, or Oracle would have you believe. Knorr had targeted several databases to satisfy customer needs, including SQL Server, DB2, and Oracle. “The problem is that there’s not much code in common,” according to Norman Dotti, president of Knorr. DataPipe developers had to write specific code to access each one of the targeted databases; this is transparent to the user, and to the rest of the DataPipe code. The database interface is constructed so that any DataPipe module can access the required details without knowing the specifics of the target database.

DataPipe uses a three-tier architecture (see Figure 1). Its Web services-accessible back-end database is independent of the other data stores DataPipe interacts with. The front end offers users powerful forms customization capabilities. For example, users can change labels and other output formatting without affecting the underlying database.

Speaking in Tongues

The new DataPipe app supports multiple languages by translating form text automatically. Its Form Designer tool allows users to select from several different languages to view data. This enables both a German and English user to look at the same data in their respective languages.
In addition, DataPipe’s back end supports Unicode, so that multiple language character sets are possible. This means that global customers can create their own labels in their own language using the character sets they prefer. This simplifies learning to use DataPipe and truly expands the number of potential users.

DataPipe developers have found that .NET affords a wide variety of useful technologies, including Web services, back-end database connectivity, and ASP.NET controls. “It makes life easier working with data sets,” says Singer. The system uses XML to handle data sets; developers found it simple to read a form, persist the properties, and bring it back to the database.
The connectivity inherent in .NET has been significant to the DataPipe project, considering the number of third-party databases involved, the many modules available for the product, and the support of users necessary. “You could build these things yourself if you wanted, but it would be fragile if you needed to make changes,” notes Dotti.

The Knorr team used Visual Studio .NET for several areas, including Windows Forms, middle-tier components, Web services, and Windows services development. The Windows services development offered a lesson in the variety of .NET technologies available to solve certain problems, such as tracking the number of users. ASP.NET seemed to offer three methods to accomplish this. Although one used Internet Information Services (IIS) and another used Web services, neither worked with the Web farms. A third method performed the task in SQL Server, but this didn’t work with the other databases that DataPipe had to support. Developers finally wrote the necessary code themselves using VB.NET. “This way, for example, you can have one machine running Web services and track who’s accessing that,” explains Singer.

Developers used COM+ for database transactions. They found its handling of commit and rollback—as well as its ability to use multiple tables—invaluable.

Take Advantage of Visio

The DataPipe development team thoroughly exploited Microsoft Visio Enterprise Edition for a variety of tasks. They designed databases by constructing entity relationship diagrams in a logical,
not physical, level. Visio then converted the logical types to the correct structures in DB2, Oracle, and SQL Server. As a bonus, Visio supports Unicode for the multi-language character sets they wanted to offer (see Figure 2).

The team also used Visio to incorporate Unified Modeling Language (UML) into the process. Given a class structure, Visio developed the interface and came in handy for designing data sets. Visio integrated well with Visual Studio and Visio documents were even incorporated in VB.NET. “Microsoft handles a lot of the plumbing,” says Singer.

Knorr did hit a few snags using the beta versions of .NET technologies: The documentation wasn’t as complete as they’d have liked, and there was always the nagging doubt that something
that worked in beta might not work the same with the real product. Happily, those fears didn’t cause significant problems.

In fact, the developers’ experience with .NET has inspired them to formulate their own wish list of features for future versions. Because they deal with so much data, edit masks on fields would be useful, forcing the correct format of fields such as phone numbers or social security numbers. Developers also miss repeater control, present in VB6 but not in VB.NET, which lets you specify how many controls you want, then binds them automatically. Because DataPipe uses complicated data sets— multiple records from many tables—Knorr developers would also like the ability to handle more complex data sets.

Knorr’s experience with .NET has been overwhelmingly positive. The new DataPipe code is robust and easy to support. “We’ve had no customer problems,” says Dotti. “It’s a low-maintenance product.” That’s the result you want when you fix something.

About the author:  Edmund X. DeJesus is a freelance technical writer in Norwood, Mass. Reach him at

New Page 1


DataPipe Overview

History of DataPipe USA

News and Events

Awards and Certifications

Helpful Websites

Employment Opportunities

Article and Newsletters


Access our system and see DataPipe live as we move through various forms and reports.


Copyright DataPipe USA Inc. 1979 - 2019.         Privacy Policy         SiteMap (XML, HTML)