David W. Fenton wrote:[color=blue]
> Seek with tabletype recordsets is a feature of DAO. I see no point
> in dragging in the term ISAM, whatever historical appropriateness it
> may have, because it is mostly used in Access for things that
> *don't* provide indexed access to data, and, therefore, can't
> provide the benefit you're attributing to ISAM.[/color]
From BC7 Help
<---
ISAM
The Microsoft BASIC Compiler includes a set of ISAM (Indexed Sequential
Access Method) features for writing data management programs. See
Chapter 10, "Database Programming with ISAM," in the BASIC Programmer's
Guide for more information about using ISAM.
The OPEN statement used with the ISAM keyword creates an ISAM database
and tables where they do not exist, and opens them.
See Also BEGINTRANS BOF CHECKPOINT CLOSE COMMITTRANS CREATEINDEX
DELETE DELETEINDEX DELETETABLE EOF FILEATTR GETINDEX$ INSERT LOF
MOVEdest OPEN RETRIEVE ROLLBACK SAVEPOINT SEEKoperand SETINDEX
TEXTCOMP TYPE UPDATE
(MOVEdest)
MOVEFIRST [#]filenumber%
MOVELAST [#]filenumber%
MOVENEXT [#]filenumber%
MOVEPREVIOUS [#]filenumber%
filenumber% The number of an open ISAM table.
(SEEKoperand)
SEEKGT [#]filenumber% ,keyvalue [,keyvalue]...
SEEKGE [#]filenumber% ,keyvalue [,keyvalue]...
SEEKEQ [#]filenumber% ,keyvalue [,keyvalue]...
filenumber% The number of an open ISAM table.
keyvalue An expression less than 256 characters long.
--->
Some of that looks familiar?
Definitions of ISAM
http://www.webopedia.com/TERM/I/ISAM.html http://search390.techtarget.com/sDef...214626,00.html http://www.amr-usa.com/thindex.htm (Paragraph entitled "ISAM (Indexes)")
So DAO is updated, merged the SEEKoperand into one Seek and renamed
SETINDEX and made it a property instead of a command, added a few bits
for SQL support amongst other things and is OO orientated, but do you
still think the tables in the MDB file are anything other than ISAM?
[color=blue]
> No, but I'm just pointing out that speed is not everything. In my
> experience, the number of situations where you need the speed and
> are able to use a tabletype recordset are quite few and far between.
> In 10 years of Access programming, it's never happened to me in any
> of the dozens of applications I've created.[/color]
10 years ago was Access 2.0, not very quick with large data sets and as
I remember, .FindFirst and .FindNext were notoriously slow. Opening just
the bits you wanted in a dynaset improved things but wasn't a patch on
..Seek.
[color=blue]
> I think that's important context, so people who don't have the
> experience won't mistakenly go down this road trying to use it where
> it can't really help your application.[/color]
I've already pointed out the pitfall of using this method earlier in
this thread.
--
[OO=00=OO]