Conference ulysse::rdb_vms_competition

    Hmmmm ... RTI did a presentation at the DECtp seminar in Santa Clara a
    year ago.  The person from RTI who wrote the gateway to Rdb was there
    and told us specifically that she uses DSRI calls.  Now, she didn't
    differ between ddl and dml actions so I don't know if they are doing
    part dynamic sql and part DSRI. It's certainly a good question. 

    The fact that Digital recommends dynamic SQL may be words from 
    Ingres in order to move the heat away from their tails.  I'd be
    very surprised if we recommended dynamic SQL over DSRI.  Maybe the
    database systems people can comment.    

    Many tool vendors do in fact use dynamic SQL since they can get
    to market quicker and port much more easily to other SQL databases.
    In fact, I believe the Trifox Oracle to Rdb tools use dynamic SQL
    as well so we need to be careful with any and all 4GLs.
    
    It's a shame customers don't think about this when they make a decision
    on a development strategy.  Call me old fashioned, but for bread
    and butter applications where performance is required, I'll take
    pre-compiled programs every time.
    
    Now you know why Oracle SQL*forms is such a pig .... SQL parsing
    is a killer for them.  In fact, SQL parsing is so bad and their
    pre compilers are so poor, they invented PL/SQL to avoid this
    terrible bottleneck.
    
    I almost never recommend a 4GL that uses dynamic SQL for the reasons
    you are are listing.  That's why Focus and SmartStar are excellent
    choices since they do, in fact, use DSRI calls.
    

First, the V5.* versions of INGRES TOOLS use DSRI, the V6.* versions use Dynamic
SQL.  Independent tests of using DSRI versus Dynamic indicates only about
a 20% difference in performance should be seen.

THERE IS NOTHING WRONG WITH DYNAMIC SQL ACCESS, YOU ARE PLACING THE BLAME
IN THE WRONG PLACE.

I have no idea exactly how the INGRES TOOLS work, so I'll answer the questions
a little generically.

The way the INGRES V5 gateways worked is that they were passed something
internal to INGRES or perhaps it was SQL, which then converted it to DSRI.
For V6, RTI realized that there was no reason for them to convert SQL to
DSRI since we (and every other vendor) already did it!  So, their entire
bridge architecture was changed to pass SQL directly to the underlying
database system.  Basically, there is no difference EXCEPT that their own
DSRI bridge was poorly designed and basically sucked LOTS of data out of Rdb
and then performed the processing inside INGRES code.  WIth the V6 design
they pass the query through to Rdb and should get much better performance.

Now, I've already said DYNAMIC SQL is not the problem.  The likely problem
is the misuse of DYNAMIC SQL and/or Rdb/VMS.  If they really re-bind to the
database between forms, then this is an INGRES TOOLS design flaw.  If they
really re-load metadata from Rdb/VMS between forms, then this is an INGRES TOOLS
design flaw.  Besides those two, they have a flaw which I know about.  In
INGRES (the database engine) a DYNAMIC SQL PREPARE of a SQL statement only
lasts for the life of that transaction.  They have to keep re-preparing it
transaction after transaction.  The query compilation process is expensive for
any database system, so this is not good.  VAX SQL and Rdb/VMS DO NOT REQUIRE
THE QUERY TO BE re-PREPARED between transactions.  Since INGRES doesn't have
this benefit, I suspect that INGRES TOOLS does not use it.  In other words,
they are incurring a MAJOR performance hit that Rdb/VMS is specifically
designed to avoid, but they are circumventing Rdb/VMS' capabilities.

Our own documentation on the performance of DYNAMIC SQL is ERRONEOUS.  It
was written when the documentation people did not understand the situation and
believed that DYNAMIC SQL operation was identical to CALLABLE RDO.  Somehow
the warning survived multiple reviews.  The proper warning is that
DYNAMIC should not be used where EMBEDDED or MODULE language will suffice.
They will nearly always perform better.  However, this option is rarely
available to 4GL or ad-hoc query products.

As long as INGRES TOOLS uses a bridge approach to access Rdb/VMS, they are
not likely to make the best use of our database system.  Some of their
competitors in the tools arena have an advantage in this regard.

Thanks for the explanation. It becomes a little rough out here in the
    field when Digital's manuals specify that the DYNAMIC SQL interface
    is not that good of a performer. Software specialists in the field
    have  been waiting a long time for the "desktop integration"
    of Rdb/VMS. We have been talking about SQL services for almost 2
    years, yet we do not have any major PC tools that can be integrated
    with Rdb/VMS. We at Digital forget that most of the business world
    use PCs. We can not afford to ignore the desktop anymore. We keep
    leaving the desktop integration up to 3rd party vendors, who do
    not have Digital at the top of their priority list or do not understand
    the "Digital Style of Computing". 
    
    There are many examples of ignoring the desktop. The recent decision
    to allow 3rd parties to build the "FIMS" forms product for the desktop.
    Why doesn't Digital want DECForms on that platform? I don't hear
    other vendor's talking about a FIMS based product...is this
    only important to DEC? I believe DECForms is a great product. Unles
    Digital makes it available on the PC/workstation in the near future
    we will continue to loose major business opportunities to ORACLE,
    INGRES, etc. 
    
    Other examples...RALLY, but we won't go into that; PC front ends
    for ACMS... The bottom line is that it is not acceptable to our customers
    to run their PCs in terminal emmulation mode. They want and require
    software that runs on the desktop and co-operates with applications
    on the multi-user servers.
    
    It is frustrating when vendors that Digital have a relationship
    with put all the blame on Digital and then offer to fix it by replacing
    the product you spent 5 months selling. It is fortunate that my
    customer is more educated than most and realizes Rdb/VMS is much
    more strategic to him than Ingres Tools.
    
    Ken McMullen
    
    (I hope this means Ultrix/SQL/SQL-service interface to Rdb, will
    not run at the same speed as its ancestor)

    Ken makes a very good point.  We keep talking about "integrating
    the enterprise."  Our customers have lots of PCs and, I think, are
    beginning to understand that we truly can integrate their PCs into
    their enterprise AT THE HARDWARE AND SYSTEM SOFTWARE LEVEL.  We
    are put in a very difficult position when it comes to applications
    from the PCs accessing our VAXes.
    
    I'm having to do a dance for at least two customers right now. 
    We're selling them PCSA with ALL-IN-1 Phase II and they're a little
    miffed that they can't use the PCs to acces the Rdb database with
    one of our products, as well.
    
    I'm a little uncomfortable, to say the least, telling them "We can
    connect your PCs into the network and enterprise-wide e-mail.  We
    can give them virtual disk space on the VAX.  But, if you want to
    use the PC for a front-end application client for a VAX/VMS with Rdb
    server, forget about all the LOTUS, R:base, dBASE, etc. tools your
    users already are familiar and comfortable with on
    the PC, you have to code 3GL applications with calls to SQL/Services
    or (if you insist on the ease of application development that a
    4GL provides) use Ingres Tools for Rdb (but please don't look *too* 
    closely at their database engine or those FUD-ful adds in Digital
    Review - they're meant for ORACLE not us)..."

    re: .0, .2
    
	"...THERE IS NOTHING WRONG WITH DYNAMIC SQL ACCESS..."
    Correct.  Right.  Truth.  Fact.  Reality.  Get the picture?
    
    "Our own documentation on the performance of DYNAMIC SQL is ERRONEOUS.  It
was written when the documentation people did not understand the situation and
believed that DYNAMIC SQL operation was identical to CALLABLE RDO.  Somehow
the warning survived multiple reviews.  The proper warning is that
DYNAMIC should not be used where EMBEDDED or MODULE language will suffice."
    
    The documentation will be modified in the next release after V3.1 to
    avoid this overblown warning.  The original intent was to warn naive
    users that Dynamic SQL might not be as fast as the equivalent
    Embedded/Module Language where there are no dynamic requirements... the
    tradeoff made for dynamic flexibility was additional runtime thinking
    on the part of the DB.  The warning, obviously, overstates the
    negative, and never mentions the positive.  We've paid for this botched
    attempt to set reasonable expectations time and time again...
    
    S
    

    
    The story I have is:
    
    In this case, the implementer made a basic mistake of using the
    "execute immediate" command, which forced a compile of each statement
    befor executing. Since that statement apparently was used after each
    query and/or update, the system would have spent inordinate resources
    and time compiling all the queries. Performance would equate to
    callable RDO levels.
    
    My guess would be that someone had an inadequate knowledge of the
    tools.
    
    ---- Michael Booth
    
    This one doesn't look like the fault of Dynamic SQL or Ingres Tools.

re: -.1
    
>>>    This one doesn't look like the fault of Dynamic SQL or Ingres Tools.

I shared some of the info in this note with a customer of mine who has the 
Ingres Tools for Rdb and he echoed Michael's sentiments above.

He said that the excessive amount of time it takes to put up screen can 
also be caused by a "LOOKUP" function (or something like that) which causes the
necessary info to be retrieved from the database and put into memory before 
the screen is actually displayed (obviously I got a less than exact 
explanation of this :-( ).

Also, my customer said that you need to be careful about whether the tools 
uses the "LIKE" or "EQUALS" clause when it builds its queries.  You think 
it's using "equals" and it may not be!

If you'd like a better explanation, my customer seemed eager to share his 
new-found knowledge of the Ingres Tools idiosyncracies with anyone who wants 
to call him:

	Mark Cecchetti  (pronounced Checketty)
	GE Transportation Systems
	(814) 875-5696

Good luck,

Rick C

    Thanks for all the replies. I am going into the customer's tomorrow
    to look at the database.
    
    I have also confirmed that the dynamic SQL interface is not the
    problem. I talked to a software specialist who's customer is using
    the dynamic SQL interface from PC's. They do not have a performance
    issue. Glad to hear the documentation is being changed.
    
    I will let everyone know what happens. I do recommend not to use
    Ingres unless it is the only way.
    
    

>    I'm a little uncomfortable, to say the least, telling them "We can
>    connect your PCs into the network and enterprise-wide e-mail.  We
>    can give them virtual disk space on the VAX.  But, if you want to
>    use the PC for a front-end application client for a VAX/VMS with Rdb
>    server, forget about all the LOTUS, R:base, dBASE, etc. tools your
>    users already are familiar and comfortable with on
>    the PC, you have to code 3GL applications with calls to SQL/Services
>    or (if you insist on the ease of application development that a
>    4GL provides) use Ingres Tools for Rdb (but please don't look *too* 
>    closely at their database engine or those FUD-ful adds in Digital
>    Review - they're meant for ORACLE not us)..."

I don't understand this paragraph at all.  LOTUS and dBASE have announced
future support for Rdb/VMS access through SQL SERVICES, and numerous
other people are working on it (see previous pointer to Ken Morse for
information).  Several 3rd party products already are available that provide
4GLs on PCs accessing Rdb/VMS.  Certainly they aren't all perfect in their
current implementation, but they exist and work.

Granted such futures and 3rd party products are more  difficult to sell
than a simple "we have it all, and we have it all now" message.  But if
the offering were perfect we wouldn't need to sell it, it would sell
itself. (Only kidding).

�>    server, forget about all the LOTUS, R:base, dBASE, etc. tools your

    Maybe I was flaming a little, but it IS difficult to sell on promises
    especially to a new customer, a little anxious about porting/converting
    thousands of lines of code and hundreds of users to a new environment.
    
    And, while I know dBASE is the most popular PC database, what my
    customers are using is LOTUS (not a database? It sure is popular).
    I, too, have heard that LOTUS and dBASE are going to provide "future"
    support for SQL SERVICES.  
    
    Those data might be handy in PID-form.  I'll talk to Ken Morse.
    I'll just be more patient, I guess :-)
    
    B

    I too have been selling to customers the promise of 3rd Party end user
    tools running on PCs and accessing data in an Rdb databse (for over a
    year now).  This is an area that is of very high interest with almost
    every single customer that is interested in Rdb and it helps to diffuse
    the "ORACLE runs on a PC" arguments. 
    
    Unfortunately LOTUS and DBASE IV integrating Rdb data through SQL
    Services does not necessarily mean from a PC.  In fact my understanding
    is that these products are integrating using SQL Services for their
    VMS-based products not their PC-based products.  This makes sense with
    their push to run on additional platforms in order to increase their
    market.   This would have a greater impact on their growth than adding
    functionality to an existing product that already dominates the PC
    platform.
    
    The good news is that there are individuals who have taken the
    initiative to fix the problem in the nearer term rather than waiting
    for the third party to get around to doing the work.  See the Lotus
    notes file for more information on these efforts.  
    
    We are not flaming in the field because we love PCs.  We see situations
    where customers cannot wait for a product that may exist at some point
    in time based on development priorities and schedules of third-party
    vendors.  We work very hard to sell the best database on the VAX
    platform and we are frustrated when we lose to "inferior" database
    products because of a few holes that still must be filled.
    
    Steve Farlow @STO    

    I agree with the last two entries. In some geographies/companies
    you can not use an unknown PC tool vendor. Digital and partners
    program annouced in 1988 some very strategic PC products that
    will be supporting Rdb. What happened to them? Can someone give
    us an update on schedules, engineering efforts, what exactly will
    be shipping. 
    
    I have heard that LOTUS on VMS (and Rdb support) will be available
    shortly and that PC-LOTUS with an Rdb interface will be a few months
    behind. I have also heard that Ashton-Tate have not even started
    the interface between Dbase IV and Rdb (and different Digital marketing
    groups keep passing the product and the funding requirements around). 
    Can someone clear up all the confusion?
    
    By the way about the orignal note...it appears that Ingres may have
    a problem in their tools. At least they phoned the customer last
    week and admitted it was not Dynamic SQL. We went in and proved
    that at the customer sight. YES it does work! It has a VERY SMALL
    performance degradation, nothing to worry about.
    
    I will keep everyone posted on what happens. There is some discussion
    on this topic in the RDB notesfile and the INGRES_TOOLS_FOR_RDB
    (BANZAI) notesfile.
    
    I hope Digital and Ingres clear up the problem. I don't mind making
    an Ingres sales rep rich, if it helps us. 

    
    If there's a proven method for working with Ingres, I'd like to
    know about it.  We're "this close" to closing an $8 million deal,
    if we can show the customer a 4GL on the PC.  Ingres tools is it,
    but Ingres is already in there selling their db on the VAX.
    
    I need their tools but not their db, if you get my drift.
    
    Re: FOCUS;  Gerry, I talked to an IBI sales support guy on Friday
    and he said FOCUS on the PC can not talk to Rdb on a VAX... (?)
    Nor can PowerHouse.
    
    Bruce

    Nor can any other reputable/well known PC tools vendor (today).
    
    Ken

    Re: .12

> I have heard that Ashton-Tate have not even started the interface
> between Dbase IV and RDB (and different Digital marketing groups keep
> passing the product and the funding requirements around). Can someone
> clear up all the confusion.
    
    Ken, I was after the DBIV/RDB link for the PC for a client about
    a year ago. The last I heard from Joe Tomas, the DEC Business Manager,
    was there were significant engineering problems in the implementation.
    
    About the same time, they started field test ob DBaseIV/VMS. Now,
    that was about 10 months ago and we still haven't seen a product
    annoucement.
    
    We are trying to close ESSO Resources on using RDB as the strategic
    DB for their division. One major stumbling block is that everyone
    has a PC on their desk, and quess what? They want co-operative
    processing for end-user reporting and computing. While they are
    receptive to a mixture of VMS and MS-DOS based tools, they prefer
    the later.
    
    I've placed a note in the SQL-SERVICES notes conference (NOVA::)
    because the issue has been raised their and non-answered numerous
    times.
    
    I also pulled the list of NAS ISV's from the VTX BOSS database and
    guess what, hardly anyone listed support SQL Services. Also interesting
    was that Ashton-Tate and LOTUS were listed only for VMS based products,
    not MS-DOS. The will use SQL Services, but it will be for VMS and
    not MS-DOS.
    
    With Ashton-Tates and LOTUS's involement with the SYBASE server,
    it may be awhile before we see an RDB link.
    
    Paul

The continuing saga....My customer has contacted the project leader and chief 
software wizard for the Ingres tools for Rdb (alias gateway engineering group).
Lots of interesting tid bits.

Guess what...it is not the EXECUTE IMMEDIATE. My customer tested with and 
without that switch. No real difference (as suspected transaction 
parsing would not take 40 seconds).

Some interesting points, Ingres tools don't really have 
the concept of SET TRANSACTION, the forms are always READ-WRITE 
transactons. To force the concept of a READ-ONLY transaction you must 
use the EXECUTE IMMEDIATE which means the apps must always go through 
the overhead of re-interpreting the database transaction, whether or not 
it needs to be done.


The Ingres Tools do not work with Rdb 3.1, no matter what your local 
Ingres support office says. Ingres egineering confirmed this fact.

My customer is convinced Ingres did not really test ABF or QBF with Rdb. 
It appears the tools are reading all of Rdb's system tables sequentially 
over and over (this sounds like SYSTEM 1032 from a few years ago). There 
is no way they would have released the tools if they had done any 
testings.

Testing you say, my customer asked them if they had turned on the 
RDMS$DEBUG_FLAGS. Ingres engineering said "What are they?". What is our 
level of support for CMPs? Do we do any quality control on CMP products.

By the way the Ingres report writer does not appear to have the same 
problems that ABF and QBF have with Rdb.



signed....one disillusioned field specialist living with the realities 
of customer satisfaction. I could use some help.


Ken M.

    This news doesn't make my situation any easier, either!  
    
    We're about to try to figure out a way to tell the customer that Ingres
    Tools for Rdb are ok.  But now I don't think I want to do it.  Come to
    think of it, this would be a great way for Ingres to steal the database
    business from us on VAXes. 
    
    Imagine, if you will, a customer who has the best computer in the world
    (a VAX), and the best relational database management system for that
    computer (Rdb), and has chosen Ingres Tools for Rdb.   Imagine further,
    that the applications written with those tools are not performing up to
    expectations.
    
    Customer asks Ingres, "Why don't these applications perform perform the
    way you said they would?"
    
    Ingres replies, "Hmm... It must be something wrong with Rdb, because the 
    applications we develop with them on *our* database always seem to 
    perform pretty well.  Wouldn't you like to try it out?"  
    
    You know the rest of the story...
    
    So, one might counsel a proposing sales team to tell the customer, "Don't
    use the Ingres Tools."  One might even suggest telling the customer 
    about Borland Software's just announced support for SQL/Services from
    applications written with PARADOX on MS-DOS.
    
    Check this interesting twist:  The Sales Unit
    Manager on my account told me to "stop telling the customer that Rdb is
    the best database for the VAX!"(!)  She said "If we have to we'll let
    them buy the Ingres database with our hardware and talk them into Rdb
    later."  She doesn't realize they *like* Rdb and that it's Ingres Tools
    they're wanting.
    
    -b

    I'm working an opportunity where the customer has narrowed his
    environment choices to:
    
      1. SQL*everyting/Oracle database
      2. Ingres Tools/Rdb
      3. Focu/Rdb
    
    Oracle is in the account right now holding their hands and walking them
    through a sample development cycle.  The customer is meeting with Focus
    next week to start the same sequence.  The Ingres story is an
    interesting one.  
    
    When the customer asked Ingres to bring in a person for a week to
    perform the same development cycle, the balked when they heard they
    were to use Rdb and NOT the Ingres engine.  They told the customer that
    they weren't sure they would be willing to expend that amount of
    manpower for "just the tools".  Ingres had another meeting with the
    customer yesterday and I'll be able to report the outcome next week.
    
    This incident does support my theory that they are quite interested in
    selling their database.  Now, in this case (no pun intended), I did not
    bring them to the account.  The customer found Ingres on his own. So I
    guess I can't be too hard on the Ingres folks.
    
    -- gerry
    
    BTW.  The Focus rep told me that whenever he and Oracle end up in the
    same account, Oracle backs off their tools and supports Focus as the
    development environment with Oracle as the database.  Pretty
    interesting stuff.

<<< Ingres replies, "Hmm... It must be something wrong with Rdb, because the 
<<<    applications we develop with them on *our* database always seem to 
<<<    perform pretty well.  Wouldn't you like to try it out?"  
    
<<<    You know the rest of the story...


NO, I DO NOT KNOW THE REST OF THE STORY. In fact, I have yet to hear any of the
story.  All I hear are insinuations.  We have ASKED over and over and over and 
over and over and over and over and over ... (i hope you get the point) that
if you can get the name of the INGRES person, the customer name and date that
it happened, we will confront INGRES with this as being in conflict with our
contract.  Once we did take an undocumented case to them, and guess what?
We got our A** taken to the cleaners.  In FACT, this is not what had happened.

What happens is that PARANOIA strikes into the heart of each specialist
(including myself) about all the bads things that INGRES is going to do if
we let them in the doors.  If they are in the doors, we are PARANOID about
them taking our database out, so we make up stories about those bad-people at
INGRES to share in notes conferences.

SO, IF you are willing to document this situations, we are willing to discuss
them with INGRES.  IF YOU ARE NOT, then cut the CRAP!



Chuck -- who really doesn't care too much for the INGRES Tools

<<< Testing you say, my customer asked them if they had turned on the 
<<< RDMS$DEBUG_FLAGS. Ingres engineering said "What are they?".

Thank you for this information.  My guess is that the developers do know what
they are (since I have been asked questions about their output), but this
person probably does not.


<<<  What is our 
<<< level of support for CMPs? Do we do any quality control on CMP products.

INGRES Tools for Rdb is the product Digital Sells.  This is a DDS agreement, not
a CMP agreement.  No there is not quality control on CMP products.  However,
there is an acceptance test run by Digital for DDS agreements (like Ingres 
Tools for Rdb).  However, according to the contract, we have x days to test.
If INGRES does not hear by that date, it is considered accepted.  Well, we
did not respond (resource issues) within the time frame, therefore they were
by default, accepted.  In terms of Support, they are a RSVP participant, and
we answer their faxes like any one else.  There have not been a great deal
of them from INGRES.

    Chuck, you can talk to the customer, I know who from Ingres, but I
    don't know the exact date. This problem is compounded in Canada, due
    to the lack of any formal agreement.
    
    If the tools work, Ingres wouldn't be able to propose switching
    databases. I would make my local Ingres reps rich if the tools
    implementation were better. Beating Ingres at the database level
    is not that hard...Rdb should always win.
                
    So, where do we go from here? My customer is not happy (except with
    Rdb), he spent a lot of money on tools that don't perform, the
    customer's local Digital office is having difficulty getting any
    useful information, the customer is re-writing the application in
    Basic and SMG (ugh...won't even buy DECforms....it's called really
    pissed off).
    
    By the way Ingres engineering has asked for one week from the customer
    (ie no phone calls). They say they are working hard on the problems.
    
    Ken McMullen

    The thing that makes this more complicated and my *hypothetical*,
    thus the word "imagine" twice in my last reply (#17), situation
    more troublesome, and less cause for concern that Ingres is breaking
    any rules is...
    
    The customer invited Ingres in, and we had nothing to do with it.
    When I first mentioned Ingres Tools for Rdb, the customer replied,
    "Oh yes, we like their tools and their database."  So I ran like
    the dickens away from the Tools - call me "PARANOID," call me a
    chicken, call me anything but late for dinner...
    
    IMHO, the customer likes VAX/VMS with Rdb/VMS and will choose
    Ingres Tools for Rdb because it runs on the PC.  I guess I hadn't
    made that perfectly clear.
    
    I'M FRUSTRATED, OKAY?  I understand that we all are, that's why
    they call it work.  

    I meant not to cast dispersions.
    
    -b

    Two items.....
    
    A customer of mine at a *major* government laboratory associated with
    the University of California....is very interested in Rdb because of
    lowered license charges..  He is a big ingres user and their costs aree
    killing him...and they don't appear to be very ready to negotiate for a
    price break...
    
    and ...I received a call from the local ingres sales office asking for
    Rdb literature.  Apparently, when they are competing against Oracle
    now, and price is the issue, they just layer on top of Rdb and charge
    for just tools...
    
    I'll call him back and inquire as to whether they run on top of
    3.1....(or at least if he thinks they do...
    
    Gil
    

    Gil,
    
    The tools will work with 3.1 soon, they just don't today. The local
    Ingres offices are like most sales environments...you mean the
    20 related products might not work if I change one of them, Why's
    that!?
    
    I wouldn't worry about which version of Rdb they work with, I would
    really be concerned about performance.

    They work.  They require a patch or two from Ingres.  They can still be
    slow if the app is designed badly (and sometimes no matter what you
    do).
    
    Contact Don Plummer @ Ingres 617/272-5060.  
    
    Jim