field is wiped out without warning

[Deborah V. Gardner]

I have a multi-user database in Access 2000. The back end is on the
server and the front end is on each machine. The user will go to a field
(defined as data type Memo) and make some changes. Then he will go to
another field and the first field is wiped out; nothing is in it.

In the OnExit command, I have DoCmd.RunCommand acCmdSaveRecord.

Also, they are using an .mde file as the front end.

Does anyone have any idea what is causing this field to just wipe out?

Thank you for any help.

Deborah

[Rich P]

My experience has been that I would have some test code in some obscure
location that I forgot about, and it gets invoked at some event, but you
don't know which event - could be a button event, current event, etc.
To make matters worse, I reference the field by its ordinal number

For i = 0 to rs.fields.count - 1
rs(i) = ""
Next

Something you could try would be to search for the field name using the
Find dialog (ctrl-F in the code module). If that does not turn anything
up then try searching for the table name. If you locate the table name
(or if you are lucky enough to find the actual field name) trace the
code wherever you reference the table/field in question. One other
thing you could check is the default property of the field on the form.
That property may also be getting set to "" after some event. That is
the worst case scenario because you can't find anything in the code
module, and if you have lots of forms and lots of fields - well, you can
open all the forms and loop through the forms collection and check the
properties of each control on each form in a couple of For Each loops
till you find the control whose source is your memo field and then check
its properties. Lastly, you can use DAO to loop through all the
querydef objects (queries) and check the sql string of each query to see
if your memo field is in an update query

Sub HuntForMemofldInQueries()
Dim DB As DAO.Database, QD As DAO.QueryDef
Set DB = CurrentDB
For Each QD in DB.QueryDefs
If Instr(1, QD.Sql, "Memofld") > 0 Then
Debug.Print QD.Name
End If
Next
End Sub

HTH

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[Br]

Deborah V. Gardner <dg******@twcny.rr.com> wrote:

I have a multi-user database in Access 2000. The back end is on the
server and the front end is on each machine. The user will go to a
field (defined as data type Memo) and make some changes. Then he will
go to another field and the first field is wiped out; nothing is in
it.
In the OnExit command, I have DoCmd.RunCommand acCmdSaveRecord.

Why do you need to save the record after the field is updated? Try
removing that line and see what happens. If it doesn't happen any more
try doing something else to get around it.....

ps. Try Me.Refresh instead :)

<>
--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response

[Deborah V. Gardner]

Thank you for your response.

I did find some suspicious code and deleted it. The reason I had the
Save command included was in hopes that by saving the record on exit,
the information would not be wiped out.

I did find some information about page-locking vs record-locking and
wonder if that is the problem. I think I might have to include two
fields in place of the one memo field.

Any ideas about how to address this problem if, indeed, it is a locking
issue?

Deborah

Rich P wrote:

My experience has been that I would have some test code in some obscure
location that I forgot about, and it gets invoked at some event, but you
don't know which event - could be a button event, current event, etc.
To make matters worse, I reference the field by its ordinal number

For i = 0 to rs.fields.count - 1
rs(i) = ""
Next

Something you could try would be to search for the field name using the
Find dialog (ctrl-F in the code module). If that does not turn anything
up then try searching for the table name. If you locate the table name
(or if you are lucky enough to find the actual field name) trace the
code wherever you reference the table/field in question. One other
thing you could check is the default property of the field on the form.
That property may also be getting set to "" after some event. That is
the worst case scenario because you can't find anything in the code
module, and if you have lots of forms and lots of fields - well, you can
open all the forms and loop through the forms collection and check the
properties of each control on each form in a couple of For Each loops
till you find the control whose source is your memo field and then check
its properties. Lastly, you can use DAO to loop through all the
querydef objects (queries) and check the sql string of each query to see
if your memo field is in an update query

Sub HuntForMemofldInQueries()
Dim DB As DAO.Database, QD As DAO.QueryDef
Set DB = CurrentDB
For Each QD in DB.QueryDefs
If Instr(1, QD.Sql, "Memofld") > 0 Then
Debug.Print QD.Name
End If
Next
End Sub

HTH

Rich

*** Sent via Developersdex http://www.developersdex.com ***

[dgardner]

I did some follow up on this problem. I connected my laptop to the
client's network. The db worked fine. I then opened it on another
computer and it also worked fine.

Then I opened it on 2 other computers and had the same problem--the
field was being wiped out; any changes to the record were not saved.

I shut everything down and opened up the database on one of the
"offending" computers. It worked fine. I opened it up on my laptop and
it worked fine. I then opened it up on 2 other computers (one which
worked fine the first time) and the field was wiped out.

I discovered that the file VBE6.DLL on my laptop is a different version
(it is newer) than the one on the client's computers.

If I remember correctly, I think there was a problem with that file and
one of the patches solved it by updating the file. Each copy of Access
on these machines has had SP3 applied. Is it possible that somehow this
old file is causing the problem?

Thank you for any insight you can offer.

Deborah
Deborah V. Gardner wrote:

Thank you for your response.

I did find some suspicious code and deleted it. The reason I had the
Save command included was in hopes that by saving the record on exit,
the information would not be wiped out.

I did find some information about page-locking vs record-locking and
wonder if that is the problem. I think I might have to include two
fields in place of the one memo field.

Any ideas about how to address this problem if, indeed, it is a locking
issue?

Deborah

Rich P wrote:

My experience has been that I would have some test code in some obscure
location that I forgot about, and it gets invoked at some event, but you
don't know which event - could be a button event, current event, etc.
To make matters worse, I reference the field by its ordinal number

For i = 0 to rs.fields.count - 1
rs(i) = ""
Next

Something you could try would be to search for the field name using the
Find dialog (ctrl-F in the code module). If that does not turn anything
up then try searching for the table name. If you locate the table name
(or if you are lucky enough to find the actual field name) trace the
code wherever you reference the table/field in question. One other
thing you could check is the default property of the field on the form.
That property may also be getting set to "" after some event. That is
the worst case scenario because you can't find anything in the code
module, and if you have lots of forms and lots of fields - well, you can
open all the forms and loop through the forms collection and check the
properties of each control on each form in a couple of For Each loops
till you find the control whose source is your memo field and then check
its properties. Lastly, you can use DAO to loop through all the
querydef objects (queries) and check the sql string of each query to see
if your memo field is in an update query

Sub HuntForMemofldInQueries()
Dim DB As DAO.Database, QD As DAO.QueryDef
Set DB = CurrentDB
For Each QD in DB.QueryDefs
If Instr(1, QD.Sql, "Memofld") > 0 Then
Debug.Print QD.Name
End If
Next
End Sub

HTH

Rich

*** Sent via Developersdex http://www.developersdex.com ***