Re: supports(adIndex) = False

From: SA (~fake.address_at_nspm.com)
Date: 05/28/04 

Date: Fri, 28 May 2004 07:48:03 -0400

Tim:

While I am sure that Denise can appreciate your passion about using DAO (yes
it is more flexible with Access (jet) tables). However, the operation she
is trying to achieve using ADO really should be quite simple and there's no
reason to push a DAO conversion to do a simple seek operation. In fact in
your previous post you recommended using a DAO find method which is normally
slower than a seek operation when using a primary key index.

The issue Denise is facing has something to do more than likely with the
actual table index or something related to the version of the MDAC library
that is on her machine.

Secondly, since VB 6, VB is designed to connect to any data source using
ADO. It is not Jet centric.

Third, ADO is not vital to ODBC. They are two totally different
technologies for data access to multiple data sources and do not even
interact. ADO (and its underlying OLE DB) happens to be designed to be much
more flexible accessing different types of data sources than ODBC.

Fourth, you can do most stuff in SQL Server using DAO pass through queries
if you want to use DAO, because you can run processes on the server that way
rather than locally speeding things up dramatically by reducing network
traffic. Its just if you want to do things like Seeking on record set etc,
that ADO would shine with SQL Server vs. DAO, because seek is not supported
in DAO with link SQL tables.

Fifth, going the MySQL route would NOT require using ADO. It WOULD require
using ODBC or JDBC (if you are into Java). AFAIK, there are no ADO
providers for MySQL.

I would suggest that you learn more about the subjects that you respond on
before you so passionately state incorrect information.

The one point that I agree with you on, and it is a good one, is that it is
normally much more efficient to use a simple SQL select to obtain the
information one needs rather than using a table seek, with the one exception
of reading against a unique (in the case of SQL server, a clustered) index,
where either would normally be about as fast. 

-- 
Steve Arbaugh
Microsoft Access MVP
ACG Soft
http://ourworld.compuserve.com/homepages/attac-cg
"Tim Ferguson" <FergusonTG@softhome.net> wrote in message 
news:Xns94F5AE235ABE3garbleme4455656@207.46.248.16...
> "=?Utf-8?B?ZGVubmlzZw==?=" <dgerber@carrerker.com> wrote in
> news:AD5ED1CB-54DF-47F5-96E8-D46EEE8FB570@microsoft.com:
>
>> OK, this is helping (I am in a learning mode).  "local Jet tables",
>> are what ?  Access db tables, yes?
>
> Tables local the the mdb that the code is running in. If you are really
> using VB (rather than VBA) then there are no such things. That is why I
> mentioned it.
>
>> I changed the application from an OLE Access.application to ADO
>> specifically to use the seek method since the program will be look-up
>> intensive.
>
> OLE Automation of the entire Access App is way over the top -- VB is
> designed to connect directly to a jet mdb, using one of the access
> libraries, ADO/ ADOX or DAO. For my money, there is no reason to use ADO
> with Jet because it's limited and incomplete; DAO gives you more
> functionality and is much easier to program. ADO is vital for ODBC and SQL
> Server etc; but that is not what you suggested. Still, it's horses for
> courses and you are better off using a tool you know well than one you
> don't.
>
>> I had hoped to keep this simple,
>> but if I must go to SQL querys then I probably will leave Access and
>> go to the free MySQL.
>
> Sorry, you just cannot do anything sensible in any modern database
> environment without using SQL -- this has been the great advance in 
> desktop
> databases over the last twenty years. The advantage of using Access/ Jet 
> is
> that it helps you write the SQL so you don't have to know very much. VB
> always used to come with a query design tool and I assume it still does.
>
> Think of trying to look up the mileage of one particular car in a dealer's
> database. You can either set up a recordset consisting of all 33 fields 
> and
> read in all 45,000 records to find it; or you can issue a one-line SQL
> command and get back _one_value_. Which one do you think your network
> manager would prefer?
>
> Going on, I couldn't even begin to think about a table-recordset-oriented
> way of answering something like
>
>  "A list of all children who have complained of bullying, and
>   for each child, the names of all children in the same class
>   who are bigger than them."
>
> ... but I know how I would start to write the SQL!
>
> Moving from Jet to MySQL will certainly mean ADO.
>
> Hope that helps
>
> Tim F
>
>
>
>
>

Relevant Pages
Loading