This innovation that enables customers to achieve seamless integration with
foreign databases is the jEDI.
This published interface provides a common set of
rules and syntax to access any database or other data source. By means of
specific jEDI drivers, jBASE BASIC I/O statements can access other databases,
such as Oracle, SQL Server and DB2, as simply as they can jBASE databases. And
for databases with embedded SQL pre-compilers, jBASE supports ESQL within the
BASIC language.
The jEDI system provides a number of very useful generic facilities to the
application developer, such as transaction boundary support across multiple
databases and secondary indexing. The Transaction Journaling product uses the
jEDI interface to log transactions to just about any device for any and all data
sources.
The jEDI architecture is ideal for sites that require their investment in
their BASIC application be maintained while being able to work with DB2, Oracle
or other RDBMS. The jEDI, in effect, separates the BASIC application from the
data source. The interface provides a consistent view of all I/O to the calling
program and to the rest of the system. The jEDI then accesses the various data
source drivers. jBASE comes with internal drivers for its own file system as
well as for the operating systems' files and directories. For other data
sources, customized drivers must be built. For jEDI drivers for specific
relational databases, jBASE software offers the jEDI Development Kit.
New! FAQ about jEDI
Q When do I use jEDI versus jBCDC?
A These are two different problems that we are trying
to solve with these two products which correspond to the two reasons that people
want to interoperate with a SQL database.
1) They want to run their existing MV Basic application on a new SQL
database. This means that they already have an application with a data access
strategy in place and it is the MV paradigm. The jEDI is a way of accessing the
SQL database that is native to the MV application i.e. using the MV paradigm.
The important thing is that in this case, they do not want to change their
application, so they stay with the thing that maintains the paradigm - the jEDI.
This allows us to say that their jBASE Basic application runs on SQL Server,
Oracle, etc. with no changes.
2) They have an existing SQL database that they want to communicate
with. For example, there might be a local authority that runs a jBASE
application and they want to interface with (not run on) a Geographical
Information System that uses SQL Server. So they have a non MV
application/database that they want to access. Because that SQL database uses
the SQL paradigm, this time they would use jBCDC – but remember that will
require changes to their Basic application.
So - the jEDI allows people to access SQL databases with NO CHANGES to their
database access paradigm (they will continue to use MV access methods); whereas
the jBCDC method necessitates the user changing their database access paradigm
and therefore will require new development within the application.
Now of course, there are times when it will not be so black and white. For
example, they have converted their application (as in 1 above) and they want to
do some new stuff with it and think that the SQL way of doing it is more in line
with their requirements- so jBCDC would be the way to go.
More to follow!
