Insufficient memory to continue the execution of the program - vb.net

My Application (Vb.net, Access 2003/2007) is to scan Access Database files for activex controls and to generate report accordingly.
Problem:
Getting an error like:
"Insufficient memory to continue the execution of the program."
The above error occurs while scanning for older version of Access files like prior to office 2000.
And the line of code where I get this is as follows:
Dim oForm As Access.Form
Dim oAccess as Access.Application
oForm = oAccess.Forms(objForms.Name)
But it opens the file and form as well.
Need Help:
Whether it is possible to read the file (Access Forms and Reports) or not?
Please provide me reference or any solution.

You appear to doing COM automation of Access to open the forms and then cycle through their controls looking for certain properties.
Another solution would also involve automating Access, but it wouldn't require actually opening the form, and that's the undocumented Application.SaveAsText command. You'd do something like this:
Application.Saveastext acForm, "dlgWebBrowser", _
"C:\Output\dlgWebBrowser.txt"
You would then have to figure out how ActiveX controls are described in that file. If that file looks like the code for a VB form, that's because that's precisely what it is.
The example above had an IE web browser control on it, and after a dump of OLE data, it had this in it:
OLEClass ="Microsoft Web Browser"
Class ="Shell.Explorer.2"
GUID = Begin
0x54c1ea41936d2046b9dc5b29905976e3
End
I would expect that all ActiveX controls will have an OLEClass, but I non-native avoid ActiveX controls on principle because of the problems they can cause if not properly installed when you try to run the app.
In fact, that could be the source of the problem -- if you open the Access form on a machine that doesn't have the relevant ActiveX control registered, it's going to fail, and the form won't open.
My bet is that Application.SaveAsText is going to sidestep that problem entirely, since the form doesn't have to be opened.

I've seen behaviour very similar to this before. Access 97 files will sometimes report an 'out of memory' error if you try to open them on a computer with more than (I think) 1Gb of RAM. The error doesn't always manifest itself immediately - sometimes the project can appear to run normally but crash when you try to open a particularly large object.
In the case where we did run into this the users were running an old Access 97 database on new XP machines they'd been upgraded to with modern amounts of RAM. Tech support for the company tried everything they could think of - including complete office reinstalls, applying all patches etc. but eventually had to resort to removing RAM from the computers - whereupon the errors went away and everything was rock solid again. I am uncertain as to the exact cause, but it will be connected with memory management in the Access 97 file format (I believe the error is on MSDN somewhere but I wasn't directly involved with Tech support hunting the solution down - I'd just written the application many years before)
I'd suggest you're only way out is to use a special, low memory, PC to run the application.

Related

MS Access occassional "Cannot open any more databases" error

I have an MS Access (2013) application with a split database. Everything seems to run smoothly except for occasionally I will get Error 3048: Cannot open any more databases.
The error occurs when the front end tries to run vba code which involves pulling data from the back end and will stall on any line with: Set DB = OpenDatabase() or DoCmd.RunSQL() commands.
The strange thing is that this error seems to be time based. I can access the back end hundreds of times without error if I do it quickly enough but after some time has passed (~1 hr) the error shows up. In fact, I can open the application and leave it running in the background (with no code running) then go back into it after an hour and I will get the error the first time the code tries to open the back end.
I've searched the length and breath of this site and google for solutions so I know this error has been addressed before. To save people reiterating the usual fixes I will list what I've tested for so far with no success:
Recordset limit: I'm not leaving any recordsets open, every time I open one I make sure to close it. The same for the databases. All my requests
to the back end are done via 3 or 4 vba functions and each of these has
a Rec.Close or DB.Close corresponding to every OpenRecordset()
and OpenDatabase() and I never have more than 2 recordsets open at
a time.
Control limit: I have 151 controls on the biggest form in the application so I should be below the limit (I believe this is 245 for a single form?)
Corrupt database: I've copied all my forms and code to a new Access database and run a Compact and Repair.
Machine Issue: I've tested the application on several machines and reproduced the same error.
Anyway with most of the above situations I would expect the application not to run at all, instead of running fine for a set amount of time and then crashing.
Some other points of note:
Citrix Users: The users are split between normal windows machines users who are experiencing this error and others who are using the application through a virtual desktop software (Citrix) who are having no issues. Unfortunately I don't know enough about this virtual desktop to really work out what that implies.
Background vs Foreground: Some users have claimed that the application only crashes if it has been running for a long time AND they switch over to another program and switch back. I've confirmed that simply switching between the application and other programs doesn't cause it to crash but haven't yet been able to leave it running in the foreground long enough to confirm if it crashes without switching between programs.
I've been struggling with this for days, anyone able to help me out?

CreateObject on Outlook.Application fails on Outlook 2010 when Outlook is running under a different account

The problem I'm running into is already described at Getting/Creating an Outlook Application in Windows 7 but I had a very hard time identifying the source of the problem because I happen to be maintaining an old VB6 application at the moment, and the errors that are reported from VB6 applications are not mentioned in that article. Furthermore, I'm looking for better solutions.
The problem is that CreateObject("Outlook.Application") and GetObject(,"Outlook.Application") are failing with Error 429 - ActiveX component can't create object, particularly on Windows 7. The source of the problem turns out to be that if Outlook is already running under a normal user account and an application is running as an administrator (not unheard of for old 32-bit applications running on Windows 7) wants to access Outlook, the request for an Outlook COM interface hangs for 30 seconds and then fails. It seems to be related to the fact that the requested instance of Outlook and the already-running instance of Outlook are using different user accounts or privileges.
It would be nice, first of all, if a better error could be reported, and if it could be reported more quickly. Usually the application hangs for 30 seconds before reporting the error. So the first question is, is there any way to detect this condition without waiting 30 seconds?
Next, is there any way to work around this error so we don't have to care that Outlook might already be running under different credentials when we want to access the Outlook API? One thought is turning off UAC so that the old 32-bit application is less likely to need to be running as administrator. Is there a better solution?
I assume you 've alredy resolved this, but just in case, i had the same proble and the solution for me was to terminate the procces outlook.exe with an API and then do "CreateObject"
you can do what is next:
if err.number = 429 then
terminateprocces ("outlook.exe") 'u can find function code on intenet
resume
end if
I solved this issue by installing the VB6 application locally instead of on a network drive.
Unchecking Run As administrator in the shortcut properties may have helped.

MS Access ignoring Microsoft Windows Common Controls 6 library

I am having serious problems with the Microsoft Windows Common Controls 6.0 SP6 library in Access. I have a number of scripts which were working fine before the weekend, but which fail lately on multiple different computers when they encounter the StrConv function. Here's a low-down on what's been going on:
Previously, all was working fine. On the afternoon of Friday the 20th (4 days ago), I began encountering some odd messages when I moused over a progress bar ActiveX control I had on one of my forms. This happened on the MouseMove, MouseDown, MouseUp and MouseClick events at least; the message reported was "The expression [MouseMove] you entered as the event property setting produced the following error: There was an error loading an ActiveX control on one of your forms or reports." I had registered none of the events mentioned on this control. Scripts in general were still working at this point.
Yesterday (after the weekend), I found that scripts I had written no longer worked. When encountering the StrConv function (which I was using to convert a string to uppercase), the VBA editor brought up an error message saying "Compile error: Can't find project or library." This function I'd imagine is quite a core part of the VBA language, but the only missing library I could find under Tools->References was "Microsoft Windows Common Controls 6.0 (SP6)". The missing file was listed as C:\Windows\system32\MSCOMCTL.OCX but this was present on the machine anyway. Browsing to it in the references dialogue made no difference.
Since then I have tried installing various different Microsoft Visual Basic redistributions, have followed the instructions at http://www.fmsinc.com/MicrosoftAccess/controls/mscomctl/, have phoned our company's tech support and have tried a system restore to a point where the scripts functioned previously, but nothing has worked. The database I am using resides in a networked folder on a server but the MS Access applications are local to the workstations.
Is there any way to resolve this issue?
Simply open one of the forms giving you trouble in Design View. Insert a new ActiveX object control in the form and save. Load the forms again. Hopefully this solves the problem. You can then safely delete the added control.

Having trouble with buttons in mde file: list box .rowsource

I have a form that has a list box and several buttons that run sqk statements for the list box.
sub on_onClick()
' error checking
me.listbox.rowsource = "SELECT tblMain.First, tblMain.last FROM tblMain ORDER BY tblMain.Last;"
so this kinda thing is what I use for the list box. it works fine for me in the .mdb, and after i have converted the database, split it, made the .mde I go into the mde and it works fine for me still. This is placed on a shared drive
HOWEVER, anyone else that tries to use this, none of the buttons are having an effect. Can't tell if they are not working, or the VBA is not returning any results for them. It works for me, but it is not working for them. So...this is for my local LAN team, I think they all have full control permissions??? The button clicks that get them to that form are working fine also.
please help!
A couple of things come to mind:
It is not clear from your question whether the mde file itself is on a shared drive or whether the back-end database is on the shared drive and each user has a copy of the mde file on their PC. If the users are using the same mde file on the network share then I would strongly suggest not taking this approach. (It probably isn't the cause of the issue, but it will get you into trouble down the road.) Give each user a copy of the mde (front end) and have the application point to the back-end database on the network share.
Make sure that the mde has the ability to relink the tables to the back-end mdb file.If you search SO you'll probably find examples of how to do this in code.
I suspect you may be running into an issue where the mde file is not able to find the back-end tables. In this case you won't receive an error message in your VBA code when you're setting the listbox's rowsource and it will appear as though nothing is happening.
Do they have Macro security disabled? By default, MAcro security is enabled in Access and none of your VBA code will run. To disable: open Access, Tools -> Macro -> Security and set to low.
I think it is generally best to use self-certified projects or a secure location rather than change security levels.
Some information on macro security:
Self Certify projects
General information on security principals for Office code and macro security
Trusted location defaults for Office 2003
Macro security in Office 2003

Cannot register an ActiveX control on only one computer

I have run into an odd problem while attempting to register a vendor-supplied ActiveX control on two different computers. On one computer, I can register the part using regsvr32, and then use it in an Access 2007 form with no problems. On the other computer, after I register the same DLL, it is simply not recognized as a valid ActiveX part by Access 2007, or any other Office 2007 program.
The ActiveX part is contained in a single DLL. I am not missing an additional file on one of the computers.
I cross-checked the exact version of the DLL on both computers using md5sum. Both DLL files are exactly identical.
I cross-checked all of the registry entries generated when the part is registered, using the Nirsoft ActiveX Helper utility. The entries are identical.
I checked Access to make sure that the part had a reference entry which pointed to the DLL.
I checked that the location of the DLL was specified as a Trusted Location in Access.
Unfortunately, I am not enough of a COM expert to know whether or not I am overlooking something odvious. Any additional ideas would be appreciated.
OK, total shot in the dark, but we have some computers in our organization the the IT has locked down pretty tight. When we run setup's they run OK and register our ActiveX components, but the first time we run the program it has to be as an administrator. After that the normal user is able to run the program.
You could try a simple VBS script to verify that the control can be created.
Using Notepad (or similar) save the following as test.vbs, and then double click it to run it.
set oTest = CreateObject("<YOUR PROGID HERE>")
MsgBox ("All Done Successfully")
You should get an reasonably descriptive error or "All Done Successfully".
This would at least point to whether its a system wide or Office specific problem.
And if you get an error it may well point to the actual problem.
OTH, if you don't get an error then you probably have an Office installation issue - which could be resolved by a re-install.