Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!brutus.cs.uiuc.edu!jarthur!elroy.jpl.nasa.gov!hacgate!ashtate!dbase!cy
From: cy@dbase.A-T.COM (Cy Shuster)
Newsgroups: comp.databases
Subject: Re: Is dBASE IV SQL really slow?
Message-ID: <421@dbase.A-T.COM>
Date: 9 Feb 90 01:28:26 GMT
References: <16946.25cffdfa@ccavax.camb.com> <419@dbase.A-T.COM>
Reply-To: cy@dbase.UUCP (Cy Shuster)
Organization: Ashton Tate Development Center Glendale, Calif.
Lines: 19

In article <419@dbase.A-T.COM> awd@dbase.A-T.COM (Alastair Dallas) writes:
>In article <16946.25cffdfa@ccavax.camb.com>, glassmann@ccavax.camb.com writes:
>> I'm new at this, so this may have been discussed already, but...
>> Is dBASE IV SQL incredibly slow?  I created a small table and did a 
>> SELECT WHERE, and it took about 8 seconds, with lots of disk accesses.
>> The equivalent query in normal dBASE took under a second.
[lines omitted]
>... but I have heard others say that dBASE/SQL
>is particularly useful as an introduction to SQL for dBASE users and that
>in this context, speed is not much of an issue...

I agree: it's useful to note that the objective was to provide SQL
support, and as you might expect in any first release, its performance
is not as good as dBASE.  However, I know that there's a certain fixed
amount of overhead in using SQL, so that the case you tried is, perhaps, 
a worst case.  I haven't measured it, but I expect that queries run on
larger tables would start to more closely match dBASE native speed.

--Cy--   cy@dbase.a-t.com   Disclaimer: My opinions only.