I'll  preface by saying I catch some heat when I advocate some
products, because I happen to sell them too. People confuse the cause
and effect there. I sell products because I use them - I'm putting my
money where my mouth is. I was using them first as a choice, having
considered other options just like fellow colleagues, and then I
decided that I liked them so much that I would sell them too. When I
sell a product like mv.NET, I get feedback from my clients. I pass
that back to the up-line developer, we get product changes, and we all
win. That's my motivation - to ensure that the products I like stay
good. Some people here know that when I decide that I can't rely on a
product anymore, I stop advocating it. And with that said, I've been
using mv.NET happily for about 8 years now.

As Symeon says, mv.NET is a super-set of the free DBMS tools.
Comparing them is like comparing water to coffee, apples to apple pie,
or radio to TV. You can survive on the former but you'll get much more
from the latter. The difference with the software, again echoing
Symeon, is that mv.NET doesn't "need" UO.NET or any of its
functionality - mv.NET can use telnet or SSH or UO as the basic
transport too.

IBM saw the value-add of mv.NET compared to UO.NET, and purchased a
version of the source to re-brand and sell to U2 sites. I don't think
they continued that - their version couldn't keep up with mv.NET
itself. The point here is to emphasize the conclusions of the
evaluation of their own product.

While this doesn't apply to most U2 developers, one of the big
advantages of mv.NET is that works for all MV platforms. For
third-party developers this is huge because it means reporting tools,
communications interfaces, and entire applications can be portable
across a wider variety of DBMS products. YMMV

Please feel free to contact me for more info.

Tony Gravagno   
Nebula Research and Development         
TG@ remove.pleaseNebula-RnD.com         
Nebula R&D sells mv.NET worldwide       
and provides related development services       

> From: Symeon Breen 
> Uniobjects.Net is the base requirement. MV.NET builds on this and
> gives you a heap more (tho infact you can use it without
> uniobjects.net)
> So it depends if you want simple connectivity to the DB to do
> commands and subroutine calls, for which uniobject.net would
> or if you want any of the other fancy stuff on top that MV.NET will
> you ...

> From: Perry Taylor 
> I'm investigating the pros and cons to using UniObjects.Net vs
> party products such as MV.Net, etc.  Anyone care to chime in with
> experiences?

U2-Users mailing list

Reply via email to