The situation is, we have a bunch of people using Access 97 SR2, with workstation OS variants from Win 9x to XP Pro. I have developed an Access planning tool as a model, with a front end and a back end; the front end has not been compiled--both are .mdb files--and the back end sits on a shared drive on the network.
For most users, whether they are using Win98 or XP, the main data form simply will not run. The effects of these users' attempts to open the form are varied, and range from system slowdown/freeze to outright crashing, sometimes Access only and sometimes everything. Only on my workstation (XP Pro, where it was developed) and one other does the form open and operate normally.
Here's the kicker: not only does everything other than the form appear to operate normally (all the queries and custom VBA functions run through without a twitch, the linked back end data is unobstructed), but I took the project files to my dinosaur at home (Win98 SE, Pent. II @ 266 MHz, 96MB RAM) where everything ran quite smoothly, if only a little bit slower. That, particularly, convinced me that the design is solid and that I'm up against some lurking, and perhaps heretofore undiscovered, bug in Access. I'm thinking it has to be something in the Forms engine, but web searches have yielded nothing.
The main form has 4 subs, 2 linked and 2 unlinked.
If someone could just point me in the right direction. . .thanks.
most of machine depended problems in applications usualy result of outdated drivers or void references. try installing latest MDAC version from microsoft site, and check if client machines have correct VBA references installed.
The problem indeed might be in the MDAC configuration, but I may have just stumbled across something that would suggest the MDAC might otherwise not have been an issue. We got the whole form loaded and running by changing one thing.
Does anyone have any knowledge about the merits of always using a persistent query object as the RecordSource for a form (at least, in cases where the recordset has to be queried)? Having replaced the run-time compiled SQL statement (which was produced automatically by the Form Wizard) with a pointer to a persistent QueryDef object seems to have done the trick.
as I said it is a posibility. let me tell you one of my weird experiences with access. I had a form that includes a unbound textbox and formatted as Date/time and its default value was the Date() argument. It was working on my development machine, but for some weird reason it showed #Name error in the textbox on the client's machine. I installed latest MDAC and problem solved. I don't know how, I don't know why, but it worked .
I never had the problem you had before. but they never acted differently in my projects. if presistent queries works for you, just go ahead and use them. most of the access wiz suggest using presistent queries.