Accde made on developement system does not fully work on client system (1 Viewer)

I am developing an app for one of my client and am faced with a strange issue.

If I compile and make accde file on my development system it does not fully work on the client system. To be more precise; I have some forms with textbox value set to default (=Date()). The date shows correctly in the accde file on my system. When the same accde is opened on the client system, the date textbox has a value = #Name?.
If I compile and make the accde on the client system, everything works fine without any issues. I have searched and found that this could be due to references. I have checked those and inserted a code to refresh the references but still the same issue.

Any help on the issue is greatly appreciated.
Thanks
Ashok

My suggestion would be to look at your references and the references on the client machine at the version level. Also, look at the Windows Updates esp. VBA, Office,

If anyone knows of a tool, script or other way to do this efficently, please let us know. This is a tough thing to troubleshoot.

My DB is developed on a 32 bit desktop - then moved to a 64 bit Windows Server for distribution on Citrix. About three times, I had a problem like this.
Open a new MS Access blank DB - Import all the objects from your existing DB - then reset up your start form and other settings. Don't understand why, but this was successful when nothing else seemd to be a problem.
If anything, it has the advantage of super compressing and re-indexing things, so there is no downside. If you find something that works, please let everyone know.

Thanks for your reply and suggestion Rx.
As I said in my first post, before making the accde on the client system I have checked the references and they are all fine.. exactly same as on my system. The only difference in my system and the client system is that it has 4 GB RAM and my system has 6 GB Ram. Same windows and same office version with no apparent difference in the updates as well. Further, had it been an issue with the references / updates it would have caused the issue even when creating the accde on client system, which is not the case.
I have had seemingly much more difficult issues but always found some or the other way to resolve them but this one although does not seem that big but is driving me nuts.

Any further suggestions welcome.
Thanks
Ashok

At least it indicates what it isn't.
Well, I had another couple of stories but not so much solutions.
I had a problem much worse than this, and it was just weird problems.
The IT group replaced may computer. They all went away.
Can you compile it on a different computer and see what happens to your client and then to yours? I know it is not totally helpful, but it might unveil a trend.

This is one that always bugged me. I use to be a MCT and teach Excel 97 Object Model Programming. So, I go to a corporate site where they had 24 computers. We install the course to each desktop from a shared drive. We get into VBA and object programming. About 2:00 PM, we hit a module with some fairly complex code. 100% of the computers on the righ-hand side of the isle worked, none of them worked on the left hand side. So, the IT staff came down and told me that he was updating the ROM BIOS driver before class and had finished all on the right-hand side. He completed the left hand side that night. The next morning, the module worked perfectly on all of them. While that might not help your exact situation, it is something that impressed me. In Access development with VB 6, as QA manager, we had a bunch of IBM portables we loaded and provided to thousands of customers. I came across the exact problem with a ROM Bios version. Then again in PC Based cash register software using Microsoft C++.
In those following two rare situations, I looked like a genius to be able to solve the problem. The reality is that I am just old and suspect everything under the sun.
It won't take long to check. It just might be worth looking into, esp if it all works on a 3rd PC.

Sometimes, after you eliminate all the possibilities, the thing will start working as if nothing is wrong and leave you wondering if it was a dream?
Please let us know what you find.

Thanks for your prompt response.

"Can you compile it on a different computer and see what happens to your client and then to yours? I know it is not totally helpful, but it might unveil a trend."

That is something I haven't done yet. However, the accde from the client system works on my system. As for compiling on another system and then trying it on client system, I can do it tomorrow and let you know the status.

Thanks
Ashok

a.sharma said:

"Can you compile it on a different computer and see what happens to your client and then to yours?"

Click to expand...

On this point, I share some posts...

VBA to Cleanup A2007 DB Extra Objects
http://www.access-programmers.co.uk/forums/showthread.php?t=226466

NT Command Script and Documented Steps to Decompile / Compact / Compile an Access DB
http://www.access-programmers.co.uk...to_Decompile_/_Compact_/_Compile_an_Access_DB

Success deploying completely decomplied database to both Access 2007 and Access 2010
http://www.access-programmers.co.uk/forums/showthread.php?p=1217193#post1217193

Errors with Windows 7 SP1 and/or Office 2010 SP1
http://www.access-programmers.co.uk/forums/showthread.php?t=229877
http://www.access-programmers.co.uk/forums/showthread.php?t=64611&page=2#post1173317

mdlueck: Thanks for the links you have given. I have gone thru them and also checked that none of the systems involved has either Win 7 SP1 or Office 2010 SP1 so it seems I should not have the issue we are discussing but still it is there.
I have compiled the database on a third system (not having either Win 7 SP1 or Office 2010 SP1) and tried the accde on the client system but still the same issue. If I run the accdb format of the database it runs fine. Double checked the references and they all are fine. If I compile and make accde on the client system then the accde runs fine.
As I do not want the client to have my accdb file, the solution for the time being is to make the accde on the client system and then delete the accdb. I will keep on researching on the issue and if a solution is found will post it back here for everyones benefit.

Thanks
Ashok

Ashok: recently I switched over to as much use of late binding as possible. For example, I switched over all of my use of ADO objects. I utilize this module to provide all of the necessary ADO constants:

ADO Constants for use with Late Binding ActiveX Data Objects 2.8 Library
http://www.access-programmers.co.uk/forums/showthread.php?t=243088

And I did likewise for all of my added references OTHER than the one required to get the TreeView control, as that one needs to be enabled in order to place the control on forms.

Perhaps shifting to late binding would ease up on database portability between systems in your case.

One obvious difference between my deployment environment and yours... I am building an application for a client's internal use, thus I may deploy an .accdb file. The linked to steps are how to completely clean up and DECOMPILE the DB file... you are needing to COMPILE the DB file for deployment... in my mind that is at the other end of the spectrum from the position I enjoy.

You tried going through the documented steps to clean up / decompile the DB, then compiled it, and that did not solve the problems?

It would not happen to be a difference between 32-bit / 64-bit code would it? Are your development systems and the client's systems the same architecture at both Windows and Office levels? Here, Office is always 32-bit, while Windows my be either 32-bit or 64-bit. If it were Office 64-bit, my application would for sure NOT work as for at least one example I make use of the TreeView OCX control which is not supported with 64-bit Office.

Michael: Yes I did try all the cleanup and decompile as documented in the links. It did reduce the size from 25 MB to 18 MB but as for the accde working on client system... no that still remains. Both systems have office 32 bit and Win 64 bit.
I am now thinking on the lines of making an install script or something that would take the accdb and launch the application and in the apps AutoExec I will put a function to run the code for compile and make accde thereafter delete the accdb and complete the installation. That way it will all be automated and the app should work fine. Haven't tested this yet but I hope this will provide me a way to gracefully deploy the application.
As for late binding, I am not that comfortable with that part so will have to research a bit on that and may be can try it later. But thanks for your suggestion.

Thanks
Ashok