Solved Error 2046 on open

[Cotswold]

Just wondering if anyone knows more detail on Error 2046. Its official explanation is:

2046 : The command or action '|1' isn't available now.@* You may be in a read-only database,
or an unconverted database from an earlier version of Microsoft Access.

I have a program developed in Access2019 and I also have a Runtime for 2010. So I opened the A2019 version in A2010, did compact & repair,
then created an .accde. The error 2046 appears in the function that checks the BE Data, which will relink if necessary. The FE & BE are local, no network

When I open it in Runtime 2010 it pops Error 2046 which is trapped in my error handler. Clicking past that, the program runs normally and without error.

As the error refers slightly to an earlier version, I uninstalled the RunTime2010 from the target PC and installed Runtime2019 (365). Then created the .accde in A2019. When it runs in RunTime the same error shows.

Needless to say the error has never appeared during development. Neither does it if the .accde runs in the full copy of Access2019. Same in Access2010 no problem. So only in RunTime on both. I would prefer it to run in Runtime2010 but not that important.

 

[The_Doc_Man]

That is telling that something passed in across the GUI/SQL environment has an error in the first field or element passed in to it. The construct '|1' represents the first thing you passed in for the initiating step, which may have been null or empty.

If you can identify the step that triggers the error, that would help (obviously). But when you find the step, something that is being passed is being passed incorrectly. Without actual code it would be hard as heck to identify the culprit.

From your description, this MIGHT be a difference in libraries, too. Stepping down from Ac2019 to Ac2010 means you have things in the saved DB file that were created in the wrong version.

But then, you switched back to Ac2019 (365). Once the down-step occurred, I don't know what is in the DB file.

I personally would have tried to export every element in text and then rebuilt the app by importing the text. Doing it in binary forms would import binary data that would be much harder to decode.

 

[tvanstiphout]

> So I opened the A2019 version in A2010
Software is rarely forward-compatible, R&C notwithstanding. A2010 is no exception.

Development should always be done in the lowest version you need to support.

Btw, did you know you can run the full version of Access with the /runtime switch to simulate the runtime version of Access. That is MUCH better than trying to install both the full and runtime version on the same machine (if that is what you were trying to do; it's unclear to me if you're talking about 1 or 2 machines).

If the References may be a problem, you can write a test in your startup code to loop over the References collection, checking for IsBroken.

 

[Cotswold]

Found it with a combination Of Doc's and tvanstiphout's suggetions.

I have a variable mFIOerr which I adjusted through the code. So I added one after every line of code. Initially the FIO error was 0, then it went to 5 and finally 18. Then running it with the R suffix it was located it with mFIOerr at 18. No errors ever showed when running in Access itself.

I had dimmed DB as DAO.TableDef and TB as DAO.TableDef. Then before I set TB unbelievably I set it to Nothing! Later in the code I set a value to TB. (who's the silly old fool that did that?) What deflected me to some extent was that the same code has been used for over six years without a problem in several programs. It is used every time a program runs and again when the BE's are relinked. I was looking but not seeing most of yesterday and almost at the point of remming out the error message! Printing the Function out helped, which is not always the same as reading it on the screen.
I'm giving copies of my Family tree program to my children, hence the Runtime necessity.

Many thanks for your help.

 

[The_Doc_Man]

Then before I set TB unbelievably I set it to Nothing!

Ah, yes ... Nothing - the villain of The Never-Ending Story and also of objects being explicitly or implicitly passed. It makes sense that you might get that error on passing in a dereferenced object - in this case a TableDef.