Unexplained behavior in Windows 2000 AS with MS Access

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

billmiami2@netscape.net - 08 Aug 2005 10:59 GMT

(Note that this message was posted a week ago in
comp.databases.ms-access)

We are having trouble with an MS Access 2000 application. The
application is set up in the standard fashion with a database mdb and a
user interface mdb with links from the user to the data file. Some of
the problems experienced include:

*continuous form subforms go "gray" and seem to lose their connection
with data after being requeried. Errors are generated when trying to
access the data in the subform after requerying. A workaround of
resetting the subform recordsource instead of requerying it has been
implemented which seems to be working for now.

*a combobox unexplainably goes blank such that none of the entries has
any text even though the entries still seem to exist. I can't tell
what exactly triggers this as the combobox isn't being requeried.

These problems only occur on certain servers set up with Windows
advanced server (SP4) and MS Office 2002. There are no problems at all
when the application is run on the following:

Windows XP workstations with Office 2002
Windows 2000 Pro (SP4) workstation with Office 2000
Windows 2000 Server (SP4) with Office 2000

Has anyone seen anything like this? What could be the problem?

Bill E.
Hollywood, FL

Reply to this Message

Tony Toews - 11 Aug 2005 20:54 GMT

>*continuous form subforms go "gray" and seem to lose their connection
>with data after being requeried. Errors are generated when trying to
>access the data in the subform after requerying.

What errors?

>Has anyone seen anything like this? What could be the problem?

Are you getting any "disk or network errors"?

Is this only one server causing the problem? No, you mention
multiple servers. There is an SMB problem of some sort but I don't
recall if it was performance or corruption related.

Anyhow this sounds very much like somehow the network connection is
getting lost. Either after a network timeout which is unlikely in
your situation or possibly a slightly flaky network card, hub or
switch.

It could be some bizarre server setting but who knows.

Now is Office installed on the server? If so why?

Tony

Signature

Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

Reply to this Message

billmiami2@netscape.net - 14 Aug 2005 10:13 GMT

Tony,

Thanks for responding.

The errors are not Disk or Network errors like you would guess.
Basically, the errors are related to inability to reference values from
the controls in the subform after they are requeried. I can't remember
the exact error--I'll tell you next week when I get the chance to
reproduce it.

The combo box going blank does not produce an error.

I would almost sum it up by saying that using form.Requery or
combobox.Requery causes the element to lose touch with its data, as if
it doesn't remember what the recordsource is. I'm using
form.Recordsource=form.Recorsource as a workaround, which doesn't cause
problems but results in a much clumsier form.

The servers are Citrix servers and that is why they have Office
installed.

We have tested on the offending servers with the files on the hard
drive and the network cable disconnected to yield the same result.
Therefore, a bad network connection probably isn't the cause.

I don't want to spend too much time trying to figure this out.
Instead, I'm redesigning the application so that it works on the
offending servers.

Bill

Reply to this Message

david epsom dot com dot au - 16 Aug 2005 00:30 GMT

> form.Recordsource=form.Recorsource as a workaround

We have seen a couple of reports with this fix recently:
it looks like it may be related to a recent Jet version,
because it doesn't seem that it was ever mentioned in
the past.

So one thing to check would be the Jet version on the
different servers.

It could be the same problem on the combo boxes: there
are other things that you can do that force the cbo's to
requery, and it might be that they are experiencing the
same problem with slow requires as is your subform.

cbo's normally go blank while they requery.

Citrix might be forcing the files to flush to disk: this
is a good idea for database systems, but makes everything
run very slow, which might be interacting with a Jet
"slow requery" problem to make a "very slow jet/citrix
requery problem".

(david)

> Tony,
>
[quoted text clipped - 26 lines]
>
> Bill

Reply to this Message

billmiami2@netscape.net - 16 Aug 2005 01:59 GMT

Thanks for responding, David.

The network guys told me last week that they set up a Win 2000 server
(not advanced server) with Office 2000 and the same problem occurred.
However, I just did the exact same thing myself with a spare machine
and the problem does NOT occur. I admit that I haven't installed all
of the latest service packs or Data Access components, but this is very
confusing. I'll have to see if the MS Jet version is different between
the two machines as you suggested.

Our problem isn't related to running Citrix metaframe. The problem
occurs when we run it directly on the server. It just happened that
the server is a citrix host.

Bill

Reply to this Message

billmiami2@netscape.net - 23 Aug 2005 01:31 GMT

An update on this problem...

We still haven't pinpointed the source, but it is beginning to look
more and more like a hardware issue at the client and nothing to do
with the operating system or version of MS Office.

I set up a PC myself with Win2k Server SP4 and MS Office SR-1. The MS
Access application worked fine with no error. The exact same setup on
one of the client's test servers (we started from a fresh hard drive
and did the installation steps exactly the same) had errors when
running the MS Access application. Could it be memory? Checking
memory usage for the Access app, I see about 20M used which is
significant but nothing drastic. Their server had about 256M of ram
while my test PC had about 50% more. Is this enough to make a
difference?

But what else could it be?

Bill

Reply to this Message