mvDBMS issues

mvDBMS issues

Post by Bill H » Mon, 19 Jan 1998 04:00:00



I've been thinking lately, always dangerous, that there are several
problems within the MV marketing machine (assuming one exists).  There are
two issues I'd like to raise, and, I suppose, some ancillary ones:

  1)  providing access to mvDBMS software, and
  2)  providing 'runtime' packages for demonstrations.

In many large (and I mean large) companies there are tremendous resources
being allocated to 're-engineering' mvDBMS applications into GUI
applications that are 'open', often in 'ORACLE'.  The time has come, in the
'Client/Server' paradigm, where we're discovering that this structure for
business data doesn't work.  (Please note, this is not always true, but
humor me a bit.)

Oxford Health Care is the most visible example of an mvDBMS supporting the
growth of that company to almost $90 per share while ORACLE assisted in the
company's decline to about $15 per share!  This is no small matter!

Many companies are spending tens (10s) of millions of dollars on useless
're-engineering' projects that will return absolutely zero (that's $0).  As
a result, during this period of 're-engineering', which can easily last
several years, the mvDBMS systems (and they generally manage all corporate
cash flow and business information) languish with no more attention than
emergency maintenance!  So, what happens?  We have very old looking mvDBMS
systems that help create the impression that they simply need to be
replaced.  A SELF-FULFILLING PROPHECY.

Ok, enough of the obvious!  WHAT ARE THE mvDBMS VENDORS DOING ABOUT THIS?
The time couldn't be better for an mvDBMS solution to business problems!
Other DBMS vendor's applications are failing, too costly to manage, return
too little, etc, etc, etc.  This failure is now becoming evident, even to
corporate management.  It is still going to take some IS people a little
more time.  If IS people were made aware of the mvDBMS systems available,
they would begin to see its value.  HOW?

I am doing some consulting through a large, national, IS consulting
company.  I'm able to purchase Microsoft's 'VB-Enterprise' edition for, get
this, $24.99!  The documentation costs me $29.99!  What is Microsoft doing
that Pick Systems, UniData, uniVerse, and GA aren't?  They're getting their
product into the hands of those who are most likely to push their product!

Can I get an mvDBMS developers edition for virtually nothing?  Not even.
Don't get me wrong.  I have no desire to quible over little things.
However, you'd think the development of mvDBMS systems, the training of
mvDBMS development expertise would be critical to the successful marketing
of the mvDBMS product.  My goodness, these vendors could GIVE AWAY their
products to students and developers!  These students and developers would
create the market for the mvDBMS products!

The second issue ties into this first.  For those of us who have developed
products in an mvDBMS environment, getting these products into the hands of
those who can successfully market or purchase them is essential.

Why can't I purchase some sort of 'runtime' module from these vendors that
I can bundle with my software product to deliver to those who can review
it?  Why must I go through the 'awful' task of buying a license, giving it
away, get it installed on someone elses PC, install our application, get it
set up, and get it running?  This makes an otherwise simple sales tool too
difficult.  People don't buy an mvDBMS because it does something, they buy
it to run an application on and to interface with their other applications.
 Every application an mvDBMS developer sells will sell an mvDBMS license!

Another issue is: why aren't mvDBMS vendors hustling the corporate world?
Why are large corporations 're-engineering' away from an mvDBMS application
with no resistence from mvDBMS vendors?  Where are they when large
corporations are looking for solutions to their business problems?  Beats
me!?

Do others agree with this analysis?  Can mvDBMS vendors do something about
this?  Should they not lose sight of the forest for the trees?

Bill

 
 
 

mvDBMS issues

Post by M Sweg » Mon, 19 Jan 1998 04:00:00


: Can I get an mvDBMS developers edition for virtually nothing?  Not even.
: Don't get me wrong.  I have no desire to quible over little things.
: However, you'd think the development of mvDBMS systems, the training of
: mvDBMS development expertise would be critical to the successful marketing
: of the mvDBMS product.  My goodness, these vendors could GIVE AWAY their
: products to students and developers!  These students and developers would
: create the market for the mvDBMS products!

: Why can't I purchase some sort of 'runtime' module from these vendors that
: I can bundle with my software product to deliver to those who can review
: it?  Why must I go through the 'awful' task of buying a license, giving it
: away, get it installed on someone elses PC, install our application, get it
: set up, and get it running?  This makes an otherwise simple sales tool too
: difficult.  People don't buy an mvDBMS because it does something, they buy
: it to run an application on and to interface with their other applications.
:  Every application an mvDBMS developer sells will sell an mvDBMS license!

: Another issue is: why aren't mvDBMS vendors hustling the corporate world?
: Why are large corporations 're-engineering' away from an mvDBMS application
: with no resistence from mvDBMS vendors?  Where are they when large
: corporations are looking for solutions to their business problems?  Beats
: me!?

Hi,

        I think I can reply to this. Recently, we had marketing types
in from Unidata/Universe to talk about their Redback product. Currently,
they are developing their own ORB, development tools and Web server along
with developing an Oracle ODBC driver and Pick ODBC drivers. When asked
why they are developing everything in house vs. licensing it from third
party vendors (for speed to market), they replied that that is the preferred
way - the way to make money. Well, they wanted $20K US for Redback and that
doesn't include all the upgrade costs over the life span of the product.
Moreover, the architecture that they are doing is out of date; it is where
the internet was three years ago - not now. In addition, you are tied
to their s/w product development cycle and not ours that is currently
way ahead.  In addition, we are going to a three tier architecture using
the Corba ORB which puts all of our business logic on the 2nd tier and
allows us to become DBMS and language independent. Thus, the DBMS just
becomes a load/store mechanism on the 3rd tier and just a s/w add on
commodity: not an application hinderance.

        When asked where they are taking the Unidate/Universe/O2 DBMS
product line in the future, the answer was interesting. It looks like
the Unidata/Universe DBMS will stay separate and that O2 will be a totally
separate product line. The main product focus will be O2 and not the
other product lines. Yes, mvDBMS' will not be dropped immediately, but
any future technological upgrades and improvements will not be the
driving factor. Hence, we are shocked by this, and now are in the process
of reviewing our DBMS applications for the future. This very fact, will
now serve as the driving factor to move to the Corba ORB and in a
direction that will allow us to become DBMS vendor independent
and less reliant on DBMS vendors in general. Similar insights served
as the basis upon why we dropped the Sequoia computer product line and
the Picksys DBMS and switched to Suns and Unidata; it now serves as the
driving force to switch from Unidata to a totally different DBMS vendor
product line - probably ORACLE!

--
        Mike,


 
 
 

mvDBMS issues

Post by Bryan Buchan » Mon, 19 Jan 1998 04:00:00



says...
[snip]

Quote:>Oxford Health Care is the most visible example of an mvDBMS supporting the
>growth of that company to almost $90 per share while ORACLE assisted in the
>company's decline to about $15 per share!  This is no small matter!

What's the story on this ? (and you'd better watch those Oracle lawyers...)

Bryan

 
 
 

mvDBMS issues

Post by Tom Packe » Tue, 20 Jan 1998 04:00:00



>I've been thinking lately, always dangerous, that there are several
>problems within the MV marketing machine (assuming one exists).  There are
>two issues I'd like to raise, and, I suppose, some ancillary ones:

[snip]

I was thinking about this the other day.  For a start, here are some
relatively cheap suggestions:

1 - Pick World, Spectrum and N&R might want to send free subscriptions
to high end health clubs around the country.   You know how people
will read anything when they get to the gym and don't have anything to
read.  Put some articles in there about success stories.  I had
someone call me the other day who had made about 50 phone calls to
professional colleagues before finding one that had anything good to
say about their own computer system.  This is not an isolated
situation, Pick's best customer is a small business owner, find ways
to reach these owners and help them grow.

2 - Leave copies of these magazines on airplanes.  You figure if each
Pick person who flies left a copy of a Pick magazine on an airplane,
it might end up being read by someone who we might otherwise never
reach.  But they would have to dress up the articles to capture the
attention of the weary exec flying home from a far away division that
can't seem to make a profit.

3 - Target trade shows, how many people would read USA Today if it
weren't given out for free.  I have had more than one Exec ask me to
find out more information about something they read about in USA
Today.  How about having Pick mag's delivered to hotel lobbies and
maybe even rooms at targetted conventions.

4 - Bundle some screen generators and sponsor some Pick people to
write articles about doing things in Pick.  Right now we are losing
mindshare at a fantastic rate because there is very little people can
buy in the form of books, tools etc to  easily to come up to speed on
Pick.  With all the PC DBMS's you get a front end tool and buy some
books and in a couple of hours you can have a data entry screen.  How
long does this take in Pick?  No wonder people don't flock to it.

Tom

"Knowledge capital is not enhanced by chopping
of heads!" - Paul Strassman

 
 
 

mvDBMS issues

Post by Jacob Proffi » Tue, 20 Jan 1998 04:00:00




Quote:>Ok, enough of the obvious!  WHAT ARE THE mvDBMS VENDORS DOING ABOUT THIS?
>The time couldn't be better for an mvDBMS solution to business problems!
>Other DBMS vendor's applications are failing, too costly to manage, return
>too little, etc, etc, etc.  This failure is now becoming evident, even to
>corporate management.  It is still going to take some IS people a little
>more time.  If IS people were made aware of the mvDBMS systems available,
>they would begin to see its value.  HOW?

>I am doing some consulting through a large, national, IS consulting
>company.  I'm able to purchase Microsoft's 'VB-Enterprise' edition for, get
>this, $24.99!  The documentation costs me $29.99!  What is Microsoft doing
>that Pick Systems, UniData, uniVerse, and GA aren't?  They're getting their
>product into the hands of those who are most likely to push their product!

>Can I get an mvDBMS developers edition for virtually nothing?  Not even.
>Don't get me wrong.  I have no desire to quible over little things.
>However, you'd think the development of mvDBMS systems, the training of
>mvDBMS development expertise would be critical to the successful marketing
>of the mvDBMS product.  My goodness, these vendors could GIVE AWAY their
>products to students and developers!  These students and developers would
>create the market for the mvDBMS products!

I'll second this observation.  I do PICK all day at work and I'm one of
those geek-types who then goes home and wants to do it some more.  There
are three applications I want to develop for my own purposes that would
really help me with my home computing.  I'm a computer geek, but I can't
get my home machine to do what I want it to because I'm stuck with
excel, paradox or access to try to do anything with.  Extremely
frustrating.  I approached all the PICK vendors mentioned here so often
to find a decent single-user environment.  Best I could do came out at
over $300 (*don't* tell me jbase is cheaper--it isn't, not if you have
to buy the C compiler as well).  This may seem cheap to you, but it
isn't to me.  I bought it anyway.  It's great, but it hurt.

Recently, I got some training with SB+ at work (by Kevin King--excellent
class, BTW).  I don't get to actually *program* in it, mind, I just got
*trained* in it.  I wan't to use *that* at home, too.  If I could use
SB+ with my home PICK flavor (okay, for the curious, I settled on an NT
version of D3 that I run on Win95--no complaints, yet), I'd have a pair
of marketable applications (*I* think, who knows if there's a market for
it, really).  I could program some stuff for various tangential hobbies
that haven't been dreamed of, yet, by conventional development aids.  So
what's it take for a single-user SB+ server?  Don't ask.  It's more
expensive than the original D3 by a factor of ten.  There's no way I can
afford that.  I didn't bother asking what a runtime liscence for SB+
would cost (if such a beast exists), I was afraid of what the answer
might be.

So what are the consequences, really?  Well, I'll never get to use the
SB+ skills I acquired.  I'll never be the evangelist I was destined to
be for SB+.  I'll not be able to create the applications that (well,
IMO) would literally revolutionize certain extremely small, niche
markets.  That's one fewer SB+ developer, three fewer applications to
test the market's waters and who knows what else.  Perhaps it's because
I am one, but I've always thought that developers are key to the
marketing strategy for vendors of computer tools.  If you really want
sales, you need to *aid* the people who are making sales possible.
Maybe that's too simplistic.  I don't see what it couldn't work that
way, though--it seems to be working just fine for other software
development tools vendors.

Jacob Proffitt

 
 
 

mvDBMS issues

Post by Joseba Real de Asu » Tue, 20 Jan 1998 04:00:00


......


> ......
>         Mike,


   Well, very interesting. Do anybody believe that it is posible to
design a system TOTALLY independent from the Database? I do not. You
always will be dependent of something and i prefer to depend of
something i know well by myself.

Technology, technology, etc. . We talk about software that , as Mike
says, is old now over the internet. But if we think what the customers
have, what they want, and what they need many times we discover, at
least i discover, that nothing is real. Computer science is domained by
comercials that have no idea of technology. Only names and names.
Everybody want CHANGE no EVOLUTION. All you have is bad and old so take
it out, spend some years, some money and you will have the latest OLD
technologie doing the same that now so i will sell you a new one again,
an so on.

So take a look to ORACLE (and it is nothing against ORACLE). I know a
company that needs an accounting software package (problems with y2000
and euro). They need to buy a new database (now they have everything in
Cobol Files). His head company uses ORACLE so they said, i will use
ORACLE too. They talk with 5 companies that 'has' that software for
ORACLE (or any other RDBMS). OK, no problem. Now, their host is a big
new DIGITAL ALPHA with VMS as operating system because the software
company is on that environment and works really well. There are an
ORACLE VERSION for VMS on Alpha. Four of the OPEN, INDEPENDENT, solution
do not run on that environment because they have developed them with
OPEN, STANDARD tools that ACTUALLY where inherent to the Operating
System and the Database version of the RDBMS. The fifth one works
without problems because it was designed with ORACLE TOOLS but of course
does not run in any other Database so ......

And many of you will say, as the vendors of the product, the problem is
that they have an OLD , PROPIETARY OS, (OK Open VMS is Propietary but
TODAY is the only 64 bits OS in the market with tech solutions much more
better than any Unix and of course NT  and totally OPEN)

Another example may be NT. The most OPEN MODERN OS of these days. It
cames from ONE COMPANY, it is compatible with itself _well when he
wants_ and know it has 'an FTP server' (thanks to the Internet
Information Server). If you want to comunicate it with Novell, Unix,
etc. you MUST BUY software. Take a look at Linux. It is free, it has
SaMBa, NFS, Novell Connection, and whatever you want. And it is free
so...

Talking about the first post , Bill's one, by myself i can agree with
him but when i think about it i said:

    The database vendor has develop a product and want to sell it (Of
course they want to make their business, not my business)
    We tell Pick Systems, Uni(i don't know more), etc. that they must
have free versions, they must use third companies products to implement
in its product (of course for free) etc.
    And why don't we do the same with our software? Of course because IT
IS OUR BUSINESS. SO.....

    Actually now what i do is:

        I go to a customer, i told him to put a clean PC for me (not to
many). I install LINUX (free) on the PC. I install my copy of  D3/Linux
and activate it for 2 weeks (free too). I put my software in the Linux
box and in any of the Windows PCs they have on the network. I show them
how it works and go home. I always say i will came back in two weeks and
take D3 out of the box. I have done it in 3 companies during december.
In less than 3 days they has phone me, has buy a D3/Linux and has change
their existing box. Why? Because they have seen a SOLUTION in order to
use what their have and go to a complete new world. THEY HAVE SEEN it.
And that's our job. Nobody is going to sell D3, Universe etc.. They
provide us the technologie and we GIVE the solutions. What do we want?.
That everybody knows Pick and then we think we are going to sell it by
...... Poor people that think like that. We must work very hard,
construct good software solutions and try to live with our work.

    But we are not going to be as 'Mr. Gates' because we have a big
problem. We want that our software works well, comercials do not care
that, they only want to sell anything, they do not care. We must try to
send them out of our business (it has been our BIGGEST problem in the
last 50 years)

This are only my impresions but may be they help somebody

joseba real de asua

 
 
 

mvDBMS issues

Post by Tom Packe » Wed, 28 Jan 1998 04:00:00


Has anyone out there run into the company called Intersys which is
marketing a post-relational database optimized for transaction
processing.  Check out their website at http://www.intersys.com

I saw the ad in Computerworld and thought it might be Pick related.
While reading the web contents I was thinking that anyone of the Pick
vendors could simply cut and paste the content and it would be
accurate.  Not that I am saying to do this, just that the issues are
all the same issues as Pick faces, Intersys has the advantage though
of no past with the word Pick in it.

I still don't know what their technology does or how it works, but
they have a conference in Orlando in April.  It might be worth a trip.

Regards,

Tom

"Knowledge capital is not enhanced by chopping
of heads!" - Paul Strassman

 
 
 

mvDBMS issues

Post by Nick » Wed, 28 Jan 1998 04:00:00


I think this is a reincarnation of

M.U.M..P.S.

Massachusetts University Medical Programming System!

Old Pickie Nickie

 
 
 

mvDBMS issues

Post by Chester H. Johnso » Thu, 29 Jan 1998 04:00:00


I saw this add too and wondered if they were a Pick and just not wanting to
admit it.  It would be interesting to find out more about them.

Chester



>Has anyone out there run into the company called Intersys which is
>marketing a post-relational database optimized for transaction
>processing.  Check out their website at http://www.intersys.com

>I saw the ad in Computerworld and thought it might be Pick related.

 
 
 

mvDBMS issues

Post by Thomas Adam » Fri, 30 Jan 1998 04:00:00


Another mysterious pick-like database was cascade/DB.  You can find an
(outdated) ad for it at:
http://sunflower.singnet.com.sg/~concern/cascade.htm

According to an old post on the microquill site, they sold it but wouldn't
say to whom.  Does anybody know who bought it?  Anybody using the free trial
edition have any comments?




>Has anyone out there run into the company called Intersys which is
>marketing a post-relational database optimized for transaction
>processing.  Check out their website at http://www.intersys.com

<snip>
Quote:>"Knowledge capital is not enhanced by chopping
>of heads!" - Paul Strassman

 
 
 

mvDBMS issues

Post by Michael Talbot-Wils » Sun, 01 Feb 1998 04:00:00





>>Ok, enough of the obvious!  WHAT ARE THE mvDBMS VENDORS DOING ABOUT THIS?
>>The time couldn't be better for an mvDBMS solution to business problems!
>>Other DBMS vendor's applications are failing, too costly to manage, return
>>too little, etc, etc, etc.  This failure is now becoming evident, even to
>>corporate management.  It is still going to take some IS people a little
>>more time.  If IS people were made aware of the mvDBMS systems available,
>>they would begin to see its value.  HOW?

>>I am doing some consulting through a large, national, IS consulting
>>company.  I'm able to purchase Microsoft's 'VB-Enterprise' edition for, get
>>this, $24.99!  The documentation costs me $29.99!  What is Microsoft doing
>>that Pick Systems, UniData, uniVerse, and GA aren't?  They're getting their
>>product into the hands of those who are most likely to push their product!

>>Can I get an mvDBMS developers edition for virtually nothing?  Not even.
>>Don't get me wrong.  I have no desire to quible over little things.
>>However, you'd think the development of mvDBMS systems, the training of
>>mvDBMS development expertise would be critical to the successful marketing
>>of the mvDBMS product.  My goodness, these vendors could GIVE AWAY their
>>products to students and developers!  These students and developers would
>>create the market for the mvDBMS products!

>I'll second this observation.  I do PICK all day at work and I'm one of

I've wondered, and asked here before, why single-user Pick isn't given
away free.  D3 has an activation model which allows you to run
single-user without activation.  Only Pick Systems know how big their
customer base in single-user D3 is, but my impression is that anyone who
runs single-user Pick in a business operation will very soon need or
want multi-user, and those who don't will never buy so there's no loss
in giving it to them.  The profit in giving it away for private use is
that people would know about it and expect to find it at work, and when
they did they'd understand what it was about and that it wasn't
something eccentric.

The more single-user D3 that Pick Systems gave away free the more profit
they'd make.  Of course, any activation protection is breakable and the
method could become folk knowledge among 2600 types, but that would make
nil difference to business sales.  Certainly it's amazing that those in
a position to introduce Pick to their own customers are not given this
kind of encouragement.

Quote:>those geek-types who then goes home and wants to do it some more.  There
>are three applications I want to develop for my own purposes that would
>really help me with my home computing.  I'm a computer geek, but I can't
>get my home machine to do what I want it to because I'm stuck with
>excel, paradox or access to try to do anything with.  Extremely
>frustrating.  I approached all the PICK vendors mentioned here so often
>to find a decent single-user environment.  Best I could do came out at
>over $300 (*don't* tell me jbase is cheaper--it isn't, not if you have
>to buy the C compiler as well).  This may seem cheap to you, but it

I'd like to see D3/ProPlus downloadable, and runnable single-user.  You
don't have to buy the C compiler for Linux.

There'd very soon be excellent ODBC developments and transparent
Pick-X11 access if that happened, I think.  It could begin the make a
real difference in the market.

Quote:>isn't to me.  I bought it anyway.  It's great, but it hurt.

>Recently, I got some training with SB+ at work (by Kevin King--excellent
>class, BTW).  I don't get to actually *program* in it, mind, I just got
>*trained* in it.  I wan't to use *that* at home, too.  If I could use
>SB+ with my home PICK flavor (okay, for the curious, I settled on an NT
>version of D3 that I run on Win95--no complaints, yet), I'd have a pair
>of marketable applications (*I* think, who knows if there's a market for
>it, really).  I could program some stuff for various tangential hobbies
>that haven't been dreamed of, yet, by conventional development aids.  So
>what's it take for a single-user SB+ server?  Don't ask.  It's more
>expensive than the original D3 by a factor of ten.  There's no way I can

Yes.  And you don't need it.  What is it's greatest advantage over what
comes native on D3, in your opinion?  You've mentioned one disadvantage.
I'm also irritated by middleware that attempts to sell replacements for
functionality already in the DBMS, leading to untidy and over-complex
systems with supplanted and unused functionality. It has almost no
purpose but to seduce us into strategic dependence.  SB+ is nothing
without the DBMS but the reverse is not the case, yet it is marketed as
a key component to which the DBMS is a mere appendage.  Speaking as an
end user, not a VAR, of course.  There's something in it for the VARs,
but not, I think, for either the DBMS vendors or the customers.

How familiar are you with development on bare D3?  With the
functionality of the dictionaries, Basic, the Update Processor (at least
for prototyping), CALLX triggers, and pass-through over ODBC, and
retrieval and update locks (ever use them?) where is the factor-of-ten
margin of value in SB+?

I feel that the Update Processor, however much you may like or
dislike the thing itself, creates a standard or a model for database
design on D3.  You might well replace it by something with more
polish, but I would hesitate to embrace a substitute that breaks
the model.  That is a one-way ticket to the secondary dependence which
I mentioned above, and which my employer has experienced and as
far as I am concerned will not experience again.

Quote:>afford that.  I didn't bother asking what a runtime liscence for SB+
>would cost (if such a beast exists), I was afraid of what the answer
>might be.

>So what are the consequences, really?  Well, I'll never get to use the
>SB+ skills I acquired.  I'll never be the evangelist I was destined to
>be for SB+.  I'll not be able to create the applications that (well,

You're doing fairly well. <grin>

Quote:>IMO) would literally revolutionize certain extremely small, niche
>markets.  That's one fewer SB+ developer, three fewer applications to
>test the market's waters and who knows what else.  Perhaps it's because

Why fewer applications?

Quote:>I am one, but I've always thought that developers are key to the
>marketing strategy for vendors of computer tools.  If you really want

Heh.  See below.

Quote:>sales, you need to *aid* the people who are making sales possible.
>Maybe that's too simplistic.  I don't see what it couldn't work that
>way, though--it seems to be working just fine for other software
>development tools vendors.

You can see that we differ on SB+, but I'm with you on the general
point.  I'm reminded of the OS/2 2.0 launch, which I had high hopes
would destroy the Microsoft hegemony.  Then I found they wanted over
$1000 for CSet/2, the C compiler, when Microsoft C was being almost
given away.  Jerry Pournelle wrote in Byte on the exact point.  A key
disadvantage of OS/2 has been the relative lack of applications.  Go
figure.  Losers, losers.
 
 
 

mvDBMS issues

Post by Jacob Proffi » Wed, 04 Feb 1998 04:00:00


Some excellent points that I agree with.  Since you asked, though, I'll
answer this one point.



>>Recently, I got some training with SB+ at work (by Kevin King--excellent
>>class, BTW).  I don't get to actually *program* in it, mind, I just got
>>*trained* in it.  I wan't to use *that* at home, too.  If I could use
>>SB+ with my home PICK flavor (okay, for the curious, I settled on an NT
>>version of D3 that I run on Win95--no complaints, yet), I'd have a pair
>>of marketable applications (*I* think, who knows if there's a market for
>>it, really).  I could program some stuff for various tangential hobbies
>>that haven't been dreamed of, yet, by conventional development aids.  So
>>what's it take for a single-user SB+ server?  Don't ask.  It's more
>>expensive than the original D3 by a factor of ten.  There's no way I can

>Yes.  And you don't need it.  What is it's greatest advantage over what
>comes native on D3, in your opinion?  You've mentioned one disadvantage.
>I'm also irritated by middleware that attempts to sell replacements for
>functionality already in the DBMS, leading to untidy and over-complex
>systems with supplanted and unused functionality. It has almost no
>purpose but to seduce us into strategic dependence.  SB+ is nothing
>without the DBMS but the reverse is not the case, yet it is marketed as
>a key component to which the DBMS is a mere appendage.  Speaking as an
>end user, not a VAR, of course.  There's something in it for the VARs,
>but not, I think, for either the DBMS vendors or the customers.

>How familiar are you with development on bare D3?  With the
>functionality of the dictionaries, Basic, the Update Processor (at least
>for prototyping), CALLX triggers, and pass-through over ODBC, and
>retrieval and update locks (ever use them?) where is the factor-of-ten
>margin of value in SB+?

>I feel that the Update Processor, however much you may like or
>dislike the thing itself, creates a standard or a model for database
>design on D3.  You might well replace it by something with more
>polish, but I would hesitate to embrace a substitute that breaks
>the model.  That is a one-way ticket to the secondary dependence which
>I mentioned above, and which my employer has experienced and as
>far as I am concerned will not experience again.

Okay, my thoughts/feelings/experience between the Update processor and
SB+.  I tried the Update processor.  It's a beast.  A frustrating beast.
It's nice to edit dictionaries or raw data, but as a data entry tool, I
found it extremely frustrating.  I can't control user stops, screen
layout, automatic filiing or hidden Keys (indexes).  Well, I probably
could have done the control and filing and *maybe* key manipulation if I
had written a slew of routines and callX'd them into the various dict
items.  But at that point, you might as well design your own screens and
display anyway since you'd have to write about the same amount of code.
The real killer for Update, though, is that I would have had to train my
user (who is also my wife, BTW :) to use the editor controls.  Controls
I have a few years experience with and that she doesn't want to have to
master.

The thing SB+ gives me is a quick screen generator with user controls
and hooks for custom code at every significant process point.  Not just
for validation of data, but for screen control, inquiry processing, and
user maintenance.  Editor controls are intuitive and online help simple.
Windowing (a skill most people already understand) is simple and
intuitive.  Automatic lookup and selects are easily configurable and
tied to important points in any process.

The end result is that knowing the capabilities of SB+ and how easy it
would be to design data entry and lookup screens in it leave me
extremely dissatisfied while programming my own screens etc.  To me
screen control is the most tedious process of programming databases.
SB+ simplifies that most despicable part of the whole design process.
Update doesn't have that degree of control.  No screen painter, no
simple validation process (Using the dict item is fine, but there's no
easy way to access the dict item in question while designing the data
entry process), no automatic lookup, no tab stop field control.  To use
Update, you have to design the whole thing without any idea how it all
works together before you actually fire it up in edit mode.  i.e. it
isn't even a little bit graphical.

Not that I wish to defend SB+.  I mean, I'll never be able to use it.
It is just too expensive for a single non-business developer with a
dream and time, but no money--or at least, not *that* much.  If I *had*
the money, I'd probably actually spend it.  I think SB+ is probably
worth it when you take the advantages it gives in the development
process.  It would cut months off my development time.  Many months if
you consider that I'm developing in my own, limited, free time.  Update
just doesn't have the capabilities I need to create the end product I
desire so it doesn't even come into the equation . . .

Jacob

 
 
 

mvDBMS issues

Post by Bill H » Fri, 06 Feb 1998 04:00:00


Jacob:

You make a valid point regarding the Update Processor (AdvPicks screen
editor).

Hoping not to step on anyone's toes, the 'thing' isn't really meant to be
used as the primary data entry screen.  It can be used under some unusual
circumstances, but, you're right; it's too klunky to give to users.  Ok,
ok, some will argue with me.

Anyway, it's a really cool prototyping tool.  You can create and test a
database setup quickly and efficiently.  It probably tries way too hard to
provide the tools to make data input screens (and routines).  However, I
can usually work with its' limitations.

As far as data input screens are concerned, we all have to do something.  I
wish someone would come up with the perfect solution; VB, PowerBuilder,
HTML, whatever.  Hopefully, that solution would at least tie all mvDBMS
software to some larger GUI market (e.g. Windows/Internet vs
SB+/Wintegrate/WinLink).  I've often thought HTML would be a perfect fit
for the 'streaming' screen generation that exists in character-based mvDBMS
software.

FWIW, Bill



> Some excellent points that I agree with.  Since you asked, though, I'll
> answer this one point.



> >>Recently, I got some training with SB+ at work (by Kevin
King--excellent
> >>class, BTW).  I don't get to actually *program* in it, mind, I just got
> >>*trained* in it.  I wan't to use *that* at home, too.  If I could use
> >>SB+ with my home PICK flavor (okay, for the curious, I settled on an NT
> >>version of D3 that I run on Win95--no complaints, yet), I'd have a pair
> >>of marketable applications (*I* think, who knows if there's a market
for
> >>it, really).  I could program some stuff for various tangential hobbies
> >>that haven't been dreamed of, yet, by conventional development aids.
So
> >>what's it take for a single-user SB+ server?  Don't ask.  It's more
> >>expensive than the original D3 by a factor of ten.  There's no way I
can

> >Yes.  And you don't need it.  What is it's greatest advantage over what
> >comes native on D3, in your opinion?  You've mentioned one disadvantage.
> >I'm also irritated by middleware that attempts to sell replacements for
> >functionality already in the DBMS, leading to untidy and over-complex
> >systems with supplanted and unused functionality. It has almost no
> >purpose but to seduce us into strategic dependence.  SB+ is nothing
> >without the DBMS but the reverse is not the case, yet it is marketed as
> >a key component to which the DBMS is a mere appendage.  Speaking as an
> >end user, not a VAR, of course.  There's something in it for the VARs,
> >but not, I think, for either the DBMS vendors or the customers.

> >How familiar are you with development on bare D3?  With the
> >functionality of the dictionaries, Basic, the Update Processor (at least
> >for prototyping), CALLX triggers, and pass-through over ODBC, and
> >retrieval and update locks (ever use them?) where is the factor-of-ten
> >margin of value in SB+?

> >I feel that the Update Processor, however much you may like or
> >dislike the thing itself, creates a standard or a model for database
> >design on D3.  You might well replace it by something with more
> >polish, but I would hesitate to embrace a substitute that breaks
> >the model.  That is a one-way ticket to the secondary dependence which
> >I mentioned above, and which my employer has experienced and as
> >far as I am concerned will not experience again.

> Okay, my thoughts/feelings/experience between the Update processor and
> SB+.  I tried the Update processor.  It's a beast.  A frustrating beast.
> It's nice to edit dictionaries or raw data, but as a data entry tool, I
> found it extremely frustrating.  I can't control user stops, screen
> layout, automatic filiing or hidden Keys (indexes).  Well, I probably
> could have done the control and filing and *maybe* key manipulation if I
> had written a slew of routines and callX'd them into the various dict
> items.  But at that point, you might as well design your own screens and
> display anyway since you'd have to write about the same amount of code.
> The real killer for Update, though, is that I would have had to train my
> user (who is also my wife, BTW :) to use the editor controls.  Controls
> I have a few years experience with and that she doesn't want to have to
> master.

> The thing SB+ gives me is a quick screen generator with user controls
> and hooks for custom code at every significant process point.  Not just
> for validation of data, but for screen control, inquiry processing, and
> user maintenance.  Editor controls are intuitive and online help simple.
> Windowing (a skill most people already understand) is simple and
> intuitive.  Automatic lookup and selects are easily configurable and
> tied to important points in any process.

> The end result is that knowing the capabilities of SB+ and how easy it
> would be to design data entry and lookup screens in it leave me
> extremely dissatisfied while programming my own screens etc.  To me
> screen control is the most tedious process of programming databases.
> SB+ simplifies that most despicable part of the whole design process.
> Update doesn't have that degree of control.  No screen painter, no
> simple validation process (Using the dict item is fine, but there's no
> easy way to access the dict item in question while designing the data
> entry process), no automatic lookup, no tab stop field control.  To use
> Update, you have to design the whole thing without any idea how it all
> works together before you actually fire it up in edit mode.  i.e. it
> isn't even a little bit graphical.

> Not that I wish to defend SB+.  I mean, I'll never be able to use it.
> It is just too expensive for a single non-business developer with a
> dream and time, but no money--or at least, not *that* much.  If I *had*
> the money, I'd probably actually spend it.  I think SB+ is probably
> worth it when you take the advantages it gives in the development
> process.  It would cut months off my development time.  Many months if
> you consider that I'm developing in my own, limited, free time.  Update
> just doesn't have the capabilities I need to create the end product I
> desire so it doesn't even come into the equation . . .

> Jacob

 
 
 

mvDBMS issues

Post by Intelligent Informatio » Fri, 06 Feb 1998 04:00:00


Your comments re the Update Processor refer.

We have the PERFECT D3 GUI solution!

It is a RAD, a work- and taskflow manager, pipes directly to D3 from
NT/Windows/SCO/AIX etc (ie does not utilise ODBC to connect, although ODBC
connectivity is available for up- and downloading from open systems
compliant applications) and uses UP in green screen mode.

The approach is thin-client and the product is extremely memory-friendly
and has a smaal footprint.

In short, it encompasses what you refer to as SB+/Wintegrate/Winlink AND
DOES A WHOLE LOT MORE!!!


Schalk



Quote:> Jacob:

> You make a valid point regarding the Update Processor (AdvPicks screen
> editor).

> Hoping not to step on anyone's toes, the 'thing' isn't really meant to be
> used as the primary data entry screen.  It can be used under some unusual
> circumstances, but, you're right; it's too klunky to give to users.  Ok,
> ok, some will argue with me.

> Anyway, it's a really cool prototyping tool.  You can create and test a
> database setup quickly and efficiently.  It probably tries way too hard
to
> provide the tools to make data input screens (and routines).  However, I
> can usually work with its' limitations.

> As far as data input screens are concerned, we all have to do something.
I
> wish someone would come up with the perfect solution; VB, PowerBuilder,
> HTML, whatever.  Hopefully, that solution would at least tie all mvDBMS
> software to some larger GUI market (e.g. Windows/Internet vs
> SB+/Wintegrate/WinLink).  I've often thought HTML would be a perfect fit
> for the 'streaming' screen generation that exists in character-based
mvDBMS
> software.

> FWIW, Bill

 
 
 

mvDBMS issues

Post by Intelligent Informatio » Sat, 07 Feb 1998 04:00:00


My apologies, the Internet address supplied re our RAD toolset is

Schalk



Quote:> Jacob:

> As far as data input screens are concerned, we all have to do something.
I
> wish someone would come up with the perfect solution; VB, PowerBuilder,
> HTML, whatever.  Hopefully, that solution would at least tie all mvDBMS
> software to some larger GUI market (e.g. Windows/Internet vs
> SB+/Wintegrate/WinLink).  I've often thought HTML would be a perfect fit
> for the 'streaming' screen generation that exists in character-based
mvDBMS
> software.

> FWIW, Bill