gerry wrote: > Thanks Tony, but ... > the web services we use are .NET, the HelloWorld example I used took > less than minutes to setup. We also have inbound and outbound web > services that use UO.NET. I'm not sure why we would want to pay for > an additional framework for such a simple thing.
Miscellaneous bullets to answer this popular question. - If you can do everything so simply with UO.NET, why are you also using the SOAP API, CallHTTP, and maybe the XML library? - The database should be focused on data, not protocols. - Pushing data from MV with mv.NET is as easy as writing an item to a file. - Each of the tools provided in MV DBMS products is non-standard amongst one another within each DBMS, as well as non-portable to other DBMS platforms. - From the posts we see here every week, using each of the tools discussed here seems to be never-ending battle with syntax, lack of examples, and occasional bugs. - A single mv.NET end-user session license costs about US$260 and that can handle the needs of many users. When people talk about the expense of for-fee components, let's put it in perspective. What's your time worth? - Our clients are using mv.NET to get around issues, complications, and/or platform-specific nuances with U2 inbound/outbound comms using BCI, ODBC/OLEDB, and sockets. They're using mv.NET as a very low-cost alternative to RedBack, yet another library people must learn. - IBM has licensed mv.NET themselves because they see the advantages, I'm sure their marketing people will go to lengths to tell you exactly what i'm telling you here. - I can't provide the content of several product documents here. To understand exactly what is in this suite of libraries compared to the single UO.NET library, all you need to do is request the FAQ (not available from anywhere except Nebula R&D) which has download information for the documentation and software. - In short, in addition to a library similar to UO: mv.NET has a library for ADO.NET connectivity which makes it much easier to work with in/outbound relational data. Another library binds data to thick and thin client components, and has recently been enhanced to make AJAX field-level processing with the DBMS nearly transparent. All of this is in the docs. - For VARs who support multiple platforms, mv.NET works on just about anything out there (see the FAQ). That's one code set for UV, UD, QM, D3, jBASE, and anything else you use or support. The bottom line is that you get all of the adhoc tools you're already using (plus more) in a single consistent package, from a highly responsive provider, and at a cost that is not zero but not overwhelming either. When people ask questions here about "how do I ...", I know mv.NET is the answer to most of those questions. Frankly the only reason why I don't cite mv.NET as a possible solution more often is that I'm not sure how to make the point without irritating our respected colleagues with constant mentions of this software. I hate pushy sales people too. My clients and colleagues have tried UO, PDP, and other related tools like the D3 Class Library or jRCS, and when they get to mv.NET they simply never look back. Sure, I sell the software and services, but I've been through the same school of hard knocks as many people here, and support mv.NET because it's good, I don't say it's good because I support it. If you want to understand what this is about, just send me an email, check out the FAQ, download the docs, and maybe even try the free trial. > Currently 90% of > this system still runs 'green-screen' and as such, things are often > driven from within uv - mv.NET may have its place in a system that > runs 90% via external client apps, however this isn't one of those > cases. That part about mv.NET's place isn't accurate, sorry. mv.NET, UO.NET, and all of these connectivity tools allow us to make the MV DBMS a valued component amongst many in an office LAN or enterprise WAN that includes trading partners. We can make use of our business rules just like other people use Java Beans or ActiveX, or whatever the flavor of the week is for component and framework technology. All of these connectivity tools (not just mv.NET) make our existing apps more valuable because they allow us to make use of other technologies designed for specific functions (rather than the well intended but often misguided efforts made by MV DBMS providers). And yes, in addition to that we can plug in to external applications and user interfaces, but these tools are not limited only to shops that are migrating 90% of their functionality out of the MV engine. > Universe in general provides almost everything we need to do what we > currently want to do, the implementation is often bizarre and > incomplete and severely lacking in usable documentation & working > samples, but with a little divination ( sometimes more ) it can be > figured out. Hence my posting here. Your comment says more than I could hope, thanks. :) > As for my question, I am leaning toward just sticking to callHttp > rather than fighting with the SOAP API - but the jury is still out > for another day or so. > > Gerry I sincerely wish you luck with whatever solution you choose. My company provides solutions with an altruistic desire that MV shops make the best of our (all of us using MV) chosen technology, and that they're profitable doing it. If you're doing that with the tools you have, then I don't want to sell anything that you don't need. If you feel like you've been beating your head against a wall on various projects, or you still don't have the tools you need to effectively accomplish business goals, then I offer to share an alternative that I've found. Regards, Tony Gravagno Nebula Research and Development TG @ removethispartNebula-RnD.com Nebula R&D is a worldwide distributor of mv.NET, providing software, development services, support, and consultation to VAR/developers and end-users. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
