I was just on the phone with a prospect who is looking for a
completely new application and related website(s).

On one hand, all of my projects are Pick-based - for all of the
reasons we know here. I'm comfortable with the tools and know they
will make for a fine solution.

On the other hand, I'm asking myself if it's really fair to put Pick
into a new shop. There are precious few Pick people who are really
comfortable with end-to-end development using modern/mainstream tools.
If and when this company wants to find other developers, will I have
done them a disservice by building everything on Pick?

It seems like most efforts to evangelize the platform fall flat. Of
the few people in this community who are interested in marketing MV to
a wider audience, no one including the DBMS providers will pay for it.
The net effect is that guys like me are left to fight this uphill
battle one end-user at a time. It's tough enough in this economy to
sell services. If putting Pick on the table is going to cost me a
gig, it's going to be one of the first things coming off the table.

T

On Apr 14, 8:35*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
The decision has nothing to do with the fact that you could probably
do the job better, faster, cheaper with Pick and everything to do with
your conscience. If you remember the salad days of Pick, few of the
developers had much consience. Interestingly enough the survivors
seem to be the ones who did not have the "dump it on the loading dock
and run" attitude I do very little outside of supporting a few old
customers and of course the various family businesses. I'm even
becoming reluctant to do new development internally because my rather
massive extended family has abandonded Pick with only one exception.
Things change - not always for the better.
If you decide to propose something other than Pick, I'm sure there
would be much interest here in both what and why.
BobJ.
It seems to me that Pick is still the best choice for a developer who
is going to market the application without saying much about how it
was built or for a few who post her - Henry is the best example - who
develop the software for their own business.

On Fri, 15 Apr 2011 02:02:14 -0700, Robert Joslyn wrote:

use anything else your project will be a waste of time
for some stupid fucking reason -- just because the system became labelled as
"old" -- mainframe -- it was completely abandoned by many the skillset was lost
the approaches were lost

there is a word used a lot "progress" -- "progressive" when things are actually
regressing

change is not always for the better -- there are massively wasteful projects
still going on all the time -- and people are excluded the true professionals
are exclude from what has actually become a cult

you people are cultists -- prospectus etc the fucking clique -- you're either
in or you're out

I happen to have always been out I was never "included" in your fucking game
which hasn't "progressed" industry at all

and the UK is socialist -- prospectus will employ morons with the same regard
as true professionals

they have done it all the time

its a massive stitch up

but I'm still alive you bastards and I will take your fucking game you fucking
cult morons

Hey Tony,

I appreciate what you're going through.

I've experienced the restrictions that SQL like systems impose, but I
worry about the MV future.

I think I currently would favor Cache that straddles the two worlds
without third party add-ons.

Douglas

<Hoping the alf storm is over/>

On Apr 15, 2:02*am, Robert Joslyn <bobjoslyn... (AT) gmail (DOT) com> wrote:

Hi
Rocket Software is one of the largest software companies in the world
and they have just paid a poultice to pick up U2 lock stock and
barrel. Cache is going gangbusters. Even Pick Systems/Raining Data/
TigerLogic is moving again.
I have worked on Pick database systems used worldwide in some of the
largest logistics businesses in the world. Here in Australia Visage
from a small company in Newcastle has tens of thousands of users.
Companies big and small use Pick databases everywhere they just don't
trumpet it because the system works and they don't need squads of DBAs
to keep it rolling. In fact as I write I suddenly thought of a
successful Singapore company currently developing Pick software using
Unicode for the Chinese characters.
We now have a NoSQL movement. Flexible development environments such
as JavaScript, Ruby, Python, Perl et al are rocking. What is the best
agile database for them - PICK. It is on the cusp of a renaissance.
If you are up to the job required then the customer will be
satisfied. The customer is normally far more interested in the colour
of his new car - yes blondes do like blue - than what database the
software is on. One unhappy wife trumps a thousand ace programs any
day. Just deliver the goods the best way you know how. Listening to
the users and giving them what they need is the most important part of
any project.
Peter McMurray

Tony,

Appreciate the soul searching (I do similar thimgs EVERY year or 2),
BUT, at the end of the day your prospect is after a SOLUTION. They
haven't come to you and said "find me a solution that runs on SQL
Server, or Oracle, or PICK for that matter! I assume that they have a
business problem and are looking for something that may take away the
pain .... and if this ends up giving them other tactical advantages in
the process, great!.

There are MANY facets to a "solution", and in my (limited) experience
an end user is rarely interested in what is under the hood .... if it
quacks like a duck & waddles like a duck, few people are going to ask
"is that a duck?". If you can show them how they they can save time &
money, now, and into the future, using a particular solution THAT
ADDRESSES THEIR CURRET & LIKELY FUTURE AREAS OF PAIN, then in my
experience, everything else becomes incidenta,l

How long do you think your commitment to an end user is going to last?
How loyal do you think THEY will be to YOU?

We have recently picked up clients that have changed systems 4 times
in the last 5 years!!! (they were all SQL based "solutions" .... not
that the clients cared about this. What mattered to them is that each
time they changed systems it cost them more time & money, and talk
about gun shy !!!

We still have our first client from 26 years ago. What started out as
3 ladies fashion stores has now grown to become a publicly listed
company with over 200 locations. Are you trying to look out for your
clients interests for the next 25 years? I'd suggest that you could
safely change your ffocus to 5 years .... and if you service the pants
off your customer over that period of time, I'd suggest that you would
then be looking at another 5 years, and another, and .... you get the
picture.

There are many factors that go into a "best" solution. Features.
Capabilities. Price. Performance. Service. Service. Service. Service!!

If you don't currently have access to a "best" solution that is pick
based, either widen your net, OR, switch to a platform where such
things exist, because your future clients are going to want "the
best".

You are already ahead of the game, because you appear to have a vested
interest in what is best for the customer in the medium/long term, and
I think it is unlikely that "pick" will disappear in the next 5 years
(and if you are having trouble finding a "best" solution locally, I
know of an excellent product out of Australia that is feature rich,
loaded with capabilities that has a great price/performance ratio, and
because it is Pick based there is ample scope for you to service the
customer & add value over the years .... gimme a call if you are
interested ;-)

Over the years your Mantra has been that you can do EVERYTHING from/
with Pick, even though most of the people on this forum may be un
willing, lack the skills or whatever, so I'd prospose the reverse
question to you .... WHY NOT PICK?

On Apr 15, 9:00*pm, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:
Good, nearly compelling arguments. Perhaps the trouble with Pick is
really the trouble with Dinosaur Pick Programmers who don't keep up.
If the customer can point and click, drag and drop, and things just
work - well that's a happy customer. Now how many Dinosaurs can
supply the point and click, drag and drop? Dick said the mouse is not
a business tool and he was more or less correct. But the mouse is a
symbol of "modern" computing. From my limited experience with them it
appears that Visage and Desigan Bias (or Bais, I can never rememberr)
are good tools for "modern" computing and it may be that SB+ will soon
join them. Even a Dinosaur can adapt a little
BobJ

Ross Ferris wrote:

I'm out of town and reading on a tiny screen so for now I'll be brief
here.

The answer to why or why not Pick seems to be answered in part so far
with ads for specific MV flavors. Hey, it's me, remember? I already
use almost all flavors of Pick available today and I'm familiar with a
wide variety of their pros and cons. The solution is also not about
just using the right MV developer tools - been there, been talking
about them for over decade.

The issue is not with MY choice but with what happens to the client
when I'm gone. My job as I see it is to write software and then get
out. If I'm invited back by the client for maintenance, it's an honor,
not to be expected because I've roped them into something that no one
else understands.

Why not Pick? You said it, Ross: "even though most of the people on
this forum may be unwilling, lack the skills or whatever". I've been
begging this market to get off its duff for years so that I/we can
continue to have a livelihood into the next decades. It hasn't
happened. The consequence is that many of our colleages have left for
more fertile ground. While I'm not inclined to pick up and follow
entirely, I'm at least now thinking about what it means to saddle a
new end-user with this situation that I've been warning about for
years. If people had heeded the warnings then we would all be
rewarded with a fertile market. Since that's not the case we face
unfortuntate choices.

Again, I'm typing fast and this isn't well thought out. More later.
Thanks for ongoing thoughts from all.

T

On Apr 14, 7:35*pm, Tony Gravagno <tony_grava... (AT) nospam (DOT) invalid>
wrote:
I'm teaching an undergraduate database course so I did some review of
the landscape again along with show what we do. While it can be easy
to justify past choices, once again after a review of what is out
there, I think I made the right decision to go with Cache' (MV) with
our software.

A few tidbits -- I showed how with a new twist on a tried and true
DBMS product, with Cache' we can specify our database schema as
classes and use IS-A and HAS-A relationships so that our SQL is
enhanced for MultiValue and for MV-like thinking. For example, you can
write

select OrderId, CustomerId->CustomerName from Order

This gives you the SQL projection, the MV Query projection (aka the
DICT), XML, and Objects, all from your source metadata in a class (aka
program). I showed how we can then have functions/methods (and
subroutines) so that when we update data, we cleanse the relevant data
to address potential XSS issues, etc as a matter of course, built into
our schema definitions.

We get both wicked fast SQL and the benefits of NoSQL combined, not to
mention the years of maturity that both the DBMS tool and the data
model we use have under their belts. After surveying the field that is
out there, with all of those products that declare themselves to be
NoSQL working almost exclusively for the company that wrote them (with
some exceptions) rather than being packaged in a way that will work
for other companies too (check out Twitter's Cassandra project, for
example). The NoSQL landscape is filled with really green tools, not
yet ready for prime time, with PICK and MUMPs being two exceptions
that have survived since pre-relational days.

Well, I don't think they fell flat. While I know I'm not a leader in
the move away from RDBMS tools, I think I made a contribution, with
more than 20,000 "absolutely unique" individuals reading my Is Codd
Dead? blog entries, including one where I placed Tom DeL's NoSQL logo.
Sometime thereafter, someone else "came up with" the name NoSQL. Maybe
that's a coincidence, but I think that many of us sent signals into
the air and helped the industry that is and will be moving beyond SQL
and toward tools much more like ours. One difference today is that
ours are tried and true PLUS they have these advantages. I will
suggest that Cache' is ahead of some other PICK products, but all MV
databases have some significant benefits. I guess I favor also having
a top notch SQL implementation so that the tools play nice with others
too.

While that is not 100% the case, I think you are right. Unfortunately
with Cache' they market their DBMS engine but they do not evangelize
MV to anyone but MV folks. I was hoping that when U2 was out from
under IBM, where you had the same problem -- they would surely have to
pitch RDBMS tools over MV to the industry -- then we would get more MV
evangelism. However, I think they are stretched thin. Revelation has
done some marketing outside of the MV space, I think.

I am a pragmatist. I had students doing MySQL/PHP projects. The RDBMS
tools are tools that work. I would not have a problem recommending SQL
Server to a customer if it fit their setting, for example. I have done
so in the past. I look at the cost of ownership for that setting. On
the other hand, I can see the writing on the wall that companies will
either be looking to move away from their "legacy RDBMS products" or
will be adopting new features that their RDBMS vendors figure out how
to paste into their RDBMS (which is what has been happening). The
legacy RDBMS is not where I would direct anyone who wasn't in that
world already. Cheers! --dawn

On 2011-04-25 17:08:50 -0400, dawn <dawnwolthuis (AT) gmail (DOT) com> said:

You should tone down the FUD, Dawn. RDMS have served very well for a
huge number of business situations and they will continue to do so for
quite some time, IMO. What we know today as the NoSQL movement was
born out of the requirements of a very few for the massive scalability
and distribution required by large Internet sites such as FaceBook.

Very few companies will ever require such scalability/distribution, and
such features offered by "NoSQL" comes at the cost of greatly reduced
functionality and weak data integrity when compared to a RDMS. Let's
not also forget that in the NoSQL world, there is zero standardization.
Once you deploy with a particular implementation, you are essentially
stuck with it unless willing to go through a rewrite. There is no
"plug and play" here. NoSQL fills a niche that very few companies will
ever need to consider. Most businesses would be best served by a RDMS
or perhaps a MV system, providing they can find a reliable source of
long-term development support.

As for MV itself being considered NoSQL. I think that is a stretch, as
most mainstream developers would not consider that to be the case.
NoSQL products are not about data representation as much as they are
about scalability and distribution, hence the reason for the completely
heterogenous data models among them.

High risk, indeed. It's much easier to gamble with a client's business
than your own.

Ouch. Why would anybody recommend MySQL? A well-documented history of
unreliability makes it terrible for anything even remotely mission
critical. Not just hearsay, I've personally been burned by MySQL
deployments on a number of occasions. It's junk, period. If one wants
a really good open source RDBMS, then the only two I would consider are
PostgreSQL and maybe Firebird.

Not sure what is your point as TG already acknowledged differences
between SQL implementations. And how are the slight incompatibilities
between SQL implementations any different than incompatibilities
between MV implementations? There are always migration issues between
database products.

So, if Google uses it, then it must be good for my business? Great
logic. Again, these companies require massive data scalability and
distribution requirements that very, very few businesses require or
could even take advantage of.

NoSQL is young, immature, no standards, and only applicable to very
specific data requirements. Recommending NoSQL for the majority of
business use is, IMO, recommending an incorrect solution.

--
Kevin Powick