Big trouble installing MS Access App - WIN7

Question

Hello, everybody! (LET ME STRESS THAT, I STILL CAN INSTALL IT 'EVERYWHERE', NO PROBLEM. THAT'S HAPPENING JUST TO MY CLIENT. MAYBE I DIDN'T MAKE THAT CLEAR ENOUGH, SORRY FOR THE CAPS)
Well, I'm having a big trouble when trying to install access app, and that's just unbelieveable! I would like to share it with You, expert fellows, and ask for some help, if You don't mind.
Technically, my client is having a problem,  not me, not at all! And here's the scenario :
1. Application runs on AccessRuntime 2010
2. FE accdr(from compiled accde) and BE accdb
3. I use InnoSetup to copy the files, run the additional softwares, all 'Trusted Location' settings are created, it's just perfect.
4. It was installing OK a couple of days ago(just accdr from accdb)
5. I was able to install it anywhere, I don't see anything wrong(Win8,Win7, i bet it would even work on XP)
6. It was running a couple of days ago until i added the compiled accde->accdr instead of accdb->accdr to the setup, that was the only update applied to  current Setup program, and I bet that's what's happening, don't
know why, or how, since it's fine for me, works just the same. Tricky, specially because i don't see s**t, and in fact, nothing works, it's just amazing!
7. The bug : After installed, error messages : 
*1 'the expression you entered has a function name that "app name" can't find'
*2 Some window to stop macros :
*3 '"app name" cannot run the macro or callback function "Callbackonload" make sure the macro or function exists and takes the correct parameters (Callbackonload Loads ribbons settings,
with icons, all that thing. Never had any trouble with it, not even when i started working with that ribbon stuff)
*4 and again, error report on  'popup' windows:
Now, I wouldn't like to install a non-compiled file, rather to contour the bug, if that's the reason for it as it seems.
Specially because this individual, thinks he's part of development team, and is always giving 'contributions' on how to test, how to track bugs, or allegedly bugs or how things work, etc, because he's been a developer 100 years ago, and something, and it will
not take long for him to start messing things around, besides the fact he bought an application only, not source code.  
Anyway, I'm having a bit of a hard time finding a way out of this, and simply don't know how to proceed, so if anybody would kindly share one's knowledge with me and help me out on this subject, I would appreciate a lot, as usually!
Thanks everybody, and excuse me, if that's a clumsy question!

Answer 1

Actually, the scenario you outline includes the “golden ring” information as to the problem. (as a result – your post is VERY good since you included details as to WHEN the application works, and when it does not! – well done on your part!!!).
You CAREFULLY note that when you distribute a NON compiled (accDB) then your application works.
You CAREFULLY note that when you distribute a compiled application (accDE), then it does NOT work. For the people reading this post – this is the above “golden ring” information that explains what is going on.
In NEAR ALL cases the above means that the target computer has a DIFFERENT version of Access. And when I say “different” version that INCLUDES Access with a DIFFERENT SP update level!
With Access 2010 (full edition), the SP updates are rolled out automatic by windows update. With the Access runtime, such SP updates are NOT rolled out.
This means the customer machine (client) is running a DIFFERENT version of Access. When you supply an accDB, then Access can (and WILL) detect that the VBA code needs to be re-compiled.
WHEN you distribute an accDE, then then VBA source code is NOT available. And of course the target computer is running a different version of Access (and as noted “different” INCLUDES when talking about SAME version of office but DIFFERENT SP update levels).
The end result is you need to compile the accDE on the SAME SP revision level that the customer is using. They are VERY likely installing 2010 runtime, but NOT installing the SP2 update to access runtime. MOST important here is installing the office SP2
update on that target will NOT update the Access runtime!
As a side note, for Access 2013, the download DOES include the SP updates, but 2010 does NOT!
I thus suggest they download + install the Access runtime SP2 update. Remember, SPECIFIC they must run the Access 2010 runtime SP2 update – the office 2010 SP update is NOT sufficient.
So the “BIG HINT” here is that WHEN you include source code, your application runs fine. When you DO NOT include source code (accDE), then the application fails on the target computer. And this is a GREAT lesson for people posting – since they now know and
realize the above issue.
So the “big” hint is WHEN code can not re-compile your application breaks. This is due to the SP level on your development machine being different then the Access SP update level on the target computer.
The above problem is exasperated by the OFTEN occurring issue that your development machine will receive the office update via windows update automatic, and the runtime does not.
However I give you a BIG THUMBS up, since you INCLUDED the VERY IMPORTANT detail that an accDB runs, but the accDE does not!
So the accDB includes source code and will “automatic” re-compile on the customers machine – the accDE does not do this and in fact cannot due to no source code being included.
And I should point out that this automatic VBA re-compile even occurs if the customer has runtime only installed.
So VERY important here is when distribution compiled code, you must ensure that the target computer MATCHES your SP update level that you used to develop the application.
And, do post back to verify the above issue - I have a VERY high confidence the above is your issue, since I seen it a zillion times in the last year!
Regards,
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canad