Re: ODBC Refresh Interval

Thanks, David. One of the biggest (and most frustrating) problems I've had
with the ODBC approach (apart from the inability to lock a record, which
isn't a huge deal most of the time), is that I can't rely on FindFirst! With
a form bound to an ODBC linked table, I'll use FindFirst on the
RecordsetClone object to go to a particular record, and, even though I
always check the NoMatch property, oftentimes my user finds themselves at
the wrong record. MS has said in KB articles that this problem was fixed
with Jet x.y, or Jet y.z, or whatever. But I found that it hasn't gone away.

To work around this problem I implemented a routine which does the
following:

1) Perform a MoveLast on the recordsetclone (which creates a significant
delay, of course; but it seems to help the situation greatly).

2) After executing DoEvents, perform the FindFirst on the RecordsetClone
object.

3) If not NoMatch, then go to the recordsetclone record.

4) Explicitly check the value of the record you're at, to make sure it
actually is the right one.

5) If not in the right record, then requery the form, and go back to step 1.

This seems to have resolved the problem. But it sure is a pain to have to do
this for a simple Go To (and it presents delays in the process).

Have you ever had this problem with FindFirst bringing you to the wrong
record? Any tips/ideas/suggestions?

Thanks.


"David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx> wrote in message
news:Xns99B8AD023ECBDf99a49ed1d0c49c5bbb2@xxxxxxxxxxxxxxxxx
"Phil Reynolds" <philr2354@xxxxxxx> wrote in
news:hWmKi.803$4V6.497@xxxxxxxxxxxxxxxxxxxxxxxxxx:

I had heard that ADO was
supposed to be better than ODBC in theory, but that Microsoft
never really brought it to maturity, and that it's still full of
bugs. Not having ever used it, I don't know. But that's what I
heard.

ADO is dead, of course.

MS is now recommending MDB + ODBC for SQL Server back ends.

That brings with it certain problems with Jet which ADP + ADO did
not have (ADPs are now deprecated by MS, though still supported, but
the main selling point was that they bypassed Jet), but ADO brings
its own set of similar problems (it often guesses wrong about what
you want to do, just like Jet does). Usually, Jet + ODBC problems
can be overcome by balancing your work between Jet and the SQL
Server, whereas it's often not so easy to work around ADO's wrong
guesses (from what I've heard -- I never "drank the Kool Aid"
myself, but the people who had the problems were pretty vocal about
them).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/


.

Relevant Pages

  • Re: [Access2003, VBA] Use DAO or ADO?
    ... ODBC, whatever the back end. ... to a jet backend to open a ado recordset. ... customers want/need sql server and another wants to use MySql. ...
    (comp.databases.ms-access)
  • Re: opening ole db databases in access
    ... Ok Brendan, thanks. ... If your data source is not supported by Jet and there ... > is no ODBC driver, then the only way to access the data will be via ADO, ...
    (microsoft.public.access.externaldata)
  • Re: Replacement for Dao
    ... roy fine ... the application uses Jet database or SQL server. ... > that Jet actually provides ADO support through its ODBC (I am still ... > was straight forward in Dao) and hence ODBC may perform better than ADO. ...
    (microsoft.public.vc.database)
  • Re: Access SQL Scalar Function DAYOFWEEK Problem
    ... by the JET ODBC driver for the JET engine to understand and process the ODBC ... Scalar Function DAYOFWEEK. ... Dim strConn As String ...
    (microsoft.public.access.queries)
  • Re: [Access2003, VBA] Use DAO or ADO?
    ... One of the reasons my clients preferred Access / Jet / ODBC was that they ... Autonumber or its server equivalent and could have been shown to the users ... real world of development, Dot Net", ADO has been superceded by ADO.NET ...
    (comp.databases.ms-access)