Why mv.NET?
Connectivity into MV / Pick databases from object-oriented languages and mainstream products used to be difficult. These days it’s not tough at all, and highly affordable as well. There are many tools in our market that can do communications between MV and others, but I’ve settled on one tool that satisfies almost all of my needs for communications development. This article focuses on some of the advantages of mv.NET over competing products.
Matching solutions with business problems
We see lots of inquiries in forums about using MV applications with Microsoft products like BizTalk Server, Exchange Server, Small Business Server, SQL Reporting Services, MapPoint, SQL Server Integration Services, and others. It’s only a matter of time before someone asks about Live Communications Server, SharePoint Portal Server, Project Server, or Speech Server.
We see inquiries about integrating with other applications like Outlook, Word, Excel, or Project, or accounting software like Great Plains, QuickBooks, SAP, and Oracle Financials. Companies want to exchange XML documents. They want to use Web Services to send or receive data. They want to pump data back and forth between SQL databases and their MV database, or between different MV environments.
Some companies want to build dynamic web sites and use Ajax (see entire Ajax category in this blog) and other coding techniques, and tools that are far beyond basic form handling.
I frequently respond to inquiries like this with a proposal for mv.NET. That’s because mv.NET really is a single solution for innumerable connectivity requirements. When someone asks "how do I connect MV with X" and I say "mv.NET will facilitate your integration between X and your DBMS", it’s implied that this same response applies to a whole lot projects, product X’s, and all MV DBMS platforms.
Specific points for mv.NET, comparison with other products
What follows are a number of reasons why mv.NET is better than other tools, particularly freeware connectivity libraries. If you have any questions or other ideas about what should be in this list, or you’d like to know how mv.NET fits with your environment, please feel free to email me or post a comment to this article.
If you use UO or UO.NET you get a "free" tool that has no pooling mechanism. This means every connection consumes a DBMS license, which can get very expensive. For pooling, some sites use RedBack. The cost of the RedBack Object Server plus webshares adds up to a few thousand dollars. Developers can add the RedBack designer for several hundred more.
If you use mv.NET you don’t need RedBack because pooling is built-in. That eliminates an entire tier from your topology. The cost of an mv.NET session license which provides process pooling is about $260, eliminating thousands from the costs of using RedBack. A single mv.NET Developer license costs less than $650 and includes two session licenses ($520 value) which can be used for developer connections or end-users when no development is taking place. You could consider this to be $130 for the developer license with two required session licenses for connectivity. Is there any MV developer product in this class with a cost that low?!
Regarding features, there are three connectivity libraries in mv.NET. One of these is the Core Objects library which includes all of the functionality of UO.NET and much more. The Binding Objects library facilitates direct access from UI components to data with no code. The Adapter Objects library provides sophisticated integration with ADO.NET, and is key to linking MV with relational databases. None of this is included with freeware libraries – developers need to write their own code to perform similar functions.
mv.NET also includes a very elegant connection model where you define profiles for servers, and profiles for accounts within servers. This eliminates the need for manual coding of this sort of thing. You never want to hard-code server names or addresses, user IDs or passwords, or account references, though this is exactly what’s done with most software written using the freeware – or developers need to write code to manage their own external tables.
The mv.NET developer package includes a GUI for editing dict definitions and data, and a colored-syntax BASIC code editor which eliminates the need to use AccuTerm, wIntegrate, or other additional software.
mv.NET now includes two great new features which are unavailable elsewhere. The first is server-side Remote Procedure Calls, which is allows BASIC code to invoke remote functions, make SQL queries, invoke Web Services, and many other functions. The second is a Gateway which allows internet-based clients to execute functions on DBMS platforms behind a firewall. If you’re using a connectivity component like UO, you need to connect from the client directly through a socket and then to the DBMS. Exposing sockets to the internet is insecure, so most sites will call web services and execute functions on the back-end, with a middle-tier server being the "real client". The Gateway allows a remote thick client to do this same function transparently. This facilitates introduction of the Service Oriented Architecture that is coming into vogue.
Business concerns
In a business sense, we can compare for-fee products like mv.NET to freeware like the D3 Class Library, UniObjects, or UO.NET. I can only recommend products that I believe are stable, well supported, and full featured. As mentioned above, the freeware has nowhere near the number of features that mv.NET has. They are COM-based (yes, even UO.NET is not fully managed code, just the same old code in a new wrapper) which means they don’t take advantage of the lessons learned over years of COM development; fully managed .NET applications do not have memory leaks and do not have to contend with "DLL Hell", while applications developed with the mentioned freeware do. Further, I don’t see the sort of development effort going into any of those products compared to the commercial offerings. It’s simple economics – there’s no profit for developers to enhance or maintain freeware, so chances are slim that these tools are ever going to be any more than what they are now, or any better supported. Microsoft has dedicated their development to .NET, and the next version of Windows will be built around .NET, not COM. I can’t recommend dead-end tools like this to my clients for real business development.
mv.NET works with (nearly) all MV DBMS products over Windows or Unix/Linux, which is great for developers who want to sell their code to a more general audience – PDP.NET only works for D3 and U2, UO only works on U2, and for the other eight or so common MV platforms some other solution must be found.
BlueFinity International is a subsidiary of MPower1, which is also the parent to jBASE International. Adopters don’t need to worry about BlueFinity or mv.NET going away, they already have the endorsement of a large company, excellent and dedicated managment, and the financial backing required for development, marketing, etc. The same can’t be said for other products in this category, where some companies have demonstrated volatility and/or show very little interest in these connectivity products.
There is a site using RedBack now that did a benchmark against mv.NET, and found mv.NET faster by a factor of tens. Even without the significant performance benefits, some important facts need to be considered. This was a live RedBack site, already paid their money and did their development, found limitations, sought assistance, did research into other products, found mv.NET satisfactory as a replacement, and they have made another purchase and are now converting. This is a testimonial from within this community and carries significant weight for any other company in similar circumstances. One of our clients has gone through the same cycle with D3 and PDP.NET and has since adopted mv.NET for use with Unidata.
Upcoming Enhancements
The future of mv.NET is very bright. One of the enhancements in development is the ability to define business objects – classes which represent files or other logical groupings of data, with properties and methods to expose data in a true object-oriented manner. As someone who tends to write this sort of thing myself, this will be quite welcome. Another enhancement is an extension of Binding Objects which will extend ASP.NET web controls with Ajax capabilities (via Microsoft Atlas) directly to the MV back-end. This will give us the ability to build a thin-client GUI with many of the features of a thick-client, including the immediate feedback which is familiar to MV green-screen users. Picture dropping a control on a form and then defining the OnChange event as a BASIC subroutine. When the control changes, your code will execute without a full page refresh. These features will never be put into any of the freeware products.
Summary
Having read these reasons why mv.NET is better than other tools, particularly freeware connectivity libraries, I hope you’re compelled to ask some questions. If you’d like more information or you’d like to know how mv.NET fits with your environment, please feel free to email me or post a comment to this article. I invite you to also read this other article which focuses more on what led me to mv.NET, rather than the product details.
Nebula Research and Development is an authorized Distributor for mv.NET.
2 thoughts on “Why mv.NET?”
Leave a Reply
You must be logged in to post a comment.
As I was providing a link to this article for a new mv.NET prospect it occurred to me that I didn’t mention a lot of things I should. In short, one other reason PDP.NET is inadequate is that it still (October 2006) doesn’t support the .NET Framework v2.0. Even if they catch up, that’s just inexcusable.
In fairness I note the world of RedBack has changed drastically. If someone would care to correct my article comments with more recent information I’d really like to have accurate information here. Also, I understand UO.NET does some type of pooling but I have no idea how it works. Please e-mail with info and I’ll summarize the info, perhaps in a correction to the article itself. Thanks!
I get lots of inquiries about why mv.NET is better than PDP.NET. Many of these are from sites that (like I did) adopted PDP.NET and then decided they needed something else. In response, I’ve just drafted a long list of notes comparing the products in business and technical terms. Please let me know if you’d like to discuss these details.