HP3000-L Archives

April 1998, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bob Graham <[log in to unmask]>
Reply To:
Bob Graham <[log in to unmask]>
Date:
Sat, 18 Apr 1998 20:12:36 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (61 lines)
----------------original thread (sort of)--------------
>Lars asks,

>> >As for the duplicates - lower powered CPUs and/or PCs with low memory
do
>> >have this problem with Access and Linked Tables.  You may try
>> this on a PC
>> >which is at least (...)
>>
>> As English is not my native language I might have misunderstood that
part
> >of the posting... To me this sounds as if a faster/bigger/better PC may
> >not only return/display results faster then a
> >slower/smaller/boughtlastweek
> >PC, but it also might have a higher chance of yielding _correct_
output??

>Actually, I was talking about Window refresh, as well as handling things
>like returned rows.  JET will, if read only, normally return a "Snapshot"
>type Recordset, in which all of the data requested is returned (and
cached).
>A Read/Write - enabled query will normally return a "Dynaset" type
>recordset, where a keyset only is retrieved, as well as the first "x" rows
-
>all of which is cached.

>Again - when I said "there's a lot going on in there" - it's just not
>Access, but also ODBC Manager, the driver itself, and depending on the
>amount of data being accessed - one heck of a lot of network traffic and
>data handling by the DBMS Engine (JET) itself.
-----------------------------
First off, Lars, we can assume you're making another one of your little
jokes...I've heard you on the HP Technology tapes and read a good deal of
your email, and your English is at least as good, and probably better than
most of the Americans I know.  Your point about CPU speed is well taken.

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.

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. 

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.

We remain open-minded, though, and remain thankful for any help or advise
offered.

Bob "still scratching his old grey head" Graham

ATOM RSS1 RSS2