Re: Why there is no controlfile in Informix like Oracle ?
Posted in 2004
Topics: Installation, Setup & Upgrades, Stored Procedures & SPL, Connectivity: ESQL/C, 4GL & Embedded SQL
Also sprach Jesus Antonio Santos Giraldo <jeansagi@myrealbox.com> : :I like Informix a lot... at the engine level... but at the tool level :informix really sucks (sorry). Have to agree with this sentiment. After having had the chance to use PL/SQL for a few projects, I now have to wonder why Informix never provided similar capabilities. As SPL is already part of the engine, it seems to be a *relatively* easy task (i.e. making all of SPL available for ad hoc queries). There is just a ton of stuff you can do in Oracle with just sqlplus running pl/sql scripts. To do anything comparable with Informix, I gotta pull out ESQL/C, perl/DBI, etc. Certainly doable, but requires the installation of additional tools, which is not always an option. plink, plink. Dave
On Mon, 30 Aug 2004 21:32:25 -0400, Dave wrote:
> Also sprach Jesus Antonio Santos Giraldo <jeansagi@myrealbox.com> :
>
>
> :I like Informix a lot... at the engine level... but at the tool level
> :informix really sucks (sorry).
>
> Have to agree with this sentiment. After having had the chance to use
> PL/SQL for a few projects, I now have to wonder why Informix never provided
> similar capabilities. As SPL is already part of the engine, it seems to be
The reasons are historical. At the beginning Informix engines came bundled
with ISQL which provides Perform screens for building quick and not so dirty
data maintenance apps and Ace reports for quick and not so dirty reporting. In
addition, there was always the option to install 4GL for anything more complex
and ESQL-C/FORTRAN/COBOL for anything that required lightning performance and
full server access.
There was, as the folk at Menlo likely saw it, reason for expanding the SQL
interface to include programming constructs, indeed even SPL did not exist
prior to OL 4.10.
On the other hand, Oracle did not have such excellent tools for data
management and manipulation as external entities (neither did DB2, Sybase or
Ingres for that matter so this is not an indictment of Oracle), so they chose
a different path and created PL/SQL as a full fledged programming language.
Yes, the unbundling of OL/IDS and ISQL in OL 5.00 does mean that from then on
one had to purchase and install additional tools, but that does not mean that
such excellent tools are not available! Just because you only bought a hammer
when you bought your house does that mean you can't or should not have to
purchase a screw driver to install screws? Personally I prefer my SQL pure,
and my RDMS engine simpler. Programming languages are for programming and SQL
is certainly NOT a programming language, its a p*^^ poor data retrieval
language (Lord I miss QUEL!). When I need to perform data management I have
MANY choices from simply crafting KSH scripts piping SQL and results in and
out of dbaccess (or more commonly Jonathan's excellent sqlcmd), to writing a
Perl/DBD/DBI script, to using my template library to pull together a new
maintenance application in 2 hours or less, to writing a new ESQL/C
application or cloning an old one or most likely reusing a more general
purpose app I wrote once and reuse.
Arguing that Oracle is superior to Informix because it has PL/SQL instead of
program development tools is akin to telling me that emacs sucks because you
cannot do .<return> to repeat a command.
Art S. Kagel
> a *relatively* easy task (i.e. making all of SPL available for ad hoc
> queries). There is just a ton of stuff you can do in Oracle with just
> sqlplus running pl/sql scripts. To do anything comparable with Informix, I
> gotta pull out ESQL/C, perl/DBI, etc. Certainly doable, but requires the
> installation of additional tools, which is not always an option.
>
> plink, plink.
> Dave
Art S. Kagel wrote: > > The reasons are historical. At the beginning Informix engines came bundled > with ISQL which provides Perform screens for building quick and not so dirty > data maintenance apps and Ace reports for quick and not so dirty reporting. In > addition, there was always the option to install 4GL for anything more complex > and ESQL-C/FORTRAN/COBOL for anything that required lightning performance and > full server access. > <snip> > On the other hand, Oracle did not have such excellent tools for data > management and manipulation as external entities (neither did DB2, Sybase or > Ingres for that matter so this is not an indictment of Oracle), so they chose > a different path and created PL/SQL as a full fledged programming language. > I'm sure they weren't as polished as Perform and Ace, but Oracle also had Forms (SQL*Forms) and Reporting tools (SQL*Rpt) available long before PL/SQL became available in the engine (Oracle 7). Also Pro*COBOL, Pro*Fortran etc for embedded SQL. It wasn't a lack of supporting tools that drove the development of PL/SQL.
Also sprach "Art S. Kagel" <kagel@bloomberg.net> : :On Mon, 30 Aug 2004 21:32:25 -0400, Dave wrote: : :> Also sprach Jesus Antonio Santos Giraldo <jeansagi@myrealbox.com> : :> :> :> :I like Informix a lot... at the engine level... but at the tool level :> :informix really sucks (sorry). :> :> Have to agree with this sentiment. After having had the chance to use :> PL/SQL for a few projects, I now have to wonder why Informix never provided :> similar capabilities. As SPL is already part of the engine, it seems to be : :Arguing that Oracle is superior to Informix because it has PL/SQL instead of :program development tools is akin to telling me that emacs sucks because you :cannot do .<return> to repeat a command. : :Art S. Kagel Art, I never said nor argued that Oracle was superior to Informix, only that at the tool level, Informix left a lot to be desired. I fully understand the history, having worked for Informix for 10 years (from the intro of Turbo to the 7.x releases). While I understand your preference for the "pure" SQL, the fact that SPL exists for stored procedures means the engine is already complicated with the code to support it, so why not make it more generally applicable? Dave