MultiValue apps without an MV vendor in the mix

[Dawn Wolthuis]

This group has been very helpful to me with wording, so that I don't say that SQL Server is an MV DBMS, no matter what it looks like, for example. I also appreciate tips such as writing "runtime machine" consistently rather than sometimes calling it a run machine. With MV folks or oldsters I sometimes call it a p-machine.

So, here's my next one.

For those using our MVON# toolset, even with the changes in wording, it is accurate to say that your MV application uses SQL Server as the DBMS and .NET as the run machine. I was thinking about how the language preferred by this group is not to say that Microsoft SQL Server is now an MV DBMS nor that .NET is an MV run machine. Where I was previously thinking of Microsoft as the MV platform vendor, if I remove such language (SQL Server as an MV DBMS, for example), the picture can be painted as users running MV applications without any MV platform vendor in the mix and, optionally, even without any MV vendor at all -- just you and Microsoft.

You can run your applications with no MV vendor in the mix!

MultiValue apps run right in .NET with SQL Server as the DBMS AND the C# source code is optionally available for the entire MVON# toolset. So, those with the source who are running their MV applications in .NET with SQL Server can opt for just their MV application with adopted toolset and Microsoft, that's it -- no MV vendors in the mix any longer, with the application running as a .NET app and the data all in SQL Server. "Freedom" is one of the words I hear from folks who might just be happy to move beyond the per seat stuff. 

Yes, that means you are running on platforms where everyone else is running, so it is good to also have groups like this one and linkedin to keep in touch with pick and pickies. Our customers think of themselves as more part of the Microsoft world (or Oracle). The "who's your daddy" answer is not an MV DBMS vendor and not us -- it is Microsoft!  We are an assist, not a destination.

Does this way of saying it resonate with you or sound off again?

--Dawn

Dawn M. Wolthuis

Take and give some delight today

[Wols Lists]

On 26/09/17 20:42, Dawn Wolthuis wrote:
> MultiValue apps run right in .NET with SQL Server as the DBMS AND the C#
> source code is optionally available for the entire MVON# toolset. So,
> those with the source who are running their MV applications in .NET with
> SQL Server can opt for just their MV application with adopted toolset
> and Microsoft, that's it -- no MV vendors in the mix any longer, with
> the application running as a .NET app and the data all in SQL Server.
> "Freedom" is one of the words I hear from folks who might just be happy
> to move beyond the per seat stuff.

"With MVON# installed, your SQL Server becomes a full-fledged MultiValue
environment ..."

As I said before, you need to play up the MVON#, and play down the SQL
Server, but I don't think that's too difficult. Things like "MVON# lets
you use Transact-SQL to access your MultiValue fields ..." (I believe
that's the case, no?). "With MVON# your BASIC code will run pretty much
unchanged in .NET". Etc etc.

As you can see, I'm stressing that MVON# is your MultiValue environment,
and because it's integrated with SQL Server then you can use your SQL
tools too. Before, you were stressing SQL Server to the point it didn't
sound like MVON# was even necessary, let alone an absolute requirement!

Cheers,
Wol

[Dawn Wolthuis]

I hear you, Wol, and I have decided to reserve the word "environment" for our MVON product that does have an "environment" from my perspective. MVON# runs applications in .NET where MVON uses SQL Server as for the DBMS but has its own runtime environment (runtime machine).

With MVON#, we use the environment provided by Microsoft, and you run your application in that environment (.NET and SQL Server) using the MVON# tools. We have tools and libraries, all of which run in the Microsoft .NET / SQL Server environment. 

I only used "MultiValue framework" earlier because Spectrum was choosing that as the way to talk about MultiValue now that it can be decoupled from the DBMS. From my understanding, MultiValue was originally the "Nelson-Pick" data model, then it was the PICK O/S, then it was an MV DBMS, now it is an MV framework. I can live with that terminology, although I might have preferred to simply call it a toolset including libraries.

So, my language is this -- MVON# is a toolset that let's you take your application to a Microsoft platform, a Microsoft environment (.NET, the full range of .NET libraries at your disposal, Xamarin development, etc), and to Microsoft as the "who's your daddy?" answer. That's why the focus is on Microsoft. We do not migrate a site from one MV platform or environment to another. We provide the tools to compile everything for use on Microsoft .NET with SQL Server using our libraries (that can be your libraries if you license the source code too).

Does that resonate with your understanding and does this terminology work for you?  --Dawn

Dawn M. Wolthuis

Take and give some delight today

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Will Johnson]

What about Query?
Do you use SQL to hit these background database?
Or do you have an MVON query language that acts like English / Access ?

To unsubscribe, email to: mvdbms+un...@googlegroups.com

[Dawn Wolthuis]

MV BASIC, MV Query, PROC, TCL, ED/AE, VOC, DICT -- Everything is there, running in .NET and SQL Server. I love showing it to people -- it looks just like UniVerse, for example, but under the covers it is a toolset, running in .NET with the data in SQL Server. 

When people see it and "get it" they are often blown away. It opens the way for a really solid business strategy for VARs and end-customers moving forward.

Grant, Perry, and the rest of the crew -- geniuses!

--Dawn

Dawn M. Wolthuis

Take and give some delight today

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

[Will Johnson]

But the actual implementation of the native embedded tables, is as non-embedded sql tables ?
I mean the multi-values.

[Dawn Wolthuis]

Not unless someone wants to do that. The out-of-the-box changeover utility uses SQL Server as the MV data store (since I know I cannot call it the MV DBMS, smiles)

We do a key-value pair with @ID as the primary key to the SQL Server row and @RECORD as the other column. So, the multi-values are all there in the delimited string, as expected.

Some like to normalize the snot out of their data and sometimes normalization makes a lot of sense (e.g. if independent data was improperly implemented as if it were dependent). 

So, it is an MV data structure and a SQL data structure. We have read-write views in SQL that give the SQL tools what they need and the MV applications handle it logically just as it would if it were in a hash table DBMS. Both MV and SQL reads and writes work. The feature set with this approach is gigantic. Just about any feature one would want in a DBMS is there other than a tiny footprint. For an MV implementation, it is solid, solid, solid as well as feature-rich.

--Dawn

Dawn M. Wolthuis

Take and give some delight today

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com