Out Of Memory

[RicardusMaximus]

I have an Access Front End that displays the following error when I attempt to Dim any variable: "Out Of Memory." the intelli sense doesn't even pop-up when I start typing String. If I do a msgBox the intellisense works. I thought that the Forms may have been corrupted, but the application seems to work fine. I am not even able to add a new Sub to an existing module without the "Out Of Memory" message popping-up and erasing everything I typed. The modification that I made to this particular application was to have the Form's Datasource point to the appropriate Linked Table depending on the value in a particular field. I thought perhaps some of the code was corrupted and I needed to Decompile and Compile the Database. {Not real clear on how to do that.} If someone could pt me in the right direction I would appreciate it. This error seems pretty vague. The sixe of the Front does seem to have increased substatially even if I Compact and Repair it. The code that I added wasn't particularly involved.

Private Sub Search_List_DblClick(Cancel As Integer)

'Each of the Files that have a corresponding Archive_Location has been assigned an Archive Location number that will be
'used to determine which query to use to be the Data source for the respective forms.

Dim xArchive_Location As String
Dim y As String

xArchive_Location = Me.Search_List.Column(8)
Activity = Me.Search_List.Column(0)

Forms![Contract Tracking]![Activity_Nr] = Activity

If IsNull(Activity) = True Or Activity = "" Then Exit Sub

'The RecordSource for the Sub forms is determined by the Archive Value of associated with each Activity number
If xArchive_Location = 1 Then


Forms![Contract Tracking]![Activities_Subform].[Form].RecordSource = "Activities"
Forms![Contract Tracking]![Contract_Info].[Form].RecordSource = "Contract_Info"
Forms![Contract Tracking]![Timings].[Form].RecordSource = "Timings"
Forms![Contract Tracking]![Revenue].[Form].RecordSource = "Revenue"

'Forms![Contract Tracking]![ContractHistory].RowSource = "Contract History"

ElseIf xArchive_Location = 2 Then

Forms![Contract Tracking]![Activities_Subform].[Form].RecordSource = "Activities_Archive2"
Forms![Contract Tracking]!Timings.[Form].RecordSource = "Timings_Archive2"
Forms![Contract Tracking]![Contract_Info].[Form].RecordSource = "Contract_Info_Archive2"
Forms![Contract Tracking]![Revenue].[Form].RecordSource = "Revenue_Archive2"

End If

Forms![Contract Tracking]![ContractHistory].RowSource = "Contract History"

DoCmd.Close acForm, "Contract Search"

End Sub

 

[Ranman256]

Do you have many subforms on a single form?
That will eat up memory.

 

[sneuberg]

Is the problem now related to this code? If you delete this code or comment it out does the problem go away? If that's the case then I'd find the offending line of code by commenting out code in a divide and conquer way.

 

[sneuberg]

Have you looked at this http://www.fmsinc.com/faqs/memory.htm ?

 

[JHB]

I thought perhaps some of the code was corrupted and I needed to Decompile and Compile the Database. {Not real clear on how to do that.} If someone could pt me in the right direction I would appreciate it.

Below is a link how to do the Decompile, remember to read the last post.
http://stackoverflow.com/questions/...ecompile-and-recompile-a-database-application

 

[Ranman256]

Code doesn't eat up memory, data does.
You have too many recordsources.
Try to use only 1 at a time.

 

[gemma-the-husky]

you may have a minor corruption.

if restart doesn't help, then see if the issue is restricted to one form - although you probably wont be able to get at the code.

if you can identify a bad form, then you may need to delete the bad form, and reload from a back up.

worst case, you may have to import everything to a new database.

 

[RicardusMaximus]

Thanks guys.
I went with working from a Backup and rebuilding each of the Forms and queries. Seems to be working and the Front End and the size of the Front end doesn't look bloated. Some of the information relating to Decompiling and compiling looks a little risky. Am I correct in thinking that is you decompile you then indicate which Database you want decompiled and then recompiled? there isn't a risk of all Access Aplications associated with your profile being decompiled?
(Surprised that Access doesn't have a built in option to recompile the cose on an application.)

Thank you.

 

[gemma-the-husky]

if you are worried about anything (often quite correctly) just take a back up copy first.

 

[JHB]

.. Some of the information relating to Decompiling and compiling looks a little risky.

Which of them looks risky?

 

[RicardusMaximus]

The last comment: " 2 down vote
Just wanted to add my two cents. I work with SQL Server, SSIS and MS Access databases daily, and our network allows us to use different Citrix desktops; some are Win Serv 2003 SP2 and some are Win Serv 2008 R2 based. When you compact and repair MS Access dbs in one desktop the databases are fine. But, when you decompile, you have to make sure whoever else uses the dbs will be able to open them. Check all the controls to see if they work the same from workstation to workstation. You will run into issues when someone else's installation of MS Access doesn't contain the same libraries. That lead us to disallow all development of front-ends with unconventional controls, specially ones that you would have to add a reference to the db in order to use. Though, it's a great resource to bring size down and speed up your code, decompiling can cause tons of troubles in a multi-user environment"