Having been around pick a long time, each year that passes, some neat-o
technologies that comes out tends to be something that pick had for 30+
years.

I can remember when UNIX folks talked about how neat the new "demand" paged
operating systems were. Of course, pick was like that from day one.
(totally virtual memory)

I can remember in the early 90's how big of a deal was variable length
fields for a database - this would save lots of disk space when it cost lots
back then!! .....again, pick had that from day one!!

I can remember all the hype about how Java is a p-code system with a
runtime. Makes it easer to port the system to different processors. Of
course we all know that a LARGE number of vendors used to exist for pick
systems..an they ran on every concavely conceivable of the day. (And, so is
the new .net stuff). Again, pick was a p-code based system. p-code
architectures are in vogue today...and we had that since day one (java and
..net are both these types of systems).

Then, XML came out. This hot new idea was a delimited string that could
represent a whole invoice. You think this was the hottest new idea on the
planet....again, pick has this delimited string concept from day one......

Then there is multi-valued fields....The new version of ms-access has
multi-valued fields..(here is a video..and multi-value fields are
mentioned).

http://www.microsoft.com/office/prev...cess/demo.mspx

Funny, each time some vendor points out how some new great feature is in the
marketplace, It seems it always came from pick!!

Somehow, I feel opportunities where missed along the way by mv vendors....

--
Albert D. Kallal
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
http://www.members.shaw.ca/AlbertKallal

Albert D. Kallal wrote:
Yes, and don't think it is a coincidence. There were enough people who
were successful with Pick or MUMPS or even VSAM files, for example, who
attempted to get the job done with RDBMS products and over the years
have been working to add in the features that were useful before the
relational model took hold. There are also a few noisy folks still in
the non-RDBMS space who might have each had some small impact that has
added up. SQL and the related data model are still king of the hill,
but that hill is eroding quite quickly right now.

And yes, I agree that the MV vendors have missed many-an-opportunity.
I think that other products will have picked up the necessary features
so that soon enough even I might be talking about MV in the past tense.
I would definitely prefer that the MV vendors had a clue how to
capitalize on their assets. IBM is starting to say "U2" out loud, but
with the IBM backing, these products could be leading in the XQuery
arena, for example, and they aren't even close -- IBM has selected the
SQL side of the house as the strategic approach to XML (I find this
appalling!). It's such a shame, although they still retain some of my
loyalty (with OpenQM redirecting some of my interest).

RD seems to have missed the mark by abandoning all prior interfaces to
Pick and doing ONLY XML interfaces plus abandoning their loyal
customers, aiming for the big boys instead. A couple of years ago I
wanted to call and sing the song I learned in girl scouts "Make new
friends, but keep the old; one is silver and the other gold."

And, of course, I have opinions about the others too. Cheers! --dawn

Y'all might just want to really read up about what 'They' mean by
Multivalued. I read that SQL 2005 had 'MDX' data. They called it
multivalued. I got excited. Then I read about it. Their idea is you
PREDEFINE what 'Counters' etc that you want to keep about records. When
Records are written into the database, SQL will update the Statistics in
the 'MDX' Cube. It has little or NOTHING to do with what we think of as
MultiValued...

Too bad they have still not see the light.

Is this another thread how great pick is to compare to the rest of the
world???
80's are over body...


Curt wrote:

Paul wrote:
I'll read that as "everybody" -- let me know if this means something
else.

There is a difference between "rah, rah, we are great and the rest of
the world sucks" chatter, which has some potential to influence
vendors, vars, or customers of MV to keep it moving forward or simply
serve as a community virtual feel-good party and...

influencing the future of software development to incorporate what we
have learned in the past half-century of software development tools &
techniques. Given that XML works with delimited strings of data, I
think there is much that MV folks, who have been largely outside of the
mainstream for years, can lend to the discussion. Folks modeling data
for XML are taking a trial and error approach, starting from scratch in
trying to identify how to model data, to a large extent. If we know
what it is we do that works well, we can help influence the industry
toward better-bang-for-the-buck software development without
reinventing all of the wheels.

For example, XQuery is really a dog-ugly language (I'm sure I could put
myself in some state to appreciate it more, perhaps requiring a
martini). If one were in a position to be able to limit their XML
schema to have only multivalues and not subvalues (by whatever names),
create virtual fields associated with a single file, skip the use of
attributes (compared to elements) or use them only for the @ID for a
record, etc, then one would think that the MV query language could be
"pointed at" a set of XML documents. It would be like a user friendly
XMLQuery-lite.

Another example is in discussing whether one-big-code file might be a
"best practice" in many cases, rather than considered a poor approach
to data modeling (as it is in an SQL solution).

So the threads that might sound like "rah rah" could be seen as a
contribution to the future of software development and not just some
lament for the past.

Apologies for the sermon, but you tripped my buttons. cheers! --dawn

Curt wrote:
I thought they referred to that as multidimensional since it is related
to their cubes. They do have multivalued virtual fields (prior to
2005). Additionally, I have heard that you can use SQL Server with a
two-valued logic. Does anyone know more precisely what you have to set
or do in order to use a 2VL instead of 3VL logic with SQL Server?

The cubes do have a relationship to MV data, but you are right that
multidimensional cubes (which are similar to MV files with multi-part
keys and materialized virtual fields) are different from mv fields.

They are doing a lot more than many vendors, much to my dismay.
Cheers! --dawn

I get sick of people bashing SQL at any chance they get. Such as your
comment about poor approach to data modeling in an SQL solution. There
is a reason why SQL databases have probably 90%+ of the market. I'm
not saying that pick doesn't have its place in the market but surely
you can see that some of these threads are all about how great we are
to compare to the rest.

Paul wrote:
Yes, there is a reason that is does have a high percentage of the
market (I doubt it is 90%) and in my opinion, there is no reason it
should have such a high percentage. I'll admit that one of my
professional goals is to help our industry move beyond SQL, at least
these two features of SQL: 1NF and 3VL. I have arrived at these goals
after considerable research, with plenty yet to go.

My interest is not so much "the market" but the practices of software
developers that have strayed so far from how to write
big-bang-for-the-buck quality software for businesses.

Many of those that I start are geared to gathering information related
to my goals of moving us beyond SQL to an approach that includes the
advantages of MV products. I'm doing a talk and demo next week as a
guest lecturer for a database class where they want me to show how to
model data without doing 1NF and with the use of a 2VL. I will use
OpenQM for this It isn't too long ago this would have been considered
heresy in a db course. This is progress, even if baby steps.

Cheers! --dawn

"Curt" <junkmail (AT) junkmail (DOT) com> wrote

Yes, I have read what they mean......

You can read about what they mean here:

http://blogs.msdn.com/access/archive...14/551556.aspx

In a nut shell, HOW the information is stored on disk is not really
relevant. While the extensions to ms-access were actually made for use with
XML and share-point services, it really is a adoption of a mv model. This
idea of allow multiple values being stored in a field that you define is
relevant. (this is not related to MDX data AT ALL!!!).

There is also extensions to the data engine, and EVEN SQL will query on the
multi-valued fields as a SINGLE FIELD just like it does in pick query (aql).

In addition, the reocredset objects will also return these multi-valued
sets too....

My only point that this is NOT a new concept, but what ms-access is adopting
is a MV ability here.

--
Albert D. Kallal
Edmonton, Alberta Canada
pleaseNOOSpamKallal (AT) msn (DOT) com
http://www.members.shaw.ca/AlbertKallal

more info:

<quote>

The complex data features will not upsize to SQL Server without changes, but
they will move to SharePoint just fine. The challenge here is the
underlying difference between the 2 platforms. Complex fields upsized to
SQL will show up as delimited text.

</quote>