Monthly Archives: October 2011

Microsoft Access 2010 has stopped working

Had this problem since we upgraded to Office 2010 from the 2007 version.
Our access application has a frontend of 20MB, and a backend on an SQL2005 (now trying to pass on 2008).
I solved my problem after reading a lot…
I opened up my Access application by pressing the Shift button, so I bypassed all startup forms and logins.
Opened up a module, not a particular one!
Went on Debug>Compile <ProjectName> and voila…problematic old code started firing up error messages.
After I removed all the unnecessary parts of the code and changed with new refs/code the needed ones, I closed and reopened.
The database opened like a charm. I compacted and repair since this process made my db frontend went on 90MB and started working again with no problem.
Hope it works for you as well.
Have a good day 🙂20/10/2011 Update

The problem continues…

A quick resolution to this is:

“C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE” “C:\MyAccess.accdb” /decompile

where MyAccess is the name of your Database. The Database opens!

The solution above (posted from another user in

http://social.msdn.microsoft.com/Forums/en/isvvba/thread/99a68e98-d9b7-448f-bc94-d06e994e9ec3 )

, regarding this decomplilation solution, is also posted by Microsoft on September 30,2011 on

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2625046

However, till the time the issue with the Faulting module vbe7.dll is resolved, we have to figure out a way to to manage our access dbs. Since no matter what you do, even if you just make a new form the problem still comes back.

When you access db frontends are in production we need a SOLUTION asap!

PS. Have pending 12 Modules and modifications that I need to make in my access frontend and I cannot…
😦

12/1/2012 Update

Microsoft has released an Office 2010 patch on 12/12/2011 which is the ultimate solution to this problem.  This patch worked great for me (even repairing the previous corrupted databases without the need to decompile).

The kbs you may refer for this are:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;2625046

and
http://support.microsoft.com/kb/2596585

The patch (both 32 and 64 bit) can be found at:

http://support.microsoft.com/kb/2553385


One more issue down….plenty to go 🙂

Creativepeople.gr

Advertisements

Cannot connect to Exchange 2003 RPC with Outlook 2007/2010

I am looking in to this problem some days now, not only on Outlook 2003 but on 2007 and 2010 as well. 
I have followed all the needed procedures found around the web but nothing. Outlook 2007 keeps asking for username/pass without going anywhere. 
 
The run command outlook.exe /rpcdiag shows that there is no active or actually working connection.
 
My solution came after doing the following:
 
At first on the client side:
Added the following on registry  key [HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\RPC]
12.0/11.0 for prior Outlook versions
(if no rpc key, then simply create it, right click on Outlook>new key)
“DefConnectOpts”=dword:00000000 (as colleagues mention above)
Also add the following under RPC as well
“ConnectTimeout”=dword value with hex value 000493e0
“ConnectTimeoutLow”=dword value with hex value 000493e0
“RFRTimeout”=dword value with hex value 000493e0
 
Secondly on the server:
On http://www.petri.co.il/how-can-i-configure-rpc-over-https-on-exchange-2003-single-server-scenario.htm you will find the best way to resolve it….but as we ITs are on hurry all the time, we don’t usually see what “exists” right in front of our eyes.
Download the tool called RPCNoFrontEnd (19kb) mentioned on the page (mid). Execute after putting your external fqdn. This tool will make all the necessary registry changes needed on the server part and till now I have not found elsewhere. God bless the guy who wrote it, Harry Bates.
Restart your server in order the registry changes to have effect.
Test your Outlook client Exchange connection through RPC/HTTPs (/rpcdiag if you want). It will take a while in the first time but I worked for me.
Hope this helps…I’m going to sleep now, cause I have a tough day tomorrow.
PS. The best walkarounds I have got till now are the following:

PS2. Be sure that the following registry entries are made on RPC and/or GC server

 
HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\RpcProxy

 
Here you need to change the value of the ValidPorts key, the values should be entered in the below format:
ExchangeServer:593; ExchangeServerFQDN:593; ExchangeServer:6001-6002; ExchangeServerFQDN:6001-6002; ExchangeServer:6004; ExchangeServerFQDN:6004; GlobalCatalogServer:593; GlobalCatalogServerFQDN:593; GlobalCatalogServer:6004; GlobalCatalogServerFQDN:6004
This means if your Exchange server is named Exchange01 and your Global Catalog server is called GlobalCatalog01 and both are members of the AD domain privatedomain.com , it should look like:
Exchange01:593; Exchange01.privatedomain.com:593; Exchange01:6001-6002; Exchange01.privatedomain.com:6001-6002; Exchange01:6004; Exchange01.privatedomain.com:6004; GlobalCatalog01:593; GlobalCatalog01.privatedomain.com:593; GlobalCatalog01:6004; GlobalCatalog01.privatedomain.com:6004
Now we need to logon to the Global Catalog server (which would be the Domain Controller), here we need to add a string to the registry as well, so navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
– Then click Edit in the menu > New then click Multi-String Value
– Name it “NSPI interface protocol sequences”
– Right-click the NSPI interface protocol sequences multi-string value, and then click Modify
– Type ncacn_http:6004 in the value box

Now restart the Global Catalog Server.

Creativepeople.gr

Mine worked! 🙂
%d bloggers like this: