Any flavor that has a native ADO.NET provider?

[timbered]

Does anyone know of any current Pick implementation that has an ADO.NET provider?

[Martyn]

I am not technical enough to answer about ADO.NET specifically, but OpenInsight (OI) has good support for .NET generally through NetOI and RevDotNet.  Our developers and VARs often interface with and use .NET components in their applications.  In one of my demos from about a decade ago, I had a wrapper which used a .NET control to show a load of image information for a .jpg file captured on a DSLR camera.

RevDotNet functionality is contained in a series of APIs that OpenInsight programmers can call to create and manipulate .NET classes. These can be either visible classes (like Tree Controls, ListView Controls, etc.) or functional classes (like encryption classes, etc.). . . .

Using the NetOI .NET assembly, you can code entirely in Visual Studio (or your development environment of choice), and develop a Windows application that uses OpenInsight as its data source. The NETOI assembly contains classes to communicate with the OpenInsight Engine Server (the Server class); open and communicate with files (the OIFile class); and manage records and selectlists (the OIRecord and OISelectList classes). Using NETOI, you can perform all the basic file I/O needed to use OpenInsight. . . .

If I learn more about support for ADO.NET specifically, I'll post an update here.

M.

[Martyn]

UPDATE - OK, so it looks like I misunderstood.   

From my tech team - You mean access OI through ADO.net ? No

Sorry.

[Bob Markowitz]

ADO.NET is one of the components of mv.NET and works with all Pick implementations (almost).  mv.NET Adapter Objects supplies a full ADO.NET.data provider implementation offering a standardized read/write interface to MultiValue databases. With optional SQL Select, Update, Insert and Delete command syntax support, it is ideal for non Multi-Value aware programmers to quickly start work using the full capabilities of ADO.NET functionality.  Some features:

High performance data retrieval

Advanced MultiValue/sub-value handling

Fetch-on-demand retrieval for the mvDataReader

SQL and MultiValuequery syntax

Sophisticated MultiValue/sub-value data 'exploding'

Typed DataSet generation

Automatic maintenance of Multi-Value/sub-value positions during update of normalized data

Sophisticated session management

Automated data dictionary usage

Remote connectivity support

Optimistic and pessimistic locking support

But I am only a salesman and what do I know.  Did I mention Evoke?

[Tony Gravagno]

As both a technician and a provider of mv.NET services, I'll verify that the ADO.NET provider in mv.NET is quite good. Fill a table, bind to a grid, it's pretty cool.

That said, one doesn't absolutely need a product for this. If you look up how to create your own provider you'll see that any data source is adequate for the task. Under the covers mv.NET uses its own Core Objects for the MV access. You can do the same with this or any tool in this industry. I'm not saying anything against mv.NET. I'm saying this is an excellent Convenience product for which there is a cost. There are other Convenience products that offer less convenience for a lower price. That goes down to free tools that provide no convenience whatsoever. From there you have to decide whether you want to pay for someone else to maintain a tool of Convenience for you, or if you want to do that work yourself, paying for it with your own time. It's not that tough for this one feature. But the question is about what your time is worth. That is where these convenience tools often become pretty easy to justify.

HTH

T

[geneb]

On Fri, 22 Mar 2019, Tony Gravagno wrote:

> As both a technician and a provider of mv.NET services, I'll verify that
> the ADO.NET provider in mv.NET is quite good. Fill a table, bind to a grid,
> it's pretty cool.
>

How does it stuff a multi-dimensional record into a two dimensional table?

tnx.

g.

--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[Albert Kallal]

ADO.NET supports the ODBC provider. So in theory any vendor that supports ODBC should work.

You certainly will likely have to setup some mapping of dict items (columns) to expose the columns.

So just as a FYI, any MV vendor that supports ODBC quite much means that ADO.net should work just fine.

ADO.net works with
ODBC providers

oleDE providers

SQL provider (most common)

Now of course if you have a truck load of code say using oleDB in .net, then you might want to find a MV vendor that supports oleDB.

However, all of the data objects you use in .net will work the same with any of the above providers, but the code for SQL commands etc. will have to be declared for the given provider, but the data objects should work the same for any provider.

Regards,

Albert D. Kallal

Edmonton, Alberta Canada

Pleasenos...@msn.com

On Thursday, March 21, 2019 at 9:05:41 PM UTC-6, timbered wrote:

[Albert Kallal]

>>>How does it stuff a multi-dimensional record into a two dimensional table?

There are useally two ways.

The code library will offer a read command. The result is VERY much like the MAT read in pick (the result goes into a array, and the multi-value delimiters will be in that row of the array.

However, to really work say with ODBC, what the MV vendors provide is a set of mapping commands.

(on older D3 systems (the last time I used this, the command was create-view).

These commands map each table to a SQL (odbc) table.

And if you have some MV values, then that becomes a child table, and you have to execute a command to map out the child table as a separate name.

So, once all this mapping is done then you can hit, update and run SQL queries on that data as if it was SQL server, or any other SQL system.

So, for any MV column, or  controlling + dependant set of controls, you can map these out with a one time command on the MV  side.

So, if you have say 3 sets of mv fields (controlling + dependent), then you wind up with 4 tables you can (have to!) query on from the ODBC side.

But if you have say 5 mv columns (not controlling + dependant), then you have to map out the 5 mv columns into separate tables.

Once done, then you have SQL + ODBC compliant tables available for the client software running on your desktop or for whatever.

So any system that supports ODBC will now work. (even the query tools in Excel can work with such data).

You can even link tables from say Access, or run crystal reports on that data.

If your table designs are good in MV land, then they map rather well to SQL. If the table design in MV land is poor, then the mapping process tends to be rather poor also.

I mean, often we find dicts that are VERY messy and there is multiple field names that  are of the same column.  But, if good dict rules and designs were in place, then the mapping works quite well indeed. I should point out that such interfaces provided usually go beyond just using ODBC, and there are options to call data basic routines, do conversions (mv CONV) etc. And often it is better to just grab a record like in mv code as opposed to using JUST sql + ODBC drivers.  

[geneb]

On Sun, 24 Mar 2019, Albert Kallal wrote:

>
>
>>>>> How does it stuff a multi-dimensional record into a two dimensional
>> table?
>>
>> There are useally two ways.
>>
> The code library will offer a read command. The result is VERY much like
> the MAT read in pick (the result goes into a array, and the multi-value
> delimiters will be in that row of the array.
>

I knew about that - I've been using the .Net MVSP lib for D3 (with my bug
fixes applied) for a very long time - I just didn't know what witchcraft
went into squashing a 3d form into a 2d plane. Based on how you described
it, it's basically a hot mess. :)

Thanks!

[Dick Thiot]

MVON# from ONgroup has true ADO.NET native capability since you can use the Microsoft ADO.NET library to access your MultiValue data.  As mentioned previously you need a way to describe your MV data in a normalized schema but that capability is built into MVON#.  You only need to create schemas for the data that you want referenced from tools that require a normalized format, not all of your MV data structure.  You don't even have to define all of the attributes in a file, just those that you want to expose.

--
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+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Tony Gravagno]

geneb wrote:
> How does it stuff a multi-dimensional record into a two dimensional table?

Gene : mv.NET comes with a PDF just for Adapter Objects. Please email me if you'd like to get it.

The doc contains a section on Normalization which defines the only two options available : We can flatten our data into what I call a "view file", and do this on a periodic basis or with triggers, etc. Or we can let mv.NET dynamically normalize in real-time. This latter option is the magic sauce that we all look for when any product claims to support ADO.NET.

The mv.NET Data Manager facilitates the maintenance of Extended Dictionary Data. In the DM you can give a file a single Table name, and specify the names of the normalized tables (views) that are exposed by the file. Further, you associate specific attributes and their values and subvalues with these views, and of course all of these fields get their own column names, data types, and other schema details.

The result is that when you fill a DataSet, you get you get multiple tables, even though the MV data is contained in a single file (and translated fields).

To be complete, when you write data back to MV through ADO.NET, the normalization does the reverse operation, updating specific attributes, value, and sub-values.

You can also fill a DataSet with a BASIC program (as a Stored Procedure), so you really don't Need to do the extended dict model stuff. A BASIC program can return schema info as well as the data to populate the desired schema.

A few of my clients have hired .NET developers who know nothing about MV to code their client-side and middle-tier code. After the Pick guys helped to map the extended dicts, the .NET guys used Adapter Objects for all of the access. This is one of the great things that I've always appreciated about this software. It's something that every end-user should be aware of because it answers that question about how to modernize without getting their MV people to have to learn a new language.

HTH

T

[geneb]

On Tue, 26 Mar 2019, Tony Gravagno wrote:

> geneb wrote:
>> How does it stuff a multi-dimensional record into a two dimensional
> table?
>
> Gene : mv.NET comes with a PDF just for Adapter Objects. Please email me if
> you'd like to get it.
>

Sounds interesting, but not enough to get sucked into a per-seat licensing
model. It's painful enough with D3. ;)

[Tony Gravagno]

geneb wrote:
> Sounds interesting, but not enough to get sucked into a per-seat

> licensing model.  It's painful enough with D3. ;)

I hear ya, but "per-seat" for mv.NET isn't 1-to-1 with the DBMS. Many processes can make use of the same DBMS port using the built-in pooling mechanism.

While bean counters think this is some kind of technical trick to cheat the DBMS companies out of revenue, session pooling verifiably keeps sites on MV when they otherwise would have left. It keeps revenue flowing rather than reducing it. Session pooling is exactly like the checkout lanes at the local grocery store:

When more than a few people queue up in one lane, the store manager knows they need to open a new lane so that we hear those lovely words "I can help the next person over here". Without that, some people will just walk away from their carts in frustration, not buying the goods they've loaded up, and they may never return.

So with a single mv.NET license, you have the benefit of the ADO.NET library, and you get the ability to queue up multiple processes like that single checkout lane.

But with two licenses you get the second checkout lane, and consumers are passed to the first available DBMS port. The throughput is Much better than two dedicated ports. As you expand on that with more sessions, many of your users get zero wait time as the session manager service brokers all requests to available DBMS ports. This is maximizing the efficiency of the DBMS licenses. And for that convenience we pay a price.

By adding mv.NET into the topology we reduce the need to add more costly DBMS licenses to accommodate load. We can use these tools to modernize our applications and keep more people on the platform, thus keeping the revenue flowing to the DBMS providers. By demonstrating our ability to scale, MV people keep their jobs and the industry continues to move forward. The alternative is the 1-to-1 licensing and special rates provided by the DBMS companies, which force end-users to leave the platform. With pooling, we and the DBMS companies get "some percentage of something". Without it, we all get "100% of nothing" in the end. I'm not saying mv.NET is saving the industry, but I guarantee you that companies using it have avoided management inquiries about modernization and scalability, they've avoided the threat of migration, and they've been able to respond to their business challenges. Conversely, I know sites that have dumped MV because they thought they had no way to do all of the things that I've been talking about for a couple decades.

None of us like extra fees, but I think the costs of licensing for most of these products vastly outweighs the costs and consequences for not using these products, for individual sites and for the industry. Stated another way, overall, the costs are an investment in long-term expense reduction and (often) long-term revenue gains. It's not a pure expense to be avoided. And if you can keep your company on MV by bringing in product a product that has a pricing model that you don't like, weigh the "value" : Is that cost perceived as being beneficial to the company? Does that cost keep the company on the platform, saving them migration costs? Do employees keep their jobs by bringing in supplemental technology? Are you really interesting in saving the company a few hundred bucks when it could cost jobs and the cost of replacing an entire IT department? Meh. When I look at it like that, the costs are inconsequential.

If you want the benefit of ADO.NET, you could write your own interface. But at run-time you would be stuck with the above scenario as you try to put all queries through one port connected into the DBMS. To fix that problem you could write your own session pooling manager. Gene, I trust you can do that, most others aren't so skilled. For this purpose, convenience products like mv.NET were created. All of the products in our industry are convenience products if you look at them - we could create all of this stuff on our own with the right skill, time, and money. But each of us needs to weigh the Perceived cost of convenience with a Perceived sense of Worth and Value. This is entirely up to individuals and their companies. The licensing model is not something that we can reasonably summarily dismiss with a "one perception fits all" comment. mv.NET fits well in some scenarios, not others. I don't lead with tools, I try to understand specific challenges and then see if I have solutions in my toolbox, which changes over time. For what it does, particularly with ADO.NET, in my opinion the cost/value proposition of mv.NET has always competed well with other make/buy options. YMMV

Best,

T

[geneb]

On Tue, 26 Mar 2019, Tony Gravagno wrote:

> geneb wrote:
>> Sounds interesting, but not enough to get sucked into a per-seat
>> licensing model. It's painful enough with D3. ;)
>
>
> I hear ya, but "per-seat" for mv.NET isn't 1-to-1 with the DBMS. Many
> processes can make use of the same DBMS port using the built-in pooling
> mechanism.
>

I get that, really I do. :) I just find it offensive to pay one guy to
store my data and another guy to access my data. ;) I'd be interested if
they licensed per-developer along the lines of Infragistics, and got rid
of the bottleneck the pooler represents. :)

> So with a single mv.NET license, you have the benefit of the ADO.NET
> library, and you get the ability to queue up multiple processes like that
> single checkout lane.

With a per-developer license, I write my applications and open as many
simultaneous checkout lanes as I need, when I need them. :) (and this is
exactly what I do with mvsp.)

Session pooling isn't going to save MV. Proving to the management types
that there's new blood coming up behind an aging workforce will. Right
now all they see is existing MV greybeards retiring and only nearly
equally as grey beards replacing them. It's "safer" to keep lighting
money on fire to the IBM & Oracle gods.

[Dick Thiot]

Most of the MultiValue vendors today offer a method of connecting to the database from modern frameworks, languages, tools, etc.  I think that Tony's original point is that mv.NET supports ADO.NET out of the box and it has a more robust, elegant way to handle large numbers of requests while limiting the number of licenses consumed on the database.    I have worked with FlashConnect, MVSP, UniObjects, U2.NET, jRCS, etc and while all work well, I have found mv.NET to be robust for high transaction environments or worry-free implementations.

Dick

[timbered]

Perhaps I'm missing something, but when Gene says "per-seat", doesn't that really mean "per-connection" (or "per-user")?

I can have 100 (Windows) login IDs but only 10 Pick (connection / login) licenses. All 100 Windows network users can log in and start my Windows software, but only 10 can use the database at any one time (simultaneous database logins + phantoms + ODBC connections + queries <= 10)

A "developer license" is for something in use in the software itself. You can write Pick Basic (containing subroutines you have purchased with a "developer license"), but you still have to buy a version of Pick to run it (with per-user licensing.)

Right?

My biggest pet peeve is when companies do both ("royalty fee" or "distribution license"). I use their product to develop some software, then they charge me when I sell my product to my users. I refuse to buy into that model, no matter what they are selling, just on principal. Like going to a bar and having both a cover charge and a 2 drink minimum.

And Tony:

I would be interested in seeing that PDF re: MV.NET Adapter Objects.

Is MV.NET licensed "per-user"? And that is on top of the license I need to purchase for the underlying MV system, correct?

I guess to Gene's point, MV.NET is used in the development part ("per-developer") but is also used in the run-time part ("per-user")?

Thanks,

T.

[Tony Gravagno]

As I write this it smacks of a huge advertisement for many reasons. So let's say up-front that this is a huge [AD] for products, consultation, and development services ... but it answers the questions that were asked, so ...

[AD]

@Timbered, there are a lot of terms being mixed here. I'll try to provide clarifications for mv.NET with bullet points. This should have been a blog, but here we are. Please ask about any of these points if required.

A session license is bound between a middle-tier Windows server and one MVDBMS.

When the first client connects to the middle tier, the session manager service starts a new connection to the DBMS, and routes the request all the way through.

The session does not automatically disconnect and reconnect on every request. It remains connected so that the next request moves through without the burden of a new connection.

When connected to the DBMS on a licensed DBMS port, that session license is in-use. In this respect, there is a one-to-one relationship between the session license and the DBMS license.

When another user needs a query processed, the session manager service looks for an open session.

If there is an available session, not currently in use by another user, the request is routed to that session. We see here that the DBMS license is still truly consumed by only one user at a time. It's physically impossible to multiplex two users into a DBMS connection at the exact same time.

If all active sessions are in use, whether one or more, new requests are queued for processing to the first connection that becomes available.

To recap on that...Assume you have 3 users and 2 mv.NET sessions.

User1 grabs session1 and might release it quickly. So a request from user2 will be processed on session1 immediately afterward.

Assume user2 on session1 has a longer query when user3 comes in. They will be connected to session2. ("I can help the person who is next in line!")

Now user2 releases sesssion1 and user4 comes in. They get session1 again.

The other sessions are only used as needed.

Since each session is logged into a specific account, it will only process requests on that one account.

I have a client who has 8 web portals, each of which integrates with a single D3 account. They have mv.NET session licenses dedicated to specific portals. So there are 5 licenses for one portal, 2 for another, 1 for another, etc.

Where there is only 1 license, we expect low volume, like the "10 items or less" express lane. In this case it's OK for user2 to wait behind user1 for a few milliseconds.

For greater volume we allocate more licenses (check out lanes) and spread the load.

For each of those portals we have tens to hundreds of named users, people around North America who randomly need access to their applications. They are logged-in to the application, but they are only actively using the connections when they interact with the UI.

We see here that while there is a one-to-one ratio of mv.NET sessions to DBMS licenses, this is not related to the end-user count. There is no licensing for named-users, though applications written over mv.NET can certainly employ that model.

To be clear, you only get as many mv.NET session licenses as you wish to handle expected load. There is no minimum, and the count is not bound to the server DBMS license count. In the above example, we have 29 MV licenses, 8 portals, and something like 12 mv.NET sessions to broker requests. We allocate and de-allocate those licenses as required. We can also increase and decrease the license count as required by issuing a new key, and the support fees for the licenses are pro-rated.

The session manager offers a lot of options to manage how this all works:

Sessions can be connected to MV ports when the manager is started, so there's no run-time burden to login.

Sessions can disconnect after a period of inactivity. Consider 3 sessions, session1 is always in AccountA, session2 is always in AccountB. Session3 will only connect if one of the other ports is already processing an active request and a second request comes in. It can then disconnect and connect to the other account if required.

If a connection dies, the session manager starts a new session to continue processing on another MV port.

The balance we seek is to get as few mv.NET session licenses as possible, dedicate some to the applications/accounts that we know are going to be hit a lot, and let a few others float just in case there is unexpected volume.

There are many options for timeouts, for connections that take too long, for logins that take too long, or simply to allow processes to wrapup gracefully to release resources.

The session manager service can broker connections to many MVDBMS systems for almost all MVDBMS platform types.

This is all done with a single, uniform library.

For all of those "what about..." scenarios, know that there are options available, whether in settings or with coding techniques.

Connection libraries like QMClient and UniObjects do not have their own pooling.

For those of us who support multiple MV platforms, we need different client code, or our own custom universal wrappers.

If we choose to write our own session management, we have to do all of that on our own, or we can pay the DBMS providers to use their mechanisms.

So in this respect, the mv.NET session manager is itself a convenience product for end-users, to help them to maximize the efficiency of their databases.

There is a developer license which includes software and support.

A single developer license can be used to create apps for any number of end-user sites, of any size. (This is how I personally use it.)

The developer license is included 2 session licenses. These allow the developer to connect to any MV platform for any purpose.

The developer can use one license himself and give one to a client.

The cost for the developer license is the same as the 2 session licenses, plus just a little bit more for developer support.

I've had people buy the developer license just for the 2 session licenses, and for the extra few bucks they have the benefit having their own developer toolkit.

The developer package provides value that earns its place as a separate product, and thus its own licensing. It includes a library that is more familiar to MV people (Core Objects) and one more familiar to RDBMS people (Adapter Objects). It includes an ORM package similar to Hibernate or CSLA, but completely integrated with MV. It also includes tools to facilitate development of REST services. There's even a little report generator built-in.

So yes, there is a cost for the developer license. This is because the sessions can be used anywhere, and for the support. But as you see this is not like some products that cost a huge amount for the developer And there is a separate huge cost for end-users.

The pricing model for mv.NET isn't rigid. There are quantity discounts both for sessions and for developer licenses. We can also offer a special pricing model for consumer applications, mobile, IoT, kiosks, and others, where mv.NET is a simple component in a larger network. This is ideal for those situations where you really have no idea how many sessions you're going to need, but you know you need a Lot of them, and you can't have the cost of connectivity inflate your consumer pricing by some multiplier.

Back on target with ADO.NET, that is included as one of the features. However, ask yourself if you really need it. Why not read records and use conventional methods to create DataTables, etc? Your back-end interface doesn't need to be the same as the mechanisms you're using with your UI. In fact, that's a violation of separation of concerns. The data access (model) should be completely abstracted from whatever you're doing in a view or controller. If you really want to use ADO.NET, yes, mv.NET is awesome for that and all of the above features.

If you are OK with rolling your own columns and rows, but you still want pooling, consider Linkar. It includes most functionality that we appreciate in mv.NET. It does not include features that few of us use in mv.NET. It has many other features that are not in mv.NET. The cost is much less. And it's aggressively supported.

You may also consider a hybrid option - like asking someone like me to create a wrapper for Linkar that will accept and return result sets in whatever class/format you require, while you focus on the UI in the front end, and providing data from the back end, without concern initially for how the middle-tier works. This way you get the best of all worlds with a low connectivity cost.

Please feel free to contact me about mv.NET (and that PDF), Linkar, and anything else related to databases or communications. :)

Tony Gravagno   
Nebula Research and Development   
TG@ remove.pleaseNebula-RnD.com   
Nebula R&D : Sells and supports D3. Provides management consultation,   
and advanced modernization development services.   
http://Nebula-RnD.com/blog (site currently under maintenance)   
http://Twitter.com/TonyGravagno   
http://LinkedIn.com/in/TonyGravagno   
http://LinkedIn.com/groups/Pick-Users-Group-64935   
https://bitbucket.org/FOSS4MV   
http://mvTalk.Slack.com    

[/AD] :)

PS: Please do not assume any inaccuracy or omission is intentional or evasive. While this is already huge, I rattled it off quickly with no intention to be fully comprehensive, only to clarify existing confusion. I will be happy to correct anything that's incorrect, and provide more information as it seems reasonable, just ask. Thanks.

[joseba]

In order to clarify what a pooling system is I recommend you to take a look at Session Pooling, configuring Linkar EntryPoints video in Kosday blog:

https://www.kosday.com/blog/session-pooling-configuring-linkar-entrypoints/

About ADO.NET: Usually with this kind of tools you can use the mv database directly reading, writing, selecting, etc. But there are some situations where you need  "standard" access to the MV Database. In a few days Kosday will present a new Linkar version. This version includes a new SCHEMAS definition that can help with this. Also Kosday will present a new Linkar plugin, Linkar Power BI connector. This pluging is a native PowerBI data source to mv databases. Our development team has created it with Linkar and actually has created an ADO.net connection.  There is not an ADO.net Linkar connector, it is a PowerBI connector, but we can help you about how we have created it (remeber that Linkar is a set of tools that allows you to create what you need in any programing framework).

In a few days we will present all the new tools you can find in Linkar. Also, you can see us at Spectrum in Phoenix, tuesday 10:30 and all days in the exhibition room.