Again, clearer SQL behind DBAccess
Posted in 1999
Topics: Server Administration, Security, Permissions & Auditing
I am about to write an application that does what dbaccess does.
Anyone out there that knows what the SQL behind the sceens look like ?
It would save me hours of work and thought, an URL or a mail or a
respons here ?
Some clearification :
First , thank's for the answers so far - but it is NOT possible to use a
prompt-started program :-(
The system is run nationwide in Sweden on NT boxes, using smartcards for
identifying the
users, and a very high security policy.
End users can ONLY access the database AND the central system with
special written
applications ( and I am about to write another one solving this
problem)..
So end users are NOT allowed to make a Telnet connection to the central
system.
Our DBA can of course maintain his work from a double password controled
special room
but end users = NO PROMPT.
So the question still is : What does dbacccess do ? What is the SQL
behind it ?
TIA
Jan Nilsson
pro IT
You're going to need to use descriptors.
Jan Nilsson wrote:
> I am about to write an application that does what dbaccess does.
> Anyone out there that knows what the SQL behind the sceens look like ?
> It would save me hours of work and thought, an URL or a mail or a
> respons here ?
>
> Some clearification :
> First , thank's for the answers so far - but it is NOT possible to use a
> prompt-started program :-(
>
> The system is run nationwide in Sweden on NT boxes, using smartcards for
> identifying the
> users, and a very high security policy.
> End users can ONLY access the database AND the central system with
> special written
> applications ( and I am about to write another one solving this
> problem)..
> So end users are NOT allowed to make a Telnet connection to the central
> system.
> Our DBA can of course maintain his work from a double password controled
> special room
> but end users = NO PROMPT.
> So the question still is : What does dbacccess do ? What is the SQL
> behind it ?
>
> TIA
>
> Jan Nilsson
> pro IT
--
Madison Pruet
===========================================
Enterprise Replication Product Developement
Dallas, Texas
Informix Software
===========================================
Why don't you take a look at SQLCMD in the IIUG archives
(http://www.iiug.org).
I released version 52 (without much fanfare) earlier this week.
It is a command line SQL command interpreter like DB-Access operated out of
screen mode. Although that seems silly in the light of what you just
suggested, it might be a good starting point. It covers the SQL stuff
pretty well, anyway, so you'd need to worry about the presentation layers.
Jan Nilsson wrote:
> I am about to write an application that does what dbaccess does.
> Anyone out there that knows what the SQL behind the sceens look like ?
> It would save me hours of work and thought, an URL or a mail or a
> respons here ?
>
> Some clearification :
> First , thank's for the answers so far - but it is NOT possible to use a
> prompt-started program :-(
OK, but define a prompt-started program. Something somewhere will kick the
program off.
Does it need to be a full-screen GUI program? Or a green-screen
curses-driven program? Or
a line-based interface. You'll find SQLCMD pretty reasonable if you want a
line-base interface.
I consciously chose not to provide either a curses-driven or a GUI version
of it; if I wanted to
do that, I'd probably use Tcl/Tk or Perl/Tk to handle the GUI (and DB-Access
if I wanted a
curses-driven system).
> The system is run nationwide in Sweden on NT boxes, using smartcards for
> identifying the
> users, and a very high security policy.
> End users can ONLY access the database AND the central system with
> special written
> applications ( and I am about to write another one solving this
> problem)..
>
OK, but DB-Access is seldom the required program under such circumstances,
because users
are barely constrained except by the raw SQL permissions (which are usually
too lax, but that's a separate topic for discussion). What is your
DB-Access surrogate going to provide to the users?
How is it going to constrain them?
> So end users are NOT allowed to make a Telnet connection to the central
> system.
> Our DBA can of course maintain his work from a double password controled
> special room
> but end users = NO PROMPT.
> So the question still is : What does dbacccess do ? What is the SQL
> behind it ?
The basic ESQL behind it is sequences of:
PREPARE
EXECUTE
FREE
or
PREPARE
DECLARE
OPEN
FETCH
CLOSE
FREE
FREE
That's all there is to it. Mostly the SQL is typed by the user. Sometimes
it is generated internally
(eg for the INFO options).
--
Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net)
Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN
#include <disclaimer.h>
Jonathan, I just happened to stumble into SQLCMD last week whilst downloading something else, installed SQLCMD, and like it a lot. It is exactly what has been missing for those of use who work around some of the features of DB-Access. It would be great to see you extend this to have the same kind of functionality as ISQL from Sybase, with a bit of if-then-else like Sybase's ISQL has. I also noticed that the output is automagically pipe-delimited. I haven't really read your docs, is there a way to get it to output without the pipe delimiters? Either that or Informix should buy up Sybase, then port the Sybase ISQL over to Informix products. :-) Anyway, SQLCMD is very cool, keep up the great work! Tim Jonathan Leffler wrote: > > Why don't you take a look at SQLCMD in the IIUG archives > (http://www.iiug.org). > I released version 52 (without much fanfare) earlier this week. > > It is a command line SQL command interpreter like DB-Access operated out of > screen mode. Although that seems silly in the light of what you just > suggested, it might be a good starting point. It covers the SQL stuff > pretty well, anyway, so you'd need to worry about the presentation layers. > > -- > Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) > Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN > #include <disclaimer.h> -- . .- .-- .--- .---- Tim Schaefer .----- tschaefe@bellsouth.net .---- http://www.inxutil.com .--- http://www.datad.com .-- .- .
Tim Schaefer wrote: > Jonathan, > > I just happened to stumble into SQLCMD last week whilst downloading > something else, installed SQLCMD, and like it a lot. It is exactly > what has been missing for those of use who work around some of the > features of DB-Access. Thanks. > It would be great to see you extend this to > have the same kind of functionality as ISQL from Sybase, with a bit > of if-then-else like Sybase's ISQL has. Not having used Sybase's ISQL, I'm a little handicapped. How much of the feature set is actually provided by Transact-SQL and how much is strictly in the ISQL front-end program? However, extending SQLCMD to recognize IF/THEN/ELSIF/ELSE/END IF is something I have vaguely considered, along with WHILE/END WHILE and so on. I haven't done so for a variety of reasons. One is that it is hard to integrate the SQL with the procedural, with issues like "when do you stop" being prominent. Another is that it would probably be better to use a pre-existing scripting language -- Tcl/Tk or Perl or Pythin spring to mind. Until recently, SQLCMD did not use a formal (Yacc) grammar, which was another reason for not trying to do anything fancy. However, since SQLCMD does now use a Yacc grammar, it would be feasible to use it for handling other issues too. > I also noticed that the output is automagically pipe-delimited. I haven't > really read your > docs, is there a way to get it to output without the pipe delimiters? I should probably say RTFM, but "delim '\\t';" sets the delimiter to tab, for example. You can also choose 'format fixed;' to get fixed format output with no field separators, and you can choose between 'format select' and 'format unload' to choose whether you get a trailing delimiter on the output. Current versions of LOAD do not require a final delimiter, incidentally; there is a document describing my understanding of Informix's UNLOAD format in with the SQLCMD source code. There are also two equivalent formats "csv" and "quote" which output non-numeric data in quotes and use commas to separate the fields. Now, let's see; your question was? > Either that or Informix should buy up Sybase, then port the Sybase > ISQL over to Informix products. :-) > > Anyway, SQLCMD is very cool, keep up the great work! > Thanks again. > > > Jonathan Leffler wrote: > > Why don't you take a look at SQLCMD in the IIUG archives > > (http://www.iiug.org). I released version 52 (without much fanfare) earlier > this week. > > > > It is a command line SQL command interpreter like DB-Access operated out of > > screen mode. Although that seems silly in the light of what you just > > suggested, it might be a good starting point. It covers the SQL stuff > > pretty well, anyway, so you'd need to worry about the presentation layers. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.62 -- see http://www.perl.com/CPAN #include <disclaimer.h>