A few weeks ago a failure appeared on every newly installed or reinstalled desktop pc's. (100+ pc's in the office, 10+ affected)
Failure description: some of the forms doesn't open with Docmd.OpenForm. I get error 2501. The Form.Open event doesn't run. The failure is stable. The applications didn't change since months. The same file runs fine on old installations.
I tried:
* decompile + compile + compact & repair on affected pc's
* import to new file (order: tables, queries, modules, forms; with compact & repair in every step)
* removed code using ActiveX & ActiveX reference
* tested the queries behind the affected forms, they are OK
* no errors show up in form editor
* deleting the VBA module of the form
* ticket to the IT departement - no reply so far
* ritual scolding and cursing of M$
The forms are opening after deleting their modules. Obviously, I need those modules. :)
If I only delete the Form.Open, Form.Load event, then they open with errors. (" error between the application and the OLE service provider or ActiveX controller"). I also get the error with Form.Close. If I delete the whole module, I don't get this error.
That error 2501 shows up with totally empty(a single rem line) Form.Open().
We have Windows 7 SP1 build 7601, and Office 2013 plus 64 bit build 4771 on all pc's. Working installations have W7 professional, affected pc's have enterprise version. One affected application has access backend, the other has MYSQL.
Any idea how to fix it?
Solution: we had english Windows 7 with hungarian MS Office. Access forms are working properly after changing language for non-unicode programs to hungarian.
How to do it: local admin privileges required. Go to control panel --> Region & language --> administrative --> change system locale.
Remark: Changing it may break other non-unicode applications.
Related
I am trying to install a legacy VB6 app on a Windows 10 Enterprise PC. The app has an install program and it is installed on many Windows server 2016 machines. This program uses active user documents (dob files) that load in a webbrowser control. The install is successful but when I run the program instead of loading the user document in the webbrowser control i get a dialog box asking me if I want to download or save a 'vbd' file with the same name as the active x dll the user document creates.
My question is if anyone knows if there is a prerequisite to having the vb6 webbrowser control or active x documents work on a Windows 10 machine? I have the dll registered and the registry entries match the Windows 2016 server.
Thanks in advance,
Hank
Here's the relevant (I think) part of the VB6 help for ActiveX Documents:
A few of the more common problems in Internet Component Download and their solutions are listed in this section. These include: [...] Prompt: "Opening file DocumentName.VBD. What would you like to do with this file? Open it or save it to disk?
The proposed solution to this is
This error occurs when the Visual Basic runtime library (MSVBVM60.DLL) is not installed. Generally, this occurs when the safety level in Internet Explorer is set to High. To correct this, you must set the safety level in Internet Explorer to Medium or None.
Note sure when this help entry was written, but with the latest IEs, you add the site in question to the Intranet zone and change the setting there. If that actually resolves the problem, you then should try turning security up again by going into "Customized" and add restrictions again that don't cause it to break again.
Oracle 10g forms builder has stopped working on Windows 7 Enterprise while opening an existing .fmb file, which was made in same environment.
The user is trying to open an existing form with extension ‘.fmb’ after connecting the form builder application to the oracle database, at that time only the application is showing ‘stopped working’ message. Those forms has been given by DBA team to user. And user needs to modify on those forms. I tried with multiple forms to open through the application, most of them causes the same message to appear and the application is crashing.
There's nothing much I can suggest that will fix your problems quickly. Anyway, here's what I think: you (or, even better, administrators) should check whether Forms version you use is/was supported & certified with operating system you use.
I have Forms 10g, ver. 9.0.4 (it was the very first 10g version, regardless the "9.x" version number) which was supported on Windows XP. That's why I installed virtual machine on my computer, put XP onto it and installed Forms. Everything works just fine.
Now, if it turns out that you're running a combination of Oracle software and operating system that wasn't certified (i.e. there's no guarantee that it'll work), I suggest you do the same. It will take some time to make it up and running (matter of an hour or two), but then you can share that virtual machine among all the developers, without any new installation.
Certification matrix is available at My Oracle Support (MOS); have a look. Also, MOS might even have a solution (patch?) for your problems - search their database.
Stuck in this exact problem and unable to find a fix to this.
I create a form from TEMPLATE.fmb on my Windows 7 64bit machine using Forms [32 Bit] Version 10.1.2.0.2.
The form is created successfully. Then I transfer the fmb to AU_TOP forms folder and compile it using frmcmp_batch, No error. The form is compiled and running.
Now when I transfer that same FMB from AU_TOP to my machine and reopen in form builder, it crashes.
IMAGE
On some systems windows 7/8 my vb6 application gets the msinet error 339.
Component ‘MSINET.OCX’ or one of its dependencies not correctly registered: a file is missing or invalid.
I'm wondering if I need that ocx.
How can I tell if I am using the msinet.ocx? And whether I need it?
I notice Microsoft Internet Controls checked as a component and also Microsoft Internet Transfer Control 6.0 (SP6). Are either of these MSInet.ocx?
Microsoft Internet Transfer Control 6.0 (SP6). Load the OCX as a reference by filename and it tell you it's name.
Rebuild the setup program, msinet is normally included if used.
Registration issues can also crop up relating to Internet Explorer 10. If the OCX is present on the systems in question but seemingly not registered, then the solution can be to uninstall IE 10 (normally best to remove all versions of IE that Windows will let you - they're found under Windows Updates, rather than programs, incidentally). After removing these versions, you are free to reinstall the latest version of IE.
We have an old Powerbuilder app running on Server 2000 and need to move it. I am having a problem with moving the Powerbuilder app ver 7.0, to a newer platform - Server 2003.
We basically moved the directory with the app in it and all the Dlls. Then I registered the ones that would allow it. We also had to set up Informix client-side software and verified that it was able to connect to the Database.
The app basically takes 2 parameters then checks for data in a remote database, then generates a return code to be used by another app. The return code we get is unexpected and I have no luck in looking up the number:
-1073741811
The app is run from the command line. When I run the app I get a Windows error that mentions Sybase and msvcr80.dll and a dump, and the return code mentioned above - Here is the error from the manifest text:
Server=watson.microsoft.com
UI LCID=1033
Flags=99088
Brand=WINDOWS
TitleName=Sybase Inc. Product File
DigPidRegPath=HKLM\Software\Microsoft\Windows NT\CurrentVersion\DigitalProductId
RegSubPath=Microsoft\PCHealth\ErrorReporting\DW
ErrorText=This error occurred on 2/14/2013 at 7:56:14 AM.
HeaderText=Sybase Inc. Product File encountered a problem and needed to close.
Stage1URL=/StageOne/cert_lsi_exe/7_0_3_10180/msvcr80_dll/8_0_50727_6195/0001e6d5.htm
Stage2URL=/dw/stagetwo.asp?szAppName=cert_lsi.exe&szAppVer=7.0.3.10180&szModName=msvcr80.dll&szModVer=8.0.50727.6195&offset=0001e6d5
ErrorSig=AppName: cert_lsi.exe AppVer: 7.0.3.10180 ModName: msvcr80.dll ModVer: 8.0.50727.6195 Offset: 0001e6d5
DataFiles=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.mdmp|C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\appcompat.txt
Heap=C:\DOCUME~1\smarkley\LOCALS~1\Temp\2\WER1.tmp.dir00\cert_lsi.exe.hdmp
ErrorSubPath=cert_lsi.exe\7.0.3.10180\msvcr80.dll\8.0.50727.6195\0001e6d5
I am surprised by the msvcr80.dll request, because this app was written around 2003 and I didnt think that c compiler was at ver 8 yet. I have used Dependency Walker and see no complaints there. I am probably in DLLHell with this thing, though... does anyone have any ideas what to look for?
Thanks in Advance!
I still have a few PB 7 applications around.
Did you try Application Compatibility?
Navigate to the folder and right click on the executable and choose the Compatibility tab.
I suggest trying
Run this program in compatibility for Windows XP (Service Pack 3)
Privilege Level [x] Run this program as administrator
You may need to use Windows XP (Service Pack 2) or an earlier version of Windows.
I have a split access 2007 database that has been running fine on a xp machine. I have recently tried moving the database to a new hosting machine that is running win 7 64 bit, but I'm having a few problems.
I have installed office 2010 small business (word, excel, PowerPoint) and the access 2007 runtime on the new machine.
My problem is that I can open the database but only as a read only. I also get the error message on some forms "Error: 3326: This recordset is not update-able".
I have checked (and double checked) that the database . Accdb file is read only and removed the read only attributes at the command prompt.
Also all users have full control set in permissions.
I must admit I expected there to be teething problems but I'm at a loss as to how I can't even get the database to be editable.
I couldn't get this working in Office 2010. I did however simply cut and paste the db files in different locations on the main computer and promptly pasted them back in the original location. I also reverted back to using office 2007. This seems to have resolved the issue, albeit not in a very satisfactory manner.