Not enough memory to refresh display

  • Thread starter Thread starter Mark A. Sam
  • Start date Start date
M

Mark A. Sam

I wrote the following procedure to update a table from a form. It is in the
Timer Event.

Private Sub Form_Timer()

[txtTime] = Time
[Users].Requery
[UserActivity].Requery

iCount = iCount + 1
If iCount >= 120 Then '1 hour of time
iCount = 0
Dim rst As Recordset
Set rst = CurrentDb.OpenRecordset("ScreenUserIdent", dbOpenDynaset,
dbSeeChanges)
rst.FindFirst "[EmpLoginName] = '" & GetLoggedUser & "' And
[MachineName] = '" & fOSMachineName & "' And [FormChildlink] = " & [ordID]
If Not rst.NoMatch Then
rst.Edit
rst![TimeLog] = Time
rst.Update
End If
Set rst = Nothing
End If

End Sub

The event is set for 30000 (30 seconds) to requery subforms. The method to
update the table is set for 1 hour (Icount = 120) , becuase I am afraid of
memory problems. Sometimes during testing I would get a message saying
there is not enough memory to refresh the screen display. However, I am
working remotely via terminal services and am thinking maybe that is the
issue. Last night I set iCount to 4 (two minutes) and upened the screen. I
also attached to my client via PC Anywhere and opened the same screen and
let them both run for a while to see if one had a problem and not the other,
but neither did.

I want to update the table more frequently, but am concerned about the
memory issue.

Can someone tell me if something in my method is inefficnet or can be
improved so that I can update every minute without worrying about memory?

God Bless,

Mark A. Sam
 
You say you got this error during testing. I'm guessing that you were going
back and forth between design view and form view on the form. Does this form
have a jpg file as its background, such as the ones that came with Access?
Are you running Access 2000? If so, this is a problem that was fixed in
service release 1 for Office 2000. The current service release is number 3.
Unlike the NT service packs, these are not cumulative, you need to install 1
then 2 then 3.
 
Hello Wayne,

I am always going between design view and form view of a form...lol, but it
caused that error.

No .jbg file as the background.

This is A2000, and all of the Service Packs are installed. I set the
procedure to 2 minute updates and opened the app via PC anywhere over an
hour ago without a problem so far. I'll get it run during the day and if no
errors occur, I'll trust it.

Thanks Wayne,

Mark


Wayne Morgan said:
You say you got this error during testing. I'm guessing that you were going
back and forth between design view and form view on the form. Does this form
have a jpg file as its background, such as the ones that came with Access?
Are you running Access 2000? If so, this is a problem that was fixed in
service release 1 for Office 2000. The current service release is number 3.
Unlike the NT service packs, these are not cumulative, you need to install 1
then 2 then 3.

--
Wayne Morgan
Microsoft Access MVP


Mark A. Sam said:
I wrote the following procedure to update a table from a form. It is in the
Timer Event.

Private Sub Form_Timer()

[txtTime] = Time
[Users].Requery
[UserActivity].Requery

iCount = iCount + 1
If iCount >= 120 Then '1 hour of time
iCount = 0
Dim rst As Recordset
Set rst = CurrentDb.OpenRecordset("ScreenUserIdent", dbOpenDynaset,
dbSeeChanges)
rst.FindFirst "[EmpLoginName] = '" & GetLoggedUser & "' And
[MachineName] = '" & fOSMachineName & "' And [FormChildlink] = " & [ordID]
If Not rst.NoMatch Then
rst.Edit
rst![TimeLog] = Time
rst.Update
End If
Set rst = Nothing
End If

End Sub

The event is set for 30000 (30 seconds) to requery subforms. The method to
update the table is set for 1 hour (Icount = 120) , becuase I am afraid of
memory problems. Sometimes during testing I would get a message saying
there is not enough memory to refresh the screen display. However, I am
working remotely via terminal services and am thinking maybe that is the
issue. Last night I set iCount to 4 (two minutes) and upened the
Click to expand...
screen.
I
also attached to my client via PC Anywhere and opened the same screen and
let them both run for a while to see if one had a problem and not the other,
but neither did.

I want to update the table more frequently, but am concerned about the
memory issue.

Can someone tell me if something in my method is inefficnet or can be
improved so that I can update every minute without worrying about memory?

God Bless,

Mark A. Sam
Click to expand...
Click to expand...
 
Hello Wayne,

Speaking about that I just got this message when I tried to post a reply to
you.

Outlook Express could not post your message. Subject 'Re: Not enough memory
to refresh display', Account: 'msnews.microsoft.com', Server:
'msnews.microsoft.com', Protocol: NNTP, Port: 119, Secure(SSL): No, Socket
Error: 10060, Error Number: 0x800CCC0E

Sheesh. I am on my machine now but the error I had was coming from the
Client machine which I was attached to remotely by terminal services.

Before I repost my message I'll wait to see if it got posted or not.

Mark
 
I am pretty sure it is the requerying causing this in the snippit I posted
on the original message, that is causing records on the unrelated subforms
( as well as fields on the main form ) to become undone. I thought that
doing a save record method before the requeries would prevent this, but that
didn't work. Any ideas would be appreciated.
 
Had you been editing the database on your computer before trying to send the
message? It sounds as if you have a memory leak, but I don't see anything in
what you have. You are setting rst=Nothing, it is also recommended to close
it first, you can try but I don't know if it will help.

rst.Close
Set rst=Nothing
 
Wayne,

I ran it all day at 2 min intervals without a problem using from a PC
anywhere connection. I also ran it for a while under terminal services
without difficulty. But I ended up disabling it due to a problem with data
entry. Fields were being undone while the operators were typing whenever
the timing event fired. I believe it is the requerying causing the problem.
I just have to find a work around to this issue.

God Bless,

Mark
 
Back
Top