Solved Invalid Procedure Call Or Argument On Everything!

[dalski]

• Creating the most basic new blank form & putting a button with an event just to display a msgbox results in the error in title; nothing wrong with call-name or passing any arguments data types... It is much more sinister than that
• Code which worked fine is no longer working
• VBA Editor no longer jumps to relevant object to view code either
• Class Objects in Object Browser > right-click > remove [object name] greyed out

Something at it's core is wrong. I've compacted & repaired, no improvement; any suggestions?

 

[Gasman]

Repair/Uninstall/Reinstall Office?
Upload the DB here?

 

[Josef P.]

Perhaps a reference is broken. Can you compile the VBA project?

Or:
Create a backup and try decompile.

 

[dalski]

Thanks, can't upload the db as I'm developing my own application to which there is limited supply. Seems like taking a bazooka to swat a fly atm, though search results only have relations to bad data types being passed as arguments; which we know that is clearly not the issue here at all.

 

[dalski]

Perhaps a reference is broken. Can you compile the VBA project?

Thanks, sounds more like the solution. No it's not compiling at all, gives me titled error on first instance of trying to compile.

Looking into decompiling now.

 

[Gasman]

I'm developing my own application to which there is limited supply

What on earth does that mean?

 

[dalski]

What on earth does that mean?

Don't worry about it mate. Concentrate on posting comments which have value.

Josef references are greyed out. Pretty sure you're right. Obviously repairing the application would not benefit this in any way.

 

[MajP]

Josef references are greyed out.

That does not sound like a broken reference. With a broken reference you normally see the references and the broken reference will state:

 

[MajP]

consider building clean and decompile recompile

Access Keeps Crashing when I go click Debug

Hi, I have just been working on Crosstab queries and reports with parameters and have got it all working (or so I thought). I am now getting an error on the Querydef function where I am setting up the parameters of the query in VBA before calling the report. I have no idea why this isn't now...

www.access-programmers.co.uk

1. Compact and repair if possible
2. Decompile recompile
3. Create new fresh DB
4. Import all tables
5. Import everything else
5. re add references if necessary

 

[dalski]

Thanks, strangely I restarted & in the problematic the References are available now. I thought it may have detached a vital .dll but you're right I have no issues in the References Library which I am able to access now strangely.

 

[MajP]

Keep what I posted in your back pocket for future. It is a good practice to clean up any db.
If the form is really corrupted then a save to text, read from text can also be added to the above trouble shooting

Crash When Add Option Group

Hi, I am working on a form, everytime I add an Option Group with the value to store the selection to a table and save the form Access Crashes. If I create a new form I can create the option group no problem and save it. Can someone tell me why this might be happening? Thanks. Fen How

www.access-programmers.co.uk

 

[dalski]

Something very, very wrong. In trying to compile it throws the same error; but does not bring me to where the issue is.

In decompiling, then rebuidling in safe mode (important to hold down shift when opening), it says it needs to delete my entire VBA Project.



Decompiling Links For Others - Sorry had to remove as being marked as SPAM

"C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE"
/decompile "C:\PathToDb\DbName.accdb"

I'm going to look at importing tables now but what is annoying is i was on another forum & specifically discussed this topic; that Access corrupts easily. They advised it was as solid as a rock. I didn't think it was the case; sure enough here I am.

 

[CJ_London]

The decompile link depends on the version of access - 32 or 64 bit and version number - 14/16 whatever

Access usually only corrupts if the developer is 'doing it wrong' or allows the user to 'do it wrong' or there is an unexpected hardware issue such as a powercut when access is halfway through updating a record.

Some examples where corruption can occur:

• developer editing code whilst it is running
• developer creates and executes code that could cause a corruption - perhaps an infinite loop or something that results in overwriting memory
• multiple users using the same file
• users (or developers) using Access over a wireless network
• powercut whilst access is doing something
• faulty drive

Also advisable to split the db into back end (tables only) and front end (everything else) - and take regular backups

It is difficult to overcome corruption - it can start small and get worse like a small leak on your car tyre. If you don't fix it soon enough, the tyre is a writeoff.

Import what you can to a new file - your error message implies your vba is toast and beyond recovery. If you have it refer back to a backup

 

[MajP]

I'm going to look at importing tables now but what is annoying is i was on another forum & specifically discussed this topic; that Access corrupts easily. They advised it was as solid as a rock. I didn't think it was the case; sure enough here I am.

I would say it is very rare. It used to be more prevalent.

There are two types of corruption and completely different. Different causes and different solutions. Corruption at the table level and corruption in the VBA project (normally a form).

I would not play any more with what you have, because it may get to the point you cannot retrieve anything. At least make a copy. I would definitely go through those steps of importing in to a clean db.
1. Import your tables and compact and repair
2. Import your code modules, queries, macros (but not the forms and reports)
3. I would consider saving all forms and reports to text as linked
4. Read from text all forms and reports
5. Compile

 

[MajP]

The reason I would suggest going as far as save to text and read from text is that technique is the most full proof to ensure you can get a clean object when done. Decompile compile works 98% of the time but I have never seen something that still is corrupted after save and read.
Some here posted a nice piece of code that loops all the forms and reports and writes to files and loops all forms and reports and reads them back in. Try searching for that.

 

[dalski]

Managed to fix it an hour ago but trying to drill down so I can see exactly what the issue is. I previously fixed it with a naming conflict where the engine has failed to update a name, sharing an identical name with a different object type... or identically named events (despite being scoped to specific class items with Private) seems might be an issue; presumably with a failed update renamed class item trying to grab it.

Well aware of the different locations for 64 bit... & as I stated I had fixed the issue so presumably for future users benefit. Tbh in 2024 I can't see your arguments for corruption being reasonably valid in this day and age. I've only dabbled in the below, but taken so many courses I've lost count. Again no expert, but I think it's more the case of Access being based on 30 year old tech.

- C#
- C++
- HTML
- CSS

Access usually only corrupts if the developer is 'doing it wrong' or allows the user to 'do it wrong' or there is an unexpected hardware issue such as a powercut when access is halfway through updating a record.

Some examples where corruption can occur:

• developer editing code whilst it is running

Not a valid defence in 2024. Easily avoided with conditional statements.

• developer creates and executes code that could cause a corruption - perhaps an infinite loop or something that results in overwriting memory

Ditto, can't imagine it being greatly difficult in testing memory tables... prior to making changes to the memory. If the pointer in memory is insufficient then exit & warn user. As for infinite loops; since the dawn of time not an issue with memory corruption; just crashes that instance of the application running.

• multiple users using the same file

Simple conditional statement on opening app avoids this.

• users (or developers) using Access over a wireless network
• powercut whilst access is doing something
• faulty drive

Not a valid defence in 2024. Far more complex apps do not have this.

Also advisable to split the db into back end (tables only) and front end (everything else) - and take regular backups

I don't think that's a good idea during development. You loose considerable functionality when splitting the back-end, lost in-app functionality; for what - reducing a few kb in size. I'm no expert but I remember looking at this some months ago & decided against as reading forums there certainly was reduced functionality in development stage.

Importing the database to a new clean file brings the issue with. Pretty sure it is related to naming conflicts within the form events.

 

[Minty]

Do you have the Track name AutoCorrect facility enabled - that has been know to cause corruption during development.
I never use it, some users swear by it's usefulness.

 

[MajP]

I don't think that's a good idea during development. You loose considerable functionality when splitting the back-end, lost in-app functionality; for what - reducing a few kb in size. I'm no expert but I remember looking at this some months ago & decided against as reading forums there certainly was reduced functionality in development stage

I cannot think of any drawbacks except losing some benefits of name autocorrect. (Some people hate that anyways. I like it, put can cause problems with imports).
So I develop for a while with the tables in place. But once I am confident on my names and table structure I split. Because any multiuse app Has to Be Split (not an option for any real application). But you need to finish developing in split to ensure you have all the link/relink functionality in place and then able to work on a development back end without messing with the real data.

Pretty sure it is related to naming conflicts within the form events.

I would not think so the way you describe the problem. The compiler should easily find that and tell you. It sounds as if it will not compile, if I understand correctly.

 

[dalski]

Do you have the Track name AutoCorrect facility enabled

Thanks was on, that's what I think has happened. Though the object has been renamed correctly in the Object Browser it is referring to an old outdated object name behind the scenes somewhere. I tried switching off, restarting, switching on again in the hope it would force a rebuild; which it did - but sadly no prompts identifying the conflict. I cannot see how to open the actual name map in Access (link spammed again; had to remove). If it was this I would've thought it would have rebuilt on reactivating.

I would not think so the way you describe the problem. The compiler should easily find that and tell you. It sounds as if it will not compile, if I understand correctly.

I would've thought that would be the case. Then again (I don't mean this to sound argumentative) but listen to some of the justifications in #13 for data corruption. Not a dig at you CJ, grateful for your input. It's a dig at Microsoft for trying to use these as defences in 2025 (I quoted the wrong year previously LOL).

I remember in the past some forms would open sometimes on loading the code of said object. I remember thinking that did not look good. I only mention in case someone recognizes something.

 

[dalski]

Thank you all for your help & input.

On creating a fresh db & importing the objects on execution it then did what it should have in the old db & jumped to:

Below in a certain form; which I don't think there is anything wrong with & was not Publicly scoped. There was another combobox with the same name but that should not have affected it; hence my logic was it was a name-mapped issue. I do not think the below should have ever been the issue but it has been working fine so far. Cautious & hopt that my tyre is fixed CJ's analogy.

Me.comboboxName.Requery

Thanks again.