2010-09-15 12 views
1

J'ai la fonction suivante dans l'accès, qui fonctionnait assez bien. Mais maintenant, je suis tout à coup commence à avoir une erreur de compilation: Membre de méthode ou données non trouvéErreur de compilation dans le code VBA dans MS Access

Function Serialize(qryname As String, keyname As String, keyvalue) As Long 
Dim dbs As Database 
Dim rs As Recordset 

Set dbs = CurrentDb 
On Error GoTo Err_Serialize 
Set rs = dbs.OpenRecordset(qryname, dbOpenDynaset, dbReadOnly) 


    On Error GoTo Err_Serialize 

    'Find the current record.' 
    Select Case rs.Fields(keyname).Type 
     ' Find using numeric data type key value?' 
     Case DB_INTEGER, DB_LONG, DB_CURRENCY, DB_SINGLE, _ 
     DB_DOUBLE, DB_BYTE 
      rs.FindFirst "[" & keyname & "] = " & keyvalue 
     ' Find using date data type key value?' 
     Case DB_DATE 
      rs.FindFirst "[" & keyname & "] = #" & keyvalue & "#" 
     ' Find using text data type key value?' 
     Case DB_TEXT 
      rs.FindFirst "[" & keyname & "] = '" & keyvalue & "'" 
     Case Else 
      MsgBox "ERROR: Invalid key field data type!" 

    End Select 

    Serialize = Nz(rs.AbsolutePosition, 0) + 1 


Err_Serialize: 
     'Add your own Error handler' 
     rs.Close 
     dbs.Close 
     Set rs = Nothing 
     Set dbs = Nothing 

End Function 

L'erreur met en évidence rs.Findfirst.

Est-ce un bug par hasard?

Répondre

3

Essayez:

Dim rs As DAO.Recordset 

Et si cela ne compile pas, assurez-vous que vous avez encore une référence à Microsoft DAO x.x bibliothèque d'objets.

2

Il existe deux bibliothèques d'interface de données possibles dans Access, DAO (la bibliothèque native) et ADO, et les deux ont des objets Recordset. Seul le DAO a une méthode FindFirst - dans ADO, c'est Rechercher. Comme @Remou le souligne dans sa réponse, vous pouvez spécifier la bibliothèque et éviter l'ambiguïté. Dans la plupart des cas, il y a peu de raison d'envisager d'utiliser autre chose que DAO comme interface par défaut dans une application Access (MDB/ACCDB). Pour les ADP, bien sûr, ADO est le seul choix (puisque les ADP sont sans Jet). Dans le cas de votre code, vous utilisez clairement DAO (puisque vous utilisez une variable de base de données qui n'existe pas dans ADO - vous utilisez plutôt des objets de connexion), donc vous avez probablement la mauvaise référence (ADO) ou vous avez ADO et DAO et ils sont dans l'ordre avec ADO en premier.

En général, il n'y a presque jamais un cas où il est approprié d'avoir les deux références, à mon avis - cela rend tout plus difficile. ADO peut être utilisé sans référence (DAO peut l'être aussi), mais il implique un faible typage de vos variables d'objet et une perte d'Intellisense. La pratique normale consiste à utiliser principalement DAO et peut-être un saupoudrage de l'immersion occasionnelle dans ADO pour les choses qui manque DAO (ou fait moins efficacement que ADO). Pour ces besoins ADO occasionnels, vous pouvez utiliser l'objet CurrentProject.Connection et tapez vos variables en tant qu'objets et faire sans la référence ADO entièrement.