kalb@dasys1.UUCP (Stephen Kalb) (05/18/89)
What do you think of your UNIX relational database software? I have
to choose a UNIX RDBMS to run on a network of SUN 4's. It should have
the following features:
1) C-Library Interface (and maybe embedded SQL).
2) Network Capable Client Server Architecture (diskless clients, 4/260 server).
3) Interactive SQL Interface (SQL> select * from foo).
4) Screen Based Interface (w/ default screens extant by virtue of the schema).
The quality of items 1 & 2 are more important than 3 & 4. 3 & 4 are
more-or-less necessary conveniences.
We're not building a database application; we're building an
application that should take advantage of database tools that somebody
else has already built. Our database needs should be simple but we
don't want to be nearsighted and preculde more intensive database use
by choosing a package with limited functionality.
Under consideration at the moment are Oracle, Sybase, Informix, and
Ingres. If you've used one of these and have comments (pro or con),
I'd really like to hear what you think. One day I'll return the favor.
-Thanx
kalb%dasys1.uucp@nyu.edu -or- ..!cmcl2!dasys1!kalb
^ note l as in limadmc@sei.cmu.edu (Dawn Cappelli) (05/18/89)
In article <9703@dasys1.UUCP> kalb@dasys1.UUCP (Stephen Kalb) writes: > > What do you think of your UNIX relational database software? I have >to choose a UNIX RDBMS to run on a network of SUN 4's. It should have >the following features: > >1) C-Library Interface (and maybe embedded SQL). >2) Network Capable Client Server Architecture (diskless clients, 4/260 server). >3) Interactive SQL Interface (SQL> select * from foo). >4) Screen Based Interface (w/ default screens extant by virtue of the schema). We have a network of approximately 170 Sun 3's and Microvax's. We have configured INGRES (using INGRES Net) on the network such that the databases are resident on a few machines designated as "database machines". Those databases can be accessed from any other machine in the network, since all front-end software is NFS mounted. Back-end executables are locally mounted on the database machines. So we have the same diskless client/server architecture that you described, except that we don't have Sun 4's. I'm very happy with the way INGRES works in this configuration. The initial database connection does take longer from a remote machine, but there is no noticeable time lag in subsequent database accesses. As far as points 1, 3 and 4, I think you'll find those features in most commercial RDBMS'.
consult@osiris.UUCP (Unix Consultation Mailbox ) (05/23/89)
In article <3378@fp.sei.cmu.edu> dmc@sei.cmu.edu (Dawn Cappelli) writes: >In article <9703@dasys1.UUCP> kalb@dasys1.UUCP (Stephen Kalb) writes: >> [My chosen UNIX RDBMS] should have the following features: >> >> 1) C-Library Interface (and maybe embedded SQL).... > > [favorable comments about how Ingres provides other needed features] > As far as points 1, 3 and 4, I think you'll find those features in most > commercial RDBMS'. You won't find 1 in Ingres. It does support embedded SQL, but *not* a C library interface, and all the pleading I have done with RTI developers for the last three years does not seem to have changed any minds except mine (I must admit that I now understand their decision to support only embedded languages, though I still disagree with it). Phil Kos
emuleomo@yes.rutgers.edu (Emuleomo) (05/26/89)
With Respect to a C-library interface, does anybody out there know of any major RDBMS vendor that has a usable C-library interface? (such as the one that Informix 3.3 uses?) Major Vendors include Informix, Oracle, Sybase, IBM (DB2) etc.. I am getting frustrated with the performance of embedded SQL. Frankly I don't know why Informix Software is reluctant to support 3.3 !!! It is a _super_ product especially for interactive use. Respondez S'il vout Plait. E-mail ==> emuleomo@yes.rutgers.edu -- Emuleomo O.O. (A previously happy user of Informix 3.3)
forrest@phobos.sybase.com (Jon Forrest) (05/30/89)
In article <May.26.10.00.53.1989.196@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: > >With Respect to a C-library interface, does anybody out there know >of any major RDBMS vendor that has a usable C-library interface? >(such as the one that Informix 3.3 uses?) >Major Vendors include Informix, Oracle, Sybase, IBM (DB2) etc.. I'd like to hear about what you find objectionable with the C-library interfaces from the major vendors in general, and from Sybase's in particular. I bet other readers from the major vendors would also like to hear your thoughts. Jon Forrest forrest@sybase.com {pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest 415-596-3422
tim@binky.sybase.com (Tim Wood) (05/30/89)
In article <May.26.10.00.53.1989.196@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: > >With Respect to a C-library interface, does anybody out there know >of any major RDBMS vendor that has a usable C-library interface? >(such as the one that Informix 3.3 uses?) >Major Vendors include Informix, Oracle, Sybase, IBM (DB2) etc..... > [ frustration w/ Informix deleted ] >-- Emuleomo O.O. (A previously happy user of Informix 3.3) The Sybase client library, called DBLIB, is our standard C-library interface. It was introduced with our first products. We do not presently have an embedded query-language interface. DBLIB is also available for several other languages such as FORTRAN, COBOL and ADA. DBLIB supports application login to the DBMS server, data representation conversion (i.e. byte-swap between, say, a 68000-based front-end and a VAX-based server or between floating point formats), and two-phase commit (distributed update) control among other things. Our basic aim with DBLIB is to make it an open standard for client-server database applications. We want other software vendors to use it as the basic interface for creating Sybase-compatible applications. Thus a software vendor can answer a DBMS application need by licensing DBLIB and constructing an application for the Sybase DBMS on top of it. This way, many different vendors collectively add value to the Sybase DBMS (SQL Server) where the applications needs exist. Naturally, we're convinced our product is flexible and powerful enough to meet that broad range of needs. Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim Voluntary disclaimer: This message is solely my personal opinion. It is not a representation of Sybase, Inc. OK.
steinar@fdmetd.uucp (Steinar Overbeck Cook) (05/30/89)
In article <May.26.10.00.53.1989.196@yes.rutgers.edu>, emuleomo@yes.rutgers.edu (Emuleomo) writes: > ..... > I am getting frustrated with the performance of embedded SQL. > What is wrong with the use of embedded SQL ?. With the use of embedded SQL your 'C' programs are much more portable than with the use of some proprietary C-interface. Personally I use Pro*C with our Oracle database. The precompiler from Oracle is lousy, but I like embedding SQL in my C-programs. -- Steinar Overbeck Cook, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY Phone : +47 2 52 80 80 Fax : +47 2 52 85 10 E-mail : ...!mcvax!ndosl!fdmetd!steinar or steinar@fdmetd.uucp <The opinions expressed, if any, do not represent Fellesdata a.s>
emuleomo@yes.rutgers.edu (Emuleomo) (05/31/89)
Path: paul.rutgers.edu!aramis.rutgers.edu!rutgers!cs.utexas.edu!uunet!mcvax!ndosl!fdmetd!steinar From: steinar@fdmetd.uucp (Steinar Overbeck Cook) Newsgroups: comp.databases Subject: Re: Do you like your UNIX RDBMS? Summary: What's wrong with embedded SQL ? Message-ID: <427@fdmetd.uucp> Date: 30 May 89 07:33:56 GMT References: <9703@dasys1.UUCP> <3378@fp.sei.cmu.edu> <2907@osiris.UUCP> <May.26.10.00.53.1989.196@yes.rutgers.edu> Organization: Fellesdata a.s, Oslo, Norway Lines: 17 In article <May.26.10.00.53.1989.196@yes.rutgers.edu> Steinar Overbeck Cook, writes: > What is wrong with the use of embedded SQL ?. With the use of embedded > SQL your 'C' programs are much more portable than with the use of some > proprietary C-interface. Personally I use Pro*C with our Oracle > database. The precompiler from Oracle is lousy, but I like embedding > SQL in my C-programs. > The problem with Embedded SQL is that is super lousy for browsing thru' a database. Suppose you issue a query and there are 1000 matching records. Are you aware that ALL the current ESQL implementations require that you WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? Thus your client will be FORCED to wait for up to 5 minutes before he/she gets a response from a simple query! This certainly is NOT PROGRESS. Remember that in _LOWLY_, pseudo-relational Dbase III you can access the 1st record of a matching set super-quickly by using filters and the other records by doing a SKIP. Also this can be done similarly in Informix 3.3. (I think this goes to show that we need 2 simultaneous database models. Relational and Network!) Also, another sore point with a DBMS like ORACLE is that you can't access a PREVIOUS record. ie. you can't browse backwards. THIS SUCKS!! Again, in lowly Dbase, all you have to do is SKIP -1. *** DO YOU NOW SEE WHAT IS WRONG WITH EMBEDDED SQL!!! *** --- Emuleomo O.O. (Disgusted with Embedded SQL!!)
hughes@math.Berkeley.EDU (Eric Hughes) (05/31/89)
In article <May.30.18.32.22.1989.943@yes.rutgers.edu>, emuleomo@yes (Emuleomo) writes: >The problem with Embedded SQL is that is super lousy for browsing thru' a >database. [example deleted] [Summary: an embedded query is completely processed before any access] > (I think this goes to show >that we need 2 simultaneous database models. Relational and Network!) [other example about lack of ability to go backwards deleted] The answer is not to keep more than more than one data model around. The problem lies in the implementation, not the idea. First, sometimes it is the case that the whole query must be processed before any viewing takes place. This happens under many conditions. For example, when no physical index exists which corresponds to the sort order of the requested table, the whole table must be constructed and then sorted. For example, when a quantifier which maps to a relational DIVISION operation is present, generally at least one operand must be constructed as a temporary file. If the user is not the sole user of the database, there may be a problem with updating (add/change/delete) taking place some member table while the SQL cursor is active. Sometimes this doesn't matter, sometimes it is very important. I do not know if any commercial system allows one to specify such a parameter. But, if none of the above are relevant, then the optimizer for the runtime SQL is cheap and lowly. 'SELECT *' on a database table should pull up the first record quickly, or the vendor has not supplied a very good implementation. A common case for selection (at least in what I do) is where the order of the constructed table is derived from the physical index of a record, and all other records are joined to it by foreign keys for which physical indices are available. In this case the obvious optimization is to read the root record, then read in any child record by its foreign key, and so one until all records have been joined. I am not familiar enough with embedded SQL to say whether any commercial products do this. From what the previous poster's experience shows, he does not seem to have come across any such. Eric Hughes hughes@math.berkeley.edu ucbvax!math!hughes
jkrueger@daitc.daitc.mil (Jonathan Krueger) (05/31/89)
In article <May.30.18.32.22.1989.943@yes.rutgers.edu>, emuleomo@yes (Emuleomo) writes: >The problem with Embedded SQL is . . . >Suppose you issue a query and there are 1000 matching records. >Are you aware that ALL the current ESQL implementations require that you >WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? This is incorrect. One extant counter-example is RTI INGRES. Doubtless there are others. -- Jon --
elgie@canisius.UUCP (Bill Elgie) (05/31/89)
In article <May.30.18.32.22.1989.943@yes.rutgers.edu>, emuleomo@yes.rutgers.edu (Emuleomo) writes: > The problem with Embedded SQL is that is super lousy for browsing thru' a > database. Suppose you issue a query and there are 1000 matching records. > Are you aware that ALL the current ESQL implementations require that you > WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? > Thus your client will be FORCED to wait for up to 5 minutes before he/she > gets a response from a simple query! This sounds somewhat exaggerated, unless one is running on an extremely slow machine. Example using INGRES; times are elapsed time in seconds from start of query to end of all output: select apx. 1000 records from a table containing apx. 35000 records. selection produced by a join to a similarly-sized table and a restriction by the value of an attribute in the second table. VAX 8550 - 9 secs; MIPS M/120 - 4 secs. I don't know whether "all ESQL implementations require that you wait..." is true or not (I haven't had the privilege of trying all ESQL implementations) but several things should be kept in mind: 1. in many cases, all records may have to be examined first to satisfy the conditions of the query (one example is "sort by"..); 2. depending on how many records are involved, their "size", organiza- tion of the physical files containing the data, and the configuration of the system(s) supporting the database, it may be more optimal to extract the entire selection first, place it in a buffer, and then process it record-at-a-time; 3. (1) and (2) naturally lead to (3), which is that the quality of the query optimizer can have a major impact on all of this. Automatically grabbing and displaying the "first record" is not necessarily the best strategy (or the correct one). - and there are a "few" other details that may enter into this, such as the volatility of the data base, concurrency, etc..... greg pavlov (under borrowed account), fstrf, amherst, ny.
emuleomo@yes.rutgers.edu (Emuleomo) (06/01/89)
I really dont find anything objectionable in C-library interfaces.
What I found objectionable was Informix Software's decision NOT
to supply an ALL-II like C-library interface to Informix SQL/ESQL.
ALL-II is a beautifully designed C-library for Informix 3.3.
What I really wanted to know was if any other _Major_ manufacturer had
something like that for their SQL based product.
It is not all the time that I wish to access my data via Embedded SQL!!!
--Emuleomo O.O. (A satisfied Informix 3.3 user who is BEING FORCED to convert
to Embedded SQL to keep up with the times!!)robf@squid.rtech.com (Robert Fair) (06/01/89)
> >In article <May.26.10.00.53.1989.196@yes.rutgers.edu> Steinar Overbeck Cook, writes: >> What is wrong with the use of embedded SQL ?. With the use of embedded >> SQL your 'C' programs are much more portable than with the use of some >> proprietary C-interface. Personally I use Pro*C with our Oracle >> database. The precompiler from Oracle is lousy, but I like embedding >> SQL in my C-programs. >> > >The problem with Embedded SQL is that is super lousy for browsing thru' a >database. Suppose you issue a query and there are 1000 matching records. >Are you aware that ALL the current ESQL implementations require that you >WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? >Thus your client will be FORCED to wait for up to 5 minutes before he/she >gets a response from a simple query! This is completely untrue ! There is no constraint in SQL systems which says that you have to wait for all the data before you get the first row. Certainly INGRES normally allows you to start looking at data as soon as the first row in the resultant dataset has been found - in R6 both cursors and the SELECT-loop do this. [In R5 things were more complex with multiple cursors] >This certainly is NOT PROGRESS. Remember that in _LOWLY_, pseudo-relational >Dbase III you can access the 1st record of a matching set super-quickly by >using filters and the other records by doing a SKIP. >Also this can be done similarly in Informix 3.3. (I think this goes to show >that we need 2 simultaneous database models. Relational and Network!) >Also, another sore point with a DBMS like ORACLE is that you can't access >a PREVIOUS record. ie. you can't browse backwards. THIS SUCKS!! >Again, in lowly Dbase, all you have to do is SKIP -1. In the latest ANSI SQL standard there is a proposal to add FETCH PREVIOUS to cursors to do exactly what you want. > >*** DO YOU NOW SEE WHAT IS WRONG WITH EMBEDDED SQL!!! *** > >--- Emuleomo O.O. (Disgusted with Embedded SQL!!) The problem with programs like DBASE is that they limit you to a specific implementation. By using SQL/ESQL your programs are portable across multiple machines and vendors - by using COMMON-SQL* my applications should run on INGRES, RDB, DB2, etc without any change! There are many other benefits to using ESQL (or a call-interface that takes SQL, like SYBASE), over a low-level record interface, including: - The SQL query is at a higher level of abstraction, so it should be more compact, maintainable & easy to read. This is especially important for complex multi-table queries. - It allows the DBMS to have a decent query optimizer, instead of having to hard-code access paths. This makes schema changes easier and the code more maintainable & easier to read. - Since the SQL & ESQL syntax is so similar, ESQL queries can usually be bench-tested in interactive-SQL before being implemented, saving lots of debugging time later. Robert L. Fair RTI Tech Support
davek@rtech.rtech.com (Dave Kellogg) (06/01/89)
>In article [...] emuleomo@yes.rutgers.edu (Emuleomo) writes: > ..... > I am getting frustrated with the performance of embedded SQL. > I think you've got the tail wagging the dog here. If you are frustrated with the performance of your SQL-based DBMS, it's the SQL engine that you should be worried about. Generally, if things are slow it's not because Embedded SQL is running slowly, it's because your queries to the database are running slowly. Therefore, causing yourself a lot of pain and using a call-level interface (with say 2-4 times the amount of code) and sending the same SQL statements to the engine won't change a thing. If the problem is the server's performance in processing SQL queries, it doesn't matter HOW the SQL got to the server. You can code it in Embedded SQL, call-level 3GL, or interactively, and it shouldn't change the performance of the queries one bit. That is, I'd argue that you are really "frustrated with the performance of your database engine" not with "embedded SQL," and changing your interface to the server won't help. (This is all on the assumption that Informix has a reasonable ESQL implementation, which I assume, but don't know for sure) David Kellogg Relational Technology (INGRES) New York City
wong@rtech.rtech.com (J. Wong) (06/02/89)
In article <May.30.18.32.22.1989.943@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: >In article <May.26.10.00.53.1989.196@yes.rutgers.edu> Steinar Overbeck Cook, writes: >> What is wrong with the use of embedded SQL ?. [RE: As opposed to a C language interface to the DBMS.] > >The problem with Embedded SQL is that is super lousy for browsing thru' a >database. Suppose you issue a query and there are 1000 matching records. >Are you aware that ALL the current ESQL implementations require that you >WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? I know for a fact that INGRES does not wait for all 1000 records to be found, so your claim of all is false. >Thus your client will be FORCED to wait for up to 5 minutes before he/she >gets a response from a simple query! >This certainly is NOT PROGRESS. Remember that in _LOWLY_, pseudo-relational >Dbase III you can access the 1st record of a matching set super-quickly by >using filters and the other records by doing a SKIP. >Also this can be done similarly in Informix 3.3. (I think this goes to show >that we need 2 simultaneous database models. Relational and Network!) >Also, another sore point with a DBMS like ORACLE is that you can't access >a PREVIOUS record. ie. you can't browse backwards. THIS SUCKS!! >Again, in lowly Dbase, all you have to do is SKIP -1. > >*** DO YOU NOW SEE WHAT IS WRONG WITH EMBEDDED SQL!!! *** Confusingly, none of this is specific to Embedded SQL so I don't see how this is relevant to whether one uses a C interface to the DBMS or Embedded SQL. -- J. Wong wong@rtech.com **************************************************************** S-s-s-ay! Newsgroups: comp.databases Subject: Re: Do you like your UNIX RDBMS? Summary: Expires: References: <9703@dasys1.UUCP> <3378@fp.sei.cmu.edu> <2907@osiris.UUCP> <May.26.10.00.53.1989.196@yes.rutgers.edu> <427@fdmetd.uucp> <May.30.18.32.22.1989.943@yes.rutgers.edu> Sender: Reply-To: wong@llama.UUCP (J. Wong) Followup-To: Distribution: Organization: Relational Technology, Inc. Alameda, CA Keywords: In article <May.30.18.32.22.1989.943@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: >In article <May.26.10.00.53.1989.196@yes.rutgers.edu> Steinar Overbeck Cook, writes: >> What is wrong with the use of embedded SQL ?. [RE: As opposed to a C language interface to the DBMS.] > >The problem with Embedded SQL is that is super lousy for browsing thru' a >database. Suppose you issue a query and there are 1000 matching records. >Are you aware that ALL the current ESQL implementations require that you >WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? >Thus your client will be FORCED to wait for up to 5 minutes before he/she >gets a response from a simple query! >This certainly is NOT PROGRESS. Remember that in _LOWLY_, pseudo-relational >Dbase III you can access the 1st record of a matching set super-quickly by >using filters and the other records by doing a SKIP. >Also this can be done similarly in Informix 3.3. (I think this goes to show >that we need 2 simultaneous database models. Relational and Network!) >Also, another sore point with a DBMS like ORACLE is that you can't access >a PREVIOUS record. ie. you can't browse backwards. THIS SUCKS!! >Again, in lowly Dbase, all you have to do is SKIP -1. > >*** DO YOU NOW SEE WHAT IS WRONG WITH EMBEDDED SQL!!! *** I know for a fact that INGRES does not wait for all 1000 records to be found, so your claim of all is false. None of this is specific to Embedded SQL, but may be inherent in the relational model, so I don't see how this is relevant to whether one uses a C interface to the DBMS or Embedded SQL. -- J. Wong wong@rtech.com {sun|mtxinu|amdahl}!rtech!wong **************************************************************** S-s-s-ay!
ben@calvin.sybase.com (ben ullrich) (06/02/89)
if you have to wait 5 minutes for the 1st row of a 1000 result-row query, you
have a fairly rotten dbms. that sounds fairly exceptional to me (and to
others, as the case may be).
i know my applications using sybase front ends never seem to have to ``wait for
all the rows to be found'' before i can see any. i must admit i am not sure if
our sql server waits until all rows are located before sending any, but i
highly doubt it; it seems like a stupid thing to do. after all, we're in the
business of moving rows around quickly, not sitting on them. and even so,
sybase is fast enough that it doesn't seem to matter, not in my experience,
anyway.
..ben
----
ben ullrich consider my words disclaimed,if you consider them at all
sybase, inc., emeryville, ca
+1 (415) 596 - 3500 "skinheads are pinheads!" -- greg sullivan
ben@sybase.com {pyramid,pacbell,sun,lll-tis}!sybase!benjohn@anasaz.UUCP (John Moore) (06/03/89)
In article <May.30.18.32.22.1989.943@yes.rutgers.edu] emuleomo@yes.rutgers.edu (Emuleomo) writes:
]
]The problem with Embedded SQL is that is super lousy for browsing thru' a
]database. Suppose you issue a query and there are 1000 matching records.
]Are you aware that ALL the current ESQL implementations require that you
]WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE?
]Thus your client will be FORCED to wait for up to 5 minutes before he/she
]gets a response from a simple query!
This can be gotten around with Informix Turbo, although it requires a
sneaky trick that I don't remember off the top of my head.
--
John Moore (NJ7E) mcdphx!anasaz!john asuvax!anasaz!john
(602) 861-7607 (day or eve) long palladium, short petroleum
The 2nd amendment is about military weapons, NOT JUST hunting weapons!bodhi@iscuvc.iscs.com (Satyabodhi) (06/05/89)
In article <May.30.18.32.22.1989.943@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: >The problem with Embedded SQL is that is super lousy for browsing thru' a >database. Suppose you issue a query and there are 1000 matching records. >Are you aware that ALL the current ESQL implementations require that you >WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? >Thus your client will be FORCED to wait for up to 5 minutes before he/she >gets a response from a simple query! This is not true with EMPRESS ESQL. With Empress you get the first record right away. >Also, another sore point with a DBMS like ORACLE is that you can't access >a PREVIOUS record. ie. you can't browse backwards. THIS SUCKS!! >Again, in lowly Dbase, all you have to do is SKIP -1. >--- Emuleomo O.O. (Disgusted with Embedded SQL!!) Empress provides a C library interface which allows reading previous record(s). You may not read previous with Empress ESQL. To read backward with ESQL, you issue a fresh select, which inverts your previous order-by clause and limits your selection to what you have already seen. Programs written with ESQL have a chance to be ported to a new DBMS. All C library interfaces are proprietary.
da@bvax.UUCP (Dave Sellers) (06/07/89)
In article <114@anasaz.UUCP>, john@anasaz.UUCP (John Moore) writes: > ]database. Suppose you issue a query and there are 1000 matching records. > ]Are you aware that ALL the current ESQL implementations require that you > ]WAIT FOR THE 1000 RECORDS TO BE FOUND EVEN BEFORE YOU CAN VIEW THE 1ST ONE? > ]Thus your client will be FORCED to wait for up to 5 minutes before he/she > ]gets a response from a simple query! Well if you have to wait more than 5 seconds, there is a problem and the RDBMS is searching the whole DB. No one will ever wait 5 MINUTES (or shouldn't). Our Sun takes <>30 seconds to run all 60K records and only a few seconds to extract ??? records if the optomizer (sp?) is not screwed up. Dave