run-time error 2105

[Luis_vxd]

Hi all

I am working on this database for a few days already. Everything went as usual except that 2 days ago I had for the first time the 'run-time error 2105' when loading a form using the following code:

Private Sub Form_Load()
DoCmd.GoToRecord , , acNewRec
Me.cmdClose.SetFocus
End Sub

I have used this hundreds of times. When the form opens go to New Rec and set focus on the Close button.
Only that now I got the 'run-time error 2105: You can't go to the specified record'.
And if I comment out the Docmd.GoToRecord line it gives 'run-time error 2950: Reserved Error' on the SetFocus line...

I have decompiled the database, and used it with MSAccess 2013 and 2016. Paradoxically it works fine on 2007!!! Just my client has 2013.

And I have done the following so far:

• recreate the problematic form (it only happens in one specific form, all others are OK) from scratch.

• Start a new database and recreate the tables from scratch, import everything else except the problematic form. Recreate the form from scratch.
• Use different version of Access. It works fine on 2007.
• Use a different machine with different OS. Usually my development environment is W7, tried with W10.

The interesting is that I manage to have a new form working fine, until, for instance I hide a field called 'DateAdded' in the datasheet section of the form (is a split form). Then I turn to Design View and back to Form View and there is the 2105 error. If I close the form by right click on the tab without saving it and start again the error disappears.
With another test version it was enough to disable some fields in the form for the error to pop-up after Design View - Form View cycle.



I am uploading one of the many versions I have created so far. The problematic form is frmClientsExtra and frmClientsNew, obviously different versions of the same Clients form.

There are 2 'Copy of... forms that do not display the error as they were created from scratch.


Sincerely hope you guys can help me.


Many thanks in advance.
Luis

 

[RuralGuy]

Any chance you have a bogus MISSING Reference?

 

[RuralGuy]

The frmNewClient I'm looking at does not have a valid Record Source. It is looking for something called TemptblClients. The Copy... forms are using the valid table tblClients_old.

 

[Luis_vxd]

Hi RuralGuy

Thank you for your help.
In the many version I have created I have given different names for the tables newly created. In that specific version I renamed it _old thinking of creating a new table from scratch, which eventually happen in a new database. The structure hasn't change.

Not sure about missing reference. Didn't look at it. The database was working fine until 2 days ago and it didn't crash or something weird happened.

 

[Luis_vxd]

All '*Client*'forms have the same record source 'tblClients_old'. Except the one you mention which was an early test and is not used in the application.

 

[RuralGuy]

I think I can see the issue now. I don't know the solution yet so I will study it further.

 

[Luis_vxd]

Thank you. I hope you can help.

 

[Luis_vxd]

I am using yet another machine running W7 and Off 2016.

I have recreated the page from scratch. As soon as I added an empty On Load event I got an error, this time different:
"The expression On Load you entered as the event as the event property setting produced the following error: A problem occurred while Microsoft Access was communicating with the OLE server of the ActiveX control".

I took out the Tab Control and the error disappeared. So far the error didn't re-appear. I have added all VBA code and still working fine.

Just the 2105 error show now in the frmVehicles form :banghead:

 

[RuralGuy]

It is as if there is a conflict somehow in your references similar to the conflict between DAO and ADO.

 

[Luis_vxd]

What could it be?
I only use DAO where required.

This app has nothing unusual in it...

Would it better if I go back to the drawing board and redo the entire app from scratch? This probably will get rid of the conflict?
So far I have redone the tables but imported the queries, some forms and the VBA. Would they bring the conflict along?

Just annoys me not knowing what could have caused it. I wouldn't like to get in the same situation again...

I have been working in the app still. Now I got to an interesting situation:
I have a band new frmClients form without the Tab Control. It works fine until I decide to hide some fields in the datasheet area. My rational is that the user will not need to have the extra Next of Kin information displayed in the the Datasheet. So I got the unhide popup window and tick off the fields that I don't want. Close it, cycle Design - Form View and 'voilá' there is the 2105 error again. I opened again the unhide window, ticked back all fields and the error is gone!

 

[RuralGuy]

Actually you do have the two basRibbon... modules that are a bit unusual.

 

[pbaldy]

Was playing around with frmClientsNew. Curiously, I noticed that without the problematic code, no other records were available (likely the source of the error). Playing around, I found that if I enabled one of the existing controls, or added a new unbound control and left it enabled, everything appeared to work as designed. Not sure why and can't play further right now, have to create a new report for an app. Perhaps a split form thing, which I haven't had a use for yet?

 

[Luis_vxd]

Hi Paul

I tried to replicate your test and got slightly different results.

Without the problematic code I still can see the records and I can go to the new record manually in the datasheet without any error. It seems that when the form is loaded and the Form_Load is ran there are no records available. Further if I comment out the 'GoToRecord' line I got the run-time error 2950: Reserved Error., which seems to indicate that the controls are, somehow, not available at that moment. so it could be in disabled mode at load time.

Could this be a Trust related issue?

I have re-created the database from scratch in a new file. However I have imported the forms, queries and code and the problem persists. In that new database have created a new form and copy and paste the controls from the problematic one and the error persists.
Yesterday (I am GMT+2) I created a entirely new form without the Tab Control and everything is fine until I hide columns in the datasheet, then the 2105 error returns, and disappears when I unhide those fields.

Question: Is the Trust issue persistent? I mean, if for some reason there was a Trust issue at a point in time but not anymore, does Access keeps the Trust flag up regardless of the new trust conditions?

 

[Minty]

We had some very odd problems (sounding slightly familiar to your issue) on one machine here with either Access 2010 or 2013 runtimes - all other machines were fine.
After a lot of messing about it turned out to be a missing Windows 10 update. Make sure the machines in question have all their updates done.

 

[Luis_vxd]

Thank you Minty

My main development environment is W7 Off 13, where the issue happened. It has been like this for a couple of years and lots of applications developed without any issue.

 

[static]

Split forms seem a bit buggy to me.
Can you get it to error as a single form?

 

[Luis_vxd]

Hi Static

You are right. there is no error using a single form...

This even bugs me more...

Can anybody please elaborate on how Access handles the RowSource in a Single Form and in Split Form? it would help to understand this issue. Thanks

 

[static]

I don't think it's a data issue.

Access forms are incredibly complicated things to start with.
Split forms are relatively new and add a whole heap of extra complication into the mix.

I think your issue is to do with screen updating.

For example, I had a look at your db and although I couldn't get it to error, I did notice that the buttons that open other forms (client and vehicle) weren't correctly repainted when they were locked/unlocked.

I did a quick test form in a new db and had the same issue - moving between records on the datasheet didn't correctly update the main form.

Anyway, I personally would avoid split forms wherever possible.

 

[Luis_vxd]

you mean something like 'me.repaint' after controls enable/disable?

However during Form_Load there is no change in the form and is when the 2105 error pops out.

 

[static]

In my test a refresh works.

Private Sub Form_Current()
    Command1.Enabled = chk1
    Me.Refresh
End Sub

But my issue isn't the same as yours. Mine doesn't cause an error as such, just incorrect / unexpected behaviour.

We are using different versions of Access and Windows. I couldn't replicate the error you are experiencing (and I don't recall seeing any evidence that anybody else here could either.)

So all I can say is that split forms seem bugged. The datasheet view doesn't seem to synchronise properly with the form view.

The question is. what is the split view giving you/your users? Do you really need it. It might be a little more effort but could you use a subform instead?