Protected: mv.NET and PDP.NET comparison

Technical

I’ll preface by saying my intention here is to cite specific product differences which have influenced my decisions, and those of my clients and colleagues, to switch from PDP.NET to mv.NET. Again, if my information isn’t current, let me know, I’m interested in technical accuracy. Since I gave up PDP.NET and am no longer using the software, my information may be old. But I’m also explaining in a historical sense what prompted me and others to reconsider the software we were using for development. People can nit-pick forever on the relative merits of individual product features. In the bigger picture we’ve just found mv.NET to be technically preferable to PDP.NET, if for no other reasons than personal and subjective preferences which many of us share.

• mv.NET has connection pooling which allows end-users to get maximum utilization from their DBMS licenses. See my article called How many licenses do I need for related info.
• PDP.NET does not have connection pooling. I’ve been told by RD that it does but their end-users looking at mv.NET say that it does not – personally I’ll believe the people who paid for it.

• mv.NET has three libraries to be used for different but related purposes: Core Objects to perform MV operations in a manner familiar to Pick BASIC developers, Adapter Objects for ADO.NET functionality, and Binding Objects for data-bound forms controls (both thick client and thin). Many of the methods in each of the libraries have an extensive set of overloads to facilitate development.
• PDP.NET provides similar functionality but with much less depth. They have a Connector library, Extensions library, and a WebExtensions library. The class definitions in these libraries are not as feature-rich as those in mv.NET and there are almost no overloads for constructors or methods.

• The mv.NET Binding Objects library supports web forms with ASP.NET, and has built-in support for Ajax/Atlas communications. BlueFinity worked with Microsoft to improve Atlas before it went production.
• To my knowledge, the PDP.NET WebExtensions class doesn’t support Atlas.

• The Adapter Objects library in mv.NET supports all four types of SQL CommandString to the MV DBMS: Select, Insert, Update, Delete. It also supports calling MV programs as ADO.NET Stored Procedures.
• PDP.NET doesn’t fully support these ADO.NET operations.

• mv.NET allows access to dynamic array attributes using syntax like item["dictname"], and this is possible without mapping the dictionary item to a product-specific extended dictionary definition. This facilitates rapid development without pre-mapping. Extended definitions in mv.NET are used for other purposes, only as required.
• PDP.NET requires an extended dictionary for all such references. This gets in the way of rapid development.

• mv.NET uses both telnet and UniObjects/UO.NET to communicate with U2. It uses telnet for D3 now and they are looking to increase performance with D3 using a direct socket connection. I appreciate this dedication to variety and the ongoing quest for better performance. This sort of thing also helps in various sales situations where the end-user already has preferences for or against specific connectivity types.
• PDP.NET has one interface for D3 and one for U2.

• mv.NET integrates more closely with Visual Studio and includes an item editor and program editor (with BASIC code highlighting) so that the VS developer can do all development from the same environment. I personally like to keep a telnet window open for TCL access anyway, but it’s nice to have this option.
• In PDP.NET, the editors for BASIC and dictionary items, as well as the server definition maintenance utilities, are all outside of VS.NET.

• mv.NET does not require XINETD in *nix or WinINETD in Windows to proxy requests from the Windows client/middle-tier into D3. PDP.NET does. This may just be an implementation detail but it’s one less component to worry about.

• I have not tested PDP.NET and mv.NET side-by-side for performance. Based on my experience I’d say the products are roughly equal in this area.

It troubles me to write up a product comparison like this. I worked at Pick Systems / Raining Data for about 7 years out of my 23+ years in this industry. I held the titles of Quality Assurance Manager, then Corporate Technical Account Manager, then DBMS Product Manager for Marketing. So I am intimately familiar with the company, the people, and the politics. Perhaps surprisingly to some, my primary development platform is D3 and I continue to appreciate this software and the people who maintain it. But all personal feelings aside, when it comes to the pure business of .NET connectivity, there is no doubt in my mind that the best product in this class in our industry is mv.NET.

Nebula Research and Development is an authorized Distributor for mv.NET and I will be happy to work with you as you research and adopt this software for internal use or resale. VARs registered with us earn sales commissions and volume discounts, installation and development assistance, and other value-add benefits to facilitate development, marketing, and sales efforts. We are also prepared to offer existing user/developers of PDP.NET special discounts on software and migration services.

As always, e-mail me with comments. When this article goes public I’ll open it up for comments here too.