Run-time Error 3265 - XP vs Win2000?

[crimsntyd]

Hi,
I'm using a VB 6.0 app to connect to/edit/create records in an Oracle HTMLDB database. The application works fine in Win2000 (my PC), but gives the following error on WinXP machines when the user brings up a record to edit:

Run-time error '3265':

Item cannot be found in the collection corresponding to the requested name or ordinal.

I've read some posts concerning this error, but none have anything to do with the OS version. I'm thinking it has something to do with it, but I don't know what? Is there a MDAC_TYP.exe for WinXP? That might be it, but I don't know. Thanks in advance for the help.

 

[BobRodes]

This error means that you are looking for a field in a recordset that doesn't exist. The fact that you're using 2000 on one machine and XP on another is probably irrelevant, although stranger things have happened. You'll need to list out the fields in your recordset and troubleshoot from there.

HTH

Bob

 

[vbSun]

We recently had a similar issue posted in thread222-1306199.

------------------------------------------
The faulty interface lies between the chair and the keyboard.

 

[crimsntyd]

BobRodes,
I'm sorry, but I'm not seeing your logic. How can the record come up in its entirety on the Win2000 machine (more than one, by the way) and crash on the WinXP machine? If the recordset wasn't declared correctly, wouldn't it hose the Win2000 machine, as well?

vbSun,
Thanks for the post. I'm not dealing with Spanish code, but, I'm still in the process of getting on the PC and trying to install MDAC. I'll get back to you. Thanks!

 

[SBerthold]

>How can the record come up in its entirety on the Win2000 machine (more than one, by the way) and crash on the WinXP machine?

I realize the question was directed at BobRodes, but would like to also give a possible answer:

Maybe the Exe is a different version with different code, or maybe the connections are (unknowingly) on two different databases and tables with different structures (field names).

We do not know, but these are often reasons that an error like this is the cause, so by all reason, it would be naturally the first question to ask, and the first thing to want to verify.

So, debugging the recordset fields called (or better, the complete source statement) at run time, and the connection source at both locations, and comparing the results, would be the first thing to do.

This debugging information, from each machine, would be what we also need to see. This information, if done as mentioned, would\may also tell us if there are any problems concerning OS language set (not just spanish) or user settings (even when set to english, a comma as a decimal seperator, which the user can set, may get into a sql statement and be then interpeted as two different elements), and show us the way the record sql statement is actually being put together at run time.

 

[crimsntyd]

Call off the dogs, everyone. I went back to the conference room this morning, and an older .exe was on the machine. I put the current one on the desktop, and it worked fine. Weird thing, when I was in the meeting yesterday in the conf. room, we copied the .exe down off the network, and it didn't overwrite the existing file. Anyway, thanks for the inputs.

 

[strongm]

So you'd agree that Bob was right (as clarified by SBerthold)?

 

[BobRodes]

Well, yes, I would. LOL

 

[crimsntyd]

Yes, I'd agree with Bob that the earlier version of the code had errors in it. Thanks again.

 

[BobRodes]

Yeah, all kidding aside, it would probably have been better advice to rule out a version discrepancy prior to modifying the code to list out the fields. But, of course, once you had made that modification, you'd have updated the version and the problem would have been solved, thereby creating greater confusion.