Conrad,

Thanks for the additional information.

Speedware Corp. has been very helpful in advising us on how to accomplish
our objectives.

Although there are some programming issues to work in moving the Image data
to Oracle, and accessing it via SQLNET, it's not as difficult as you have
stated.

1) We don't have to move all the data, or even a whole database at one time,
so the coding impact can be spread out.

2) Speedware's ALIAS parameters for base, file, element, and index
definitions can largely overcome the difference in naming syntax. (BTW
Speedware does fully support Oracle RDBMS) Further, Speedware applications
can access datasets from multiple DBMS and RDBMS in the same program unit.

3) It is true that program architecture designed for Image might not work
well (or at all) for RDBMS; especially where TPI on Image (such as Omnidex)
was used.  This can be mitigated somewhat by how the RDBMS database is
structured, but some re-coding will be required.  Fortunately, Speedware
allows us to greatly simplify data access logic when using Oracle, compared
to Image.  With Image, a screen program, for example, can only define one
dataset as the primary file, so a screen manipulating multiple datasets must
use a lot of local variables and hard-coded dataset references.  With
Oracle, those screen programs can operate on a "view" as the primary file.
A view is like a pre-defined join or cursor - multiple sets and their
relationships are defined, and Speedware lets us program as if they are a
single dataset entry.  So, when modifying our programs, we can remove a lot
of code.

Speedware has provided a good document on converting to RDBMS, but we'll
definitely pay close attention to the Axiant Migration Planning Guide - it
looks like a great document. Further, we'll be sure to look at Cognos and
Axiant tools when selecting other development tools.

Thanks for the heads-up.

-dtd

> -----Original Message-----
> From: Conrad Whittall [mailto:[log in to unmask]]
> Sent: Tuesday, November 28, 2000 11:52 AM
> To: [log in to unmask]
> Subject: Re: Speedware 3000 to remote Oracle
>
>
> On Wed, 22 Nov 2000 08:56:00 -0700, Dave Darnell
> <[log in to unmask]> wrote:
>
> >Dear Speedware experts:
> >
> >I have a customer who is interested in moving TurboImage data under
> >Speedware (7.04.02) to Oracle databases on Solaris or NT,
> but retaining the
> >Speedware apps on the 3K until the resources to migrate them become
> >unavailable.
> >
> >Undoubtedly, many will ask "Why?"
> >
> >They have maybe 8 Gig in the TurboImage databases, but only
> see about 80
> >concurrent users.  Their processors are modern, but their
> disc drives are a
> >little older and are starting to fail.  Budgeteers will not
> pay for upgrade
> >to RAID technology, and the users have a cost of ownership
> concern.  They
> >are in "lean times" and don't have the resources to convert
> the applications
> >at this time.
> >
> >On the other hand, they have a site license for Oracle DB,
> and plenty of
> >new, high-availability real-estate on Solaris and NT boxes.
> >
> >Now, the Speedware support team is looking to see if there
> is an Oracle
> >client that will run on the HP3000 - that would be one
> solution.  Speedware
> >does not support ODBC.  I asked him about SyBase under
> Speedware, but he
> >hasn't had time to answer back yet.
> >
> >This list always comes up with very innovative solutions,
> and sage advise,
> >what are your comments?
> >
> >-Dave
>
> Dave,
>
> Regardless of the development tool being used there is
> probably no easy way
> to move data from TurboIMAGE to Oracle (or any relational
> DBMS) without also
> having to make significant changes to the application code --
> even with
> Oracle's SQL*Net on the 3000 proving access to remote Oracle
> databases.
>
> This is simply down to the differences between TurboIMAGE and
> relational
> databases. For example, relational naming conventions will
> probably be the
> first major issue that will need to be dealt with. While
> TurboIMAGE allows
> dashes in dataset and item names, relational databases do
> not. So the first
> step might be to replace all dashes in dataset and data item
> names with
> underscores for the equivelent relational table and column
> names. Of course,
> this isn't just something that needs to be done in the
> database schema - it
> needs to be done throughout the application (unless you have
> some middleware
> that can do dynamic name translation for you, probably at the
> expense of
> runtime performance).
>
> As a further example, consider that the original developer of the
> application probably made many assumtions about the way in
> which TurboIMAGE
> will store and return data to the application. For example,
> the developer
> might be relying on sorted DETAIL chains to return data to
> the user's screen
> in a particular order. Even if the syntax of the development
> tool being used
> makes the change in the underlying data storage transparent
> (as PowerHouse
> 4GL does), a relational database will not return data in a
> particular order
> unless specifically asked to do so - using an ORDERBY clause
> on the SQL
> SELECT statement (either coded by the designer or generated by the
> development tool based on a designer specification).
>
> These are just a few examples of the many issues that must be
> addressed in
> moving an application from non-relational to relational data storage,
> regardless of the development tools being used.
>
> Although it cannot help with Speedware applications, Axiant 4GL from
> Cognos provides both advice and automation assistance to
> those looking to
> migrate their PowerHouse applications to new environments. The Axiant
> Migration Planning Guide (to be found on the Cognos Web site at
> http://www.cognos.com/products/axiant/guide.html) provides
> more detailed
> information on many of the issues that are likely to be
> encountered in any
> migration, regardless of the development tools being used.
> Specifically, the
> section entitled "Moving Forward With Axiant 4GL" starts with
> a discussion
> of many of the issues to be faced in moving from indexed
> (non-relational) to
> relational data storage. I'm sure that you will find this
> discussion useful,
> even if the application is written in Speedware (or any other
> language).
>
> Best regards,
> Conrad
>
> Conrad Whittall
> Marketing Manager, Application Development Tools, Cognos Inc.
>