Bob Graham writes,

[a bunch of stuff snipped]

> I have a significant problem with this idea of CPU speed affecting this
> ODBC thing, tho'.  Due respect, Joe, but I can't buy it.
>
> First, the test PC in question is a 200mhz/64meg/4meg PCI video
> ball-buster
> that has no problems running anything.  We have run into this duplicate
> record thing on virtually every machine we've run tests on, and all were
> 166mhz pentiums or better.

These machines SHOULD NOT have the problems I spoke of earlier... definately
should not.  The problem described earlier are machines which are, as also
mentioned, 16MB, lower powered CPUs.  They key really is (in order) -
Adequate Memory (on the PC and the 3000), Adequate Disk (for caching), and a
good processor (P166 should be just fine for most applications).

> Second, we have run into the identical problem with not only the HP ODBC
> drivers, but with Minisoft's ODBC/32 driver.   I think that given
> the facts
> we are running into the problem on multiple machines with two
> separate, and
> very different ODBC drivers, we have to look somewhere else for the
> solution.

Actually, a machine can run both drivers (or all four) at the same time --
but remember one thing about the drivers - each handle "connections" in
different ways.

SE will yield one connection per DBE only, and MiniSoft handles connections
is a much different way.  SE is actually the most piggish in terms of
connection efficiency - whereas the commercial drivers are more efficient.

> We are pretty sure (subject to further testing) that the problem only
> involves detail datasets where a unique key hasn't been defined.
> We notice
> that if there are two detail records meeting the key
> specifications, we get
> duplicate records.  If there are three detail records, we get triplicates,
> and so on.

This will do it... using JET, one MUST have a unique key defined, or the
Updatable property will be returned as False.  Details will always return as
false unless linked through Access with a unique defined.  Detail access via
Direct ODBC (without using Access) will always yield a non-updatable
recordset without some fancy footwork in the code.  (Again, this assumes the
use of JET)

Joe