×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Like Vern I have always felt that the fact that we can use RLA _and_ SQL
against our data is a major advantage that we should shout from the
rooftops. There are occasions when RLA is the right tool for the job but
the data also needs set
style access. Other systems force you to make a decision one way or the
other with resulting inefficiencies - we don't have to do that.
the problem with RLA or SQL is not performance, it's design.
Using SQL it's very easy to decouple the application from the database.
simply never use a table, only use views. RLA and DDS tend to navigate
through the data and grab the data together (I know, this could have been
done better, but most applications didn't). Following newer recommendations,
using SQL DDL instead of DDS - and to use some newer features, you are
forced to do so, the situation is getting worse. Views can't be accessed by
RLA and indexes are limited with their definitions.. Instead triggers, for
instance are a great enhancement, enabling making read only views updatable,
but no way with RLA. And worse of all, as long as you have RLA access to
your data, you are very restricted to refatoring of your database design.
My recommendation is: first change your access method from RLA to SQL - it's
rather easy. if you introduce a functional data access layer. Then you have
all prerequisites to switch your data definition from DDS to SQL DDL and
redesign your database, without any harm fro your applications.
D*B
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.