Compile Error

[tomco22]

With Access 2000 (SP-3) why do I get a compile error that stops on, “rs.findfirst” with the “.findfirst” part highlighted. The error message is, “Compile error: Method or data member not found”

Tom
MCSD
I Nab Terrorists

 

[VBslammer]

Check your references...

VBSlammer

"You just have to know which screws to turn." - Professor Bob

 

[tomco22]

Checked references. I DO have "Microsoft DAO 3.6 Object Library" checked.

Tom
MCSD
I Nab Terrorists

 

[PHV]

You must references the Microsoft DAO 3.x Object Library and use full qualified objects:
Dim rs As DAO.Recordset

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244

 

[tomco22]

DHV,

I think you nailed it! I can't wait to get to work tomorrow to try it. Thank you.

Tom
MCSD
I Nab Terrorists

 

[tomco22]

PHV,

I think you nailed it! I can't wait to get to work tomorrow to try it. Thank you.

Tom
MCSD
I Nab Terrorists

 

[VBslammer]

One thing I never see mentioned regarding references is that you can change the order (priority) of your references using the arrow buttons on the right side of the references dialog. If you move the DAO reference higher up on the list than the ADO reference, then you won't have to qualify the DAO references because Access searches the reference list in order until it finds what it needs.

VBSlammer

"You just have to know which screws to turn." - Professor Bob

 

[RoyVidar]

That's true VBSlammer, and one does find mentioning of it, for instance on this site by FancyPrairie here thread705-939652, but often someone else pops in recommending not to rely upon the order of references.

I'm with PHV here, and I'll put in a couple of words of why I'm one of those who may enter a thread here at Tek-Tips recommending to disambiguate declarations.

If one is as lazy as I am, I use the name rs on a recordset, when I use only one recordset in a routine. I haven't yet build a good code library, but copy/paste routines from one app to the other when needed. If

[tt]dim rs as recordset ' and
dim rs as recordset[/tt]

means different things dependtend on project, it's not only Access experiencing amiguity, but also me. Why on earth do I get Type mismatch, user defined type not declared, method or member not found errors when the code runs without error in the original app?

OK - you can easily get past that by adding a couple of lines of comment -

[tt]' NOTE - this routine requires the DAO library to have higher priority than ADO [/tt]

But then, what if the other project relies on ADO the same way, and you need this routine?

Or when you fetch a whole form with some form recordsetprogramming (DAO recordset unless ADP or explicitly set as ADO) and you rely on ADO with highest priority in this project.

Then you have to alter the code - in other words disambiguate, or explicitly declare the objects through the library. This could easily mean going through some code lines, and would need some time, also to ensure that the recordset instantiated within a deeply nested if/else/endif structure also works.

Also, when importing all objects into a new database, there's only need to ensure the correct libraries are checked, not toggle the order of them.

I think, typing four/six letter letters in front of my recordset object declaration when doing the initial write of the routine can reduce the overall time used to program and debug, clears the ambiguity within my own head, for Access and also for those who are unfortunate enough to have to maintain my apps in the future. So, typing a few letters more at the start, really applies to my laziness;-)

It may of course be my disorganized way of programming, but before I started using explict declarations, I found there where always some part of a routine, deeply nested somewhere, throwing and exception at the most unfortunate time.

It's also recommended in ADH (Getz et all, Sybex), who also claims it performs faster when disambiguating references.

Some go even further by using a naming convention not only showing object type, but also library and scope, for instance:

[tt]dim l_recDAO as dao.recordset
dim l_recADO as adodb.recordset[/tt]

(l=local recordset) and/or also add a descriptor/name suffix related to what info is retrieved through the recordset. Using such, there should never be any ambiguity.

One other thing to consider, is if/when another object library is either added to your project, or it becomes a default library to Access (as is the case in Access 2003, both ADO and DAO are default libraries), one may suffer the same (when objects and methods having the same name with either the same functionality or different functionality). Some samples FileSystemObject, which one may find both in Microsoft Scripting Runtime and Windows Script Host Object Model and the Dictionary object found both in Microsoft Scripting Runtime and the Word application object.

So my preference is to type those few extra letters when creating the routine, to avoid the ambiguity arising later, but of course that's preferences.

Roy-Vidar

 

[VBslammer]

Or course you're right RoyVidar, explicitness goes hand-in-hand with GIGO (Garbage In, Garbage Out). If we don't tell the stupid computer what we want, then we shouldn't be surprised that it can't figure it out on its own.

And I'm definitely a proponent of early-binding when possible. Typing a few extra letters is a no-brainer after you've worked with .Net code for a while...some of the new stuff has to be very explicit:

[green]// C#
// variable declarations[/green]
protected System.Web.UI.HtmlControls.HtmlInputHidden paramID;
protected System.Web.UI.WebControls.DataGrid dgExistingPolls;

[green]// checking null[/green]
if (!(DBNull.Value.Equals(memberRecord["LastLogin"])))
  base.LastLogin = Convert.ToDateTime(memberRecord["LastLogin"]);

[green]// getting a combo value[/green]
int points = Convert.ToInt32(((DropDownList)e.Item.FindControl("cboPoints")).SelectedItem.Value);

Coding .Net takes some getting used to, but when you go back to do maintenance coding it is very easy to understand what's going on because it's so wordy. Speaking of .Net, have you used VB.Net? I love the auto-generated "End" clauses it generates for you. Once you get used to that it's a letdown to come back to VB6. That would be a great Add-In project for the classic VB IDE. Hmmm...

VBSlammer

"You just have to know which screws to turn." - Professor Bob