Récupère un message d'erreur lors de la transmission d'arguments à une fonction vba: "Argument non optionnel (erreur 449)"

Question

J'essaie de récupérer un jeu d'enregistrements ADODB depuis une fonction dans MS-Access 2007 mais je reçois un message d'erreur très ennuyeux disant: "Argument non optionnel (Erreur 449)".

Je ne peux vraiment pas comprendre ce que je fais mal, s'il vous plaît aider!

Cordialement,

Stefan

FONCTION:

Function Rs(sourceSQL As String) As ADODB.Recordset 

' Create New Disconnected Recordset 

Dim rsConnection As ADODB.Connection 
Dim rsRecordset As ADODB.Recordset 

Set rsConnection = New ADODB.Connection 
rsConnection.Open CurrentProject.Connection 

Set rsRecordset = New ADODB.Recordset 

rsRecordset.CursorLocation = adUseClient 
rsRecordset.Open sourceSQL, rsConnection 

Set Rs = rsRecordset 

Set rsRecordset.ActiveConnection = Nothing 

End Function 

APPEL DE FONCTION:

Private Sub Form_Load() 

Call Rs("tblDocumentCode") 

Debug.Print Rs.txtDocumentCode(0).Value 

End Sub 

Answer 1

Vous utilisez rs deux fois, une fois en fonction, une fois que le nom de un jeu d'enregistrements:

Private Sub Form_Load() 

Set Myrs= Rs("tblDocumentCode") 

Debug.Print MyRs(0).Value 

End Sub 

Answer 2

Si l'on suppose que "txtDocumentCode" est un domaine dans le recordset, ceci:

Private Sub Form_Load() 
    Call Rs("tblDocumentCode") 
    Debug.Print Rs.txtDocumentCode(0).Value 
    End Sub 

... doit être changé à ceci:

Private Sub Form_Load() 
    Debug.Print Rs("tblDocumentCode").Fields("txtDocumentCode").Value 
    End Sub 

Pour autant que je peux dire, qui devrait fonctionne sans avoir besoin d'affecter le jeu d'enregistrements renvoyé par la fonction à une variable. Mais permettez-moi de prendre un peu de recul et de suggérer que la correction de cette erreur syntaxique soulève la question: ce qui est fait, elle est très déconseillée. Chaque fois que cette fonction est appelée, vous ouvrez une nouvelle connexion, mais Access fonctionne mieux avec une seule connexion qui est utilisée encore et encore. Cela est vrai pour les back-ends Jet/ACE et les back-end du serveur. La surcharge requise pour initialiser la connexion va faire en sorte que vos formulaires se chargent très lentement.

Mais pire encore, ce n'est pas la programmation Access - c'est la programmation "réfugié d'un environnement de programmation qui manque de formulaires/contrôles liés". Vous devriez utiliser ODBC avec des tables liées et ensuite vous pouvez assigner des sources de documents à vos formulaires sans avoir à perdre du temps avec les jeux d'enregistrements ADO. Si vous insistez pour faire ce que vous faites, vous pourriez tout aussi bien ne pas utiliser Access du tout, car vous perdez 75% ou plus des avantages d'Access, et vous n'obtenez aucun avantage en termes de performances ou de simultanéité. (et vous acheter un monde de problèmes).

Bien sûr, maintenant que je le regarde de nouveau, vous utilisez le CurrentProject.Connection, et je ne suis pas sûr comment cela interagit avec les tables liées ODBC. En effet, je suppose qu'il est possible que ce soit un ADP et non un MDB/ACCDB, mais cela est encore moins logique, car vous n'avez rien à ajouter dans un ADP pour remplir vos formulaires avec des jeux d'enregistrements ADO - c'est le défaut. Donc, en général, quelque chose ne va pas au-delà de l'erreur de syntaxe - ce que vous faites n'a tout simplement pas beaucoup de sens.