Evaluating to EOF when in fact it is not

[JulieS]

I am searching for duplicate values using findnext. THis is done in an outer Do Until rst.EOF loop, which rst.movenext at the end of the loop.

The problem is that it thinks it is EOF with every new record that does not have a duplicate. I've gone crazy testing whether it is a new record within my code, and am thinking could it be an EOF problem???
Anyone ever come across this nonsense before?

Thanks and I hope you have,
julie

 

[smedvid]

Never seen that one, but make sure you have the latest Access version (Service Pack/Release) loaded. I had Access 2000 adding records to a sub-form at random, turns out it was an Access bug.

In terms of duplicates, I just use DCount() for a quick check to see if there is more than 1 record. Unless you need the specific details of the duplicate. htwh Steve Medvid
"IT Consultant & Web Master"

http://users.erols.com/medvid/

 

[MichaelRed]

JUlie, Julie, Julie,

Haven't we been through this? The (Outter)rst.EOF <> (Inner)rst.eof. You must get it straight. The OUTTER loop is the LIST of duplicates, the INNER loop is the table WITH the duplicates. The OUTTER Loop is just to get the Criteria which describes the DUPlicates. The INNER Loop needs to find the first, then findNEXT (and delete) until it's EOF, then fall through to the OUTTER Loop MOVENEXT.

Sigh -- someday it will be clear.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[JulieS]

Michael, Michael, Michael. Thank you for being so loyal.
I did manage to somewhat figure out all that loop .. stuff.
This new problem arises because I am importing data from excel using the DoCmd.TransferSpreadsheet function.

So, my first button imports the data.
The second button assigns the IDs (soon I will figure out how to make this a separate procedure so I can call it, but that's for another day).

The first import and ID assignment works great.
When I import again so new data is written to the table then click the Assign ID button, the EOF evaluates to true too early (i believe it is not reading the new import, or at least some of them). Should I be doing some sort of append? I have no idea why it's not reading it.

Have i mentioned I love programming.

 

[MichaelRed]

Hmmmmmmmmmm,

Not enough for this crystal ball to see through the cloudy stuff that is always inside.

As a GENERAL practice, I would not import 'new' information directly into a production app table. The process is somewhat easier in small steps (no leaping of tall mountains from here).

There is a 'tblTemp'.

Frst baby step is to delete * from it (or -possibly- delete it altogether.

Next, transfer is to a 'tbltemp' .

BIG step. Validate what came in through the transfer. Flag invlaid records for further processing.

Append Query to add tblTemp (valid) records to Production Table.

Return / Rerout Invalid records back to 'proper' authourity. Not always the sender or originator!

Repeat in small doses.

MichaelRed
m.red@att.net

There is never time to do it right but there is always time to do it over

 

[JulieS]

that sounds sane. i'll try it.
thanks (you may be hearing from me ..... )

 

[maggieb]

Are you moving to the first record each time before beginning the search?