Bob - I was with you up until the following:

"RJ" wrote:
I don't believe that's correct. Each pipe into MV, whether UO,
QMClient, Telnet, ODBC, etc, has a saturation point. There are only
so many bytes that you can push through the pipe. When you need to
push more data you need more licenses.

Further, if a single user is running a job that just takes 5 seconds,
that's 5 seconds during which no one else can use the pipe. The
solution to this is to get more licenses.

This is the way mv.NET works, and FlashConnect, and DesignBais, and
some others. These products provide session management that
coordinates many users across many licenses. This is a feature that
is not present in the D3 class library, UniObjects, or QMClient.
These products don't allow us to run away with licenses, but they do
allow us to maximize the efficiency of the licenses we use. MV DBMS
providers should embrace that concept to help sell more sites, rather
than worrying about more licenses in each site.

Picture your system as a grocery store with several checkout lanes.
If all the lanes but one are closed then people backup on the one lane
that's open. "Open lane 2" the manager shouts, and people shift over
to the other one. The store is now running in parallel mode rather
than serial - just like your MV system with multiple licenses. During
peak shopping time, all of the checkout lanes are open. If people
wait too long, they're going to leave their cart and walk out - just
like people will leave a website.

You need fast hardware, lots of memory, broadband networks, and more
DBMS licenses to support a lot of users. That's a fact of life that
we shouldn't run from - and we shouldn't scare the DBMS providers into
thinking they're going to go out of business if they get mainstream
developers to start using their software!

T

Kevin Powick wrote:

And he's posting about a commercial, platform-dependent,
single-language, proprietary solution in a thread where we're having a
very real discussion about multi-lingual, platform independent
interfaces. Doesn't that just accentuate the need for this? As a
worldwide distributor for mv.NET I could have mentioned that you can
use mv.NET from any language to any MV platform, but I didn't. Errrr,
until now.

Commercial products like U2Logic, mv.NET, and On.NET (re-branded
PDP.NET) provide value-add above the free libraries like UniObjects,
QMClient, the D3 class library (and soon .NET/Java libs for D3). But
for now we still need a freeware vehicle to MV with a common API, and
language- and platform- independence.

In fact, the language bindings being discussed have at least three
components:
1) Language-specific developer libraries
2) Communications to specific MV platforms
3) MV-side helpers that accept commands and perform functions
With a single API, there might be several implementations of each of
those components. I might create a MV.PHP lib that conforms to the
API, using U2Logic as the pipe to get into Universe. I might then
create an alternative middle-tier to get into all other platforms with
mv.NET. Someone might say "why use buyware?" and re-implement the
middle-tier in UniObjects for Java. Someone else might use QMClient
as the bridge to QM under a Java binding. The connectivity tools and
languages don't matter. What matters is that the developer lib must
conform to the defined API - and once we can code to our platform of
choice with out language of choice, then we can evaluate the value-add
of the various communication tools in terms of performance, license
consumption, stability, and other factors.

T

On Mar 14, 11:57*pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

I didn't think that the goal was to ease MV people into the relational
world. I thought you wanted to spread the MV gospel to the heathens?

So why continue to encourage bad design?

Which is exactly what you were advocating at the top of this post...
Easing MV people into the world of tools and technologies that have
been available to the RDBMS people "forever".

<sigh> The reason for their creation is irrelevant. The overall theme
of this thread has been about brining the MV "light" to the RDBMS
darkness. The bindings to do this have been around for years and it
still hasn't made a difference. Just like PHP-MV will not make a
difference. As you noted, features are not necessarily what drive
people to one platform over another.

Exactly.

--
Kevin Powick

On Mar 16, 1:06*am, Kevin Powick <kpow... (AT) gmail (DOT) com> wrote:

If we count Cache as an MV DBMS provider, then I think they would also
be an exception .... granted, they don't push MV down peoples throat,
but I believe the visibility of their product through mainstream
publications is quite high ....

Ross Ferris wrote:
From what I can see, Caché visibility amongst other DBMS products has
done absolutely nothing for MultiValue.

My faith in Caché as a viable MV platform is as high as it was a few
years ago. My faith in InterSystems as an excellent partner for MV
VARs and end-users is similarly high. My faith in InterSystems as a
market driver of MV technology into new sites has dwindled
substantially. I can't figure them out. They have a real gem there
but now they're acting like all of other MV providers: they either
don't know what to do with the product, or maybe their interest is
just to get MV migrations and not to sell new systems.

Selling the concept of a Pick/MultiValue database has at least two
issues. For anyone who knows DBMS history, you'll get a "is that
still around?" comment. But I'd guess there are only a small
percentage of people who would come up with that anymore. The other
issue is trying to sell a different DBMS model: "what? It's not
relational? It's not SQL? Why should I bother?"

But InterSystems has already skillfully played that game for years
with an Object database, not traditional Relational but certainly
compliant with all Relational rules, and their Mumps roots are as
comment provoking as the Pick platform. While they may not want to
take on yet another platform with the same challenges, they already
have, and I think they can do well with it if they'd just give it a
chance.

After a lot of consideration my only guess as to what is going on over
there is that they hired a team to create and maintain the platform,
but now that that work is done they still don't have Marketing people
who know how to package it. That said with full respect to the fine
Marketing people there who otherwise (IMO) do a better Marketing job
for Caché than any of the MV DBMS companies do for their products.

T

On Mar 16, 1:47*pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:

I tend to agree. Originally I had thought they they were going to get
some "product champions" in place to shake the trees alittle (a
somewhat different, though related, role to what I believe LeeB is
fulfilling) --> then again, we all know that "change" is a four letter
to many on this list ;-)

Cache also seem to run hot & cold, at least that is my observation
here in OZ. Even getting something as seemingly basic as firm pricing
(catering for connection pooling, which seems to be a non-event/free
if you use ZEN, but a major PITA otherwise) has proven to be so much
of an issue that it precludes even considering them as a viable partner

On Mar 13, 4:30*am, wjhonson <wjhon... (AT) aol (DOT) com> wrote:
Okay, point taken there. But all you are really going to do is create
a "flat file" that has record marks, field marks, value marks, etc and
a set of PHP functions to tear it all apart and put it back together.
In order to write it to the file you would have another issue, since
it will be a flat file you will have to create all the mid-level I/O
routine to read a block, if it overflows, write that block and a
pointer to the new block for overflow, etc. That's a lot of overhead
in I/O to do in PHP. Even reading it as a block is still a flat file
and you are reading logical "sectors" only you are calling them
"blocks." Basic concept is the same just you have to now block and
wait for the O/S to read the physical sectors. Then you have to do
all the bit fiddling and string parsing to figure out if you have the
right block or do you need to read the next block (overflow). At that
point it is a purely sequential search through overflow.

I guess this is better than read/writing flat files myself, but sounds
like a lot of overhead for PHP to handle and if blows up during the
write of a block...wow...look out...GFE has returned. There's a lot
of things that have to be accounted for as a DBMS that will slow the
whole process down.

If someone needs to keep enough data to warrant a database, then they
need to learn to use a real database and not some hybrid solution that
allows them "bridge" the gap, just jump that gap and get it over with
as it will probably outgrow the "bridge" rather quickly anyway.

Just my nickels worth...

M<