| >However, updating the Oracle database from the VAX appears to be a more costly
>undertaking. As I understand it, they have the option of buying a gateway
>from Oracle and probably some precompiler to allow a VMS application to access
>the Oracle database on the Sun via TCP/IP.
>
>Do they need the Oracle database on the VAX or can the gateway function
>without it?
>
>How about writing some task-to-task code using RPC technology? Is this
>feasible?
If the VAX application that updates the Oracle DB is 'stable' - that is it does
not issue free-format queries, but all the queries are well known in advance,
then I personally would favor writing an RPC-based application. Something that
would allow VAX applications to issue requests for fixed queries (identified
by some number), with the server end on the Sun executing the corresponding SQL
verbs. The actual queries would then be embedded on the Sun.
This can even lead to a more portable solution in the oong run. If the protocol
and the client/server functions aee well architected, you should be able to use
them to access other databases.
This is just my opinion. You would need to cost that and compare it with a
tools-based solution (I am sure Oracle can provide one).
On re-reading what I just wrote, this is exactly what SQL-Access tries to
achieve. Check the BROKE::SQL_ACCESS conference for info and persons to
contact.
/albert
|
| I think that what you'd really like to do here is integrate the
Rdb/VMS applications with the ORACLE/Sun applications, and not
necessarily simply access the database. I'd suggest that you
take a look at ACA Services and try to integrate the applications.
When the VMS application needs to access information for the Sun
system, ACA Services can invoke the Sun application. For more
information about ACA Services, check out the VIA::ACA_SERVICES
notes conference, or contact John (MRKTNG::) Clancy or Linda
(IDE::) Storm.
ACA Services is a phenominal integration tool. If you don't know
about it, you're definitely missing out.
|